コードは次のとおりです:
@Configuration public class CorsConfiguration { @Bean public WebMvcConfigurer corsConfigurer() { return new WebMvcConfigurerAdapter() { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedHeaders("*") .allowedMethods("*") .allowedOrigins("*"); } }; } }
この構成では、すべてのマッピング、すべてのリクエスト ヘッダー、すべてのリクエスト メソッド、およびすべてのソースが許可されます。構成を変更した後、効果を確認するために思い切ってプロジェクトを再起動しました。シングル サインイン ページにリダイレクトする方法がないことがわかりました。ブラウザ エラーの原因がクロスドメインであることを確認して、最初に次のコードをアップロードしました。私のログイン インターセプター
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { //用户已经登录 if (request.getSession().getAttribute("user") != null) { return true; } //从单点登录返回之后的状态,本系统还不处于登录状态 //根据code值去获取access_token,然后再根据access_token去获取用户信息,并将用户信息存到session中 String state = request.getParameter("state"); String uri = getUri(request); if (isLoginFromSSO(state)) { String code = request.getParameter("code"); Object cacheUrl = request.getSession().getAttribute(state); if (cacheUrl == null) { response.sendRedirect(uri); return false; } HttpUtil client = new HttpUtil(); StringBuffer sb = new StringBuffer(); sb.append("code=").append(code) .append("&grant_type=").append("authorization_code") .append("&client_id=").append(SSOAuth.ClientID) .append("&client_secret=").append(SSOAuth.ClientSecret) .append("&redirect_uri=").append(URLEncoder.encode((String) cacheUrl)); String resp = client.post(SSOAuth.AccessTokenUrl, sb.toString()); Map<String, String> map = new Gson().fromJson(resp, Map.class); //根据access_token去获取用户信息 String accessToken = map.get("access_token"); HttpUtil http = new HttpUtil(); http.addHeader("Authorization", "Bearer " + accessToken); String encrypt = http.get(SSOAuth.UserUrl); String userinfo = decryptUserInfo(encrypt); //封装成user对象 User user = new Gson().fromJson(userinfo, User.class); request.getSession().setAttribute("user", user); return true; } //跳转到单点登录界面 state = Const._SSO_LOGIN + Const.UNDERLINE + RandomUtil.getUUID(); request.getSession().setAttribute(state, uri); String redirectUrl = buildAuthCodeUrl(uri, state); response.sendRedirect(redirectUrl); return false; }
その後、フロントエンド vue は
window.location.href=this.$api.config.baseUrl+"/system/user/login"
を使用してバックエンド ログイン インターフェイスを直接リクエストし、フロントエンドはシステムにアクセスしてシングル サインに直接ジャンプできます。 -ページ内。しかし、アカウントとパスワードを入力してクリックしてログインすると、システムに戻ってすべてのリクエスト データ インターフェイスに正常にアクセスできないことがわかりました。デバッグでは、すべてのリクエストにユーザー情報が含まれておらず、インターセプターによって次のように認識されたことがわかりました。ログインしていないため、すべてのリクエストが通過できませんでした。
なぜ私は明らかにログインしているのに、インターセプターはユーザー情報もセッションに設定しているのですか? Cookie が消えてしまったのはなぜですか?再度リクエストを開始したところ、各リクエストの JsessionId が異なっていたことがわかり、いろいろ調べた結果、フロントエンドに認証情報を追加できるように設定を追加する必要があることがわかりました。対応する設定をバックエンドでも行う必要があります。allowCredentials(true );
axios.defaults.withCredentials=true;
この設定を追加した後、操作プロセスを再実行したところ、ログイン後は通常どおりシステムにジャンプできることがわかりました。ページデータも正常に表示されます。
これで終わったと思ったら、突然ページをクリックしたらデータが正常に表示されなくなり、戸惑いましたが、慌ててF12を押すと、OPTIONSという見たことのないリクエストメソッドが表示されていました。このリクエストメソッドは明らかに POST であることがわかりましたが、なぜ OPTIONS になったのでしょうか?そこで、他にもいくつかの POST リクエストを注文しましたが、それらはすべて OPTIONS リクエストになっていることがわかりました。混乱してすぐに OPTIONS リクエストの情報を確認しました。インターネットでは、OPTIONS リクエストは「事前チェック リクエスト」と呼ばれていると言われていました。リクエストが実行される前に、ブラウザはまず事前チェック リクエストを開始し、事前チェック リクエストが通過した後にのみ正式なリクエストを実行できます。これを読んだ後、OPTIONS がインターセプトされたため、POST リクエストを実行できなくなったことに突然気づき、事前チェック リクエストをそのまま通過させました。この判断をインターセプタに追加するだけです
@Bean public WebMvcConfigurer corsConfigurer() { return new WebMvcConfigurerAdapter() { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedHeaders("*") .allowedMethods("*") .allowedOrigins("*").allowCredentials(true); } }; }
このようにして、インターセプタはリクエストが事前チェックリクエストであると判断した場合、それを直接渡し、次のPOSTリクエストを実行できます。
以上がvue+springbootのフロントエンドとバックエンドを分離してクロスドメインのシングルサインオンを実現する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。