問題タブ [spring-cloud]

ビジネス用と Spring OAuth 2 を使用したユーザー認証用の 2 つの独立したサービスを開発したい

それらを Business-Service および OAuth-Service と呼びましょう。

リクエストが認証されない場合は、Business-Service を OAuth-Service に委譲する必要があります。クライアント アプリケーション (Android アプリ) は、事前に OAuth サービスについて認識してはならず、認証されていない要求に対して 302 HTTP リダイレクトを使用して、ビジネス サービスによって委任される必要があります。正確には、API ランディング ページでhttp://businessservice.com/loginへのリンクを提供する必要があり、クライアント アプリがこのリンクをたどることを決定すると、OAuth サービスにリダイレクトされます。

Business-Service に@EnableOAuth2Resourceのアノテーションを付けると、そのすべてのリソースが保護され、アクセス トークンなしで curl すると 401 が返されます。ここまでは順調ですね。次のようなアクセストークンを提供すると:

リソースにアクセスできます。まだいい。

ただし、OAuth サービスへのリダイレクトを有効にするために@EnableOAuth2SsoでBusiness-Service にアノテーションを付けると、アクセス トークン (上記と同じ curl) を使用してリソースにアクセスする機能が失われ、ログイン ページhttpに 302 のみが返されます。 //localhost:8667/ログイン

両方のアノテーションを使用すると、認証は機能しますが、 http://localhost:8667/loginを呼び出すと404 が返されるため、@EnableOAuth2Resource は常に「勝つ」ように見えます。

では、認証されていない呼び出しを認証サーバーに委任するリソース サーバーを作成する正しい方法は何でしょうか?

Spring システムを Spring Cloud Config を使用するように移行することを考えています。

システムは複数のサービスで構成されており、DB データソースなどの共通リソースのいくつかの共有プロパティがあります。これらのために、一般的に使用されるプロパティを 1 か所に含む「ベース」構成ファイルがあります。各サービスは、最初に共通ファイルを読み取り、その上でプロパティ ファイルをオーバーロードします。これにより、共通のプロパティを繰り返す必要がなくなります。

spring cloud config で同じことを行う方法がわかりません。さまざまなリポジトリのオプションが表示されますが、プロパティ ファイルのオーバーロードは表示されません。

私は自分のプロジェクトの設計段階にいますが、疑問があります。私は自分のシステムをモデリングしており、Spring Data JPA を永続層に使用します。ただし、クラウド展開の可能性は高いです。Spring Data JPA から Spring Clous AWS (RDS) への移植性はトラウマですか? この種の統合についての直接的な言及は見つかりませんでした。今後は無駄なコードを避けるようにしています。よろしくお願いします、

春のクラウド eureka のドキュメント:

Eureka サーバーは log4j に関連付けられており、logback では機能しないため、通常の Spring Boot アプリと比較して依存関係の構成を微調整する必要があります。spring-cloud-starter-eureka-server がこれを行いますが、別の依存関係を介して推移的に logback を追加する場合は、Maven などで手動で除外する必要があります

SLF4J ドキュメントから:

アプリケーションがブリッジに存在しない log4j コンポーネントを呼び出す場合、log4j-over-slf4j モジュールは機能しません。たとえば、アプリケーション コードが log4j アペンダー、フィルター、または PropertyConfigurator を直接参照する場合、log4j-over-slf4j は log4j の代替として不十分です。

これは eureka サーバーが行っていることであり、log4j-over-slf4j を使用できない理由は何ですか?

Zuul を使用するプロジェクトに spring-cloud スタックを使用しようとしています。私の組織には、xml ベースのカスタム構成スタックがあり、プロパティの構成と階層的なオーバーライドを行います。この構成の処理方法が原因で、PropertySource を作成するのに苦労しました。

私のカスタム PropertySource は私の Config Bean を使用する必要がありますが、Spring Boot のブートストラップ中に PropertySources が初期化されるため、アプリケーション コンテキストはまだ完全に初期化されておらず、xml ベースの構成システムを公開するカスタム Bean にアクセスできません。

@ConfigurationProperties は、完全に .properties および .yaml ファイルに偏っているようです。Config Bean は ApplicationContextInitializer で初期化されます。初期化後に Config Bean を使用してカスタム プロパティ ソースを構築できるように、さまざまなサービス内で ConfigurationProperties の解決を遅らせる方法はありますか?

私は Spring Cloud OAuth を使用しています。https://github.com/spring-cloud-samples/sso/ の公式サンプルをGitLab ( https://about.gitlab.com/ ) を OAuth プロバイダーとして使用しています。

問題は、GitLab がタイプ「ベアラー」のトークンを送信し、Spring Cloud SSO がトークンを取得し、形式の
Authorization bearer xxxxxxx
トークンのみを受け入れるドキュメントに従って、GitLab サーバーによって拒否される形式のヘッダーを送信することです
Authorization Bearer xxxxxxx。

これはおそらく GitLab サーバーのバグですが、Spring Cloud SSO でこの問題を回避する方法はありますか。

アップデート 19.03.:

これは、SpringCloud-sample の SsoApplication.java で試したものです。

新しく注入された OAuth2ProtectedResourceDetails の代わりに、「元の」ものが呼び出されます。サンプルアプリで認証しようとするたびに

パスワードを暗号化する方法はありますか。以下のコードを試しましたが、うまくいきません (spring-cloud-config を使用していません)。

生成されたパスワードは application.yml に配置されます

そして、bootstrap.yml でキーを定義します

エラーが発生しています

非対称アプローチを使用していません。なぜキーストアを探しているのですか?

POM.xml