解決:spring securityログインページの滞留時間が長すぎて403ページにジャンプ
7941 ワード
前言:最近のプロジェクトではspring securityコンポーネントが使われています.このバグ、本当に1波3折です:それを再現するのは問題で、それから私はまた403を404に変えて、それからいっそメインステーションに登録して入らないで、最後に、このバグ、本赤ちゃんのコードの中で消滅されて、ハハハハ!
問題点:tokenの期限切れ
一、問題についての考え方
1,私は书いたログインロジックに问题があるかどうかを考えて、コードで现在のログインページの関连キャッシュの问题を制御して、ずっとコードと.はい、一部の工事は権限がなくて言わないで、それから同僚は私にまた論理にジャンプしていないはずだと教えて、死んでしまいました.私はログインページでそのsecurityのマーク(当時はそれが何なのか全然知らなかった、バカX)を見つけて、調べて、同僚と具体的な状況を理解して、論理に対する疑いを断固として放棄しました.私たちはコードでキャッシュの失効を制御していないからです.
2,ユーザコードの問題ではない以上,コンポーネントメカニズムの問題である.赤ちゃんはすぐにspring securityのドキュメントをめくって、本当にタイムアウトの概念に言及しました.リンクアドレスは次のような一元化されたソリューションが提案されています.https://docs.spring.io/spring-security/site/docs/4.1.3.RELEASE/reference/htmlsingle/#csrf-timeoutsいいでしょう.JS関数を使用して、フォームの提出前にtoken値(springで提供されたCsrfTokenArgumentResolverを使用することによって)を取得することについて説明していますが、赤ちゃんはこの時点でバグとは言えない提案されたバグをやめません.また、カスタム処理に関する異常の提案についても言及しています.しかし、私の赤ちゃんはいつも自分を守る人ではありません.やっとバグを作ったので、しばらく振り回さないと、天罰を受けます.以下は私の赤ちゃんの検証演算の案の例です.
a:もともとspring securityの安全保護メカニズムで、バグではなく、テストと製品と協議し、それを無視しています.ハハ、もちろんこれは下策です.最も手間が省けますが、99%が死ぬと予想しています.
b:滞在時間が長すぎて発生した問題である以上、ユーザーがいつログインをクリックしても、彼が口座情報を入力したばかりのように工夫します.だから私は考えました:HTTP-EQUIV=“REFRESH”CONTENT=“csrf_timeout_in_seconds”>しかし、私のケースの中で、役に立たないで、悲しんでいます.
c:token登録機を使って、時代遅れのものを作って、登録ページに使います.ハハ、私はとてもいいと思います.もうだめだ、このtokenの期限切れに関するコードを見つけて、それを変えた--やはりコードを書くのが死ぬ精神だ.
d:私を怒らせて、私はこのcsrfのtoken検証機能を消します——簡単で乱暴でしょう、へへへ——もちろん、これはできないことを決めて、私のそのバグを解決することができますが
e:とにかく異常が発生して、システムはブロックして、それから指定の403ページにジャンプして、それでは私はそれが403ページにジャンプする前に、この異常を遮断して、それから私がカスタマイズして処理します
f:これは実はd条と似ています.私はすべての検証を消すことができない以上、ログインページの検証総行を消しましょう.ログインページの検証はもともとこのページではなく、ユーザーの権限です.誰でもログインページに入ることができるのではないでしょうか、へへ.そして、当赤ちゃんはブロッキングを書き換え、ログインページのリクエストを流しました.--しかし、人柄に問題があるのか、私は正常にログインできなくて、悲しんでいます.どこか私に書き間違えられたに違いない.
実は私の考えは多くて、いつも1つのこのバグを乾かすことができて、何度も悲しんだ后で、私はカスタムの异常なブロックのこのような方案を选んで、この线の考えは:ブレークポイント、それが403にジャンプする前に见て、いったいどんな异常をブロックしました;異常を見つけて、私はカスタマイズして遮断して、そして私がシステムにしたい反応をします
二、キーコード
カスタム例外処理:
はい、実はここでまた冗談を言いました.私は最初、転送をリダイレクトして、私は頼りにして、前はtokenが失って、今はパラメータ全体がなくなって、自分の心を絞め殺そうとしました.やはり長い間基礎コードを書かないで、手描きですね.
セキュリティ構成:
三、まとめ
上の方法でやって、問題は解決しました.どうせ今のところ私は大丈夫だと自測しているから、問題があったらまた話しましょう.ハハハハ.
実はこの中でいくつかのエピソードが発生して、私は分かち合うことができると思います:
1、最初は403ページにジャンプしたが、結局私は変更し、403はジャンプしなかったが、404をジャンプした.この時、あなたはどのように問題を考えますか?どうせ私が考えているのは、403を404にジャンプできる以上、私は必ずそれを私が行きたい場所にジャンプさせることができて、私は成功まで最後の点しかありません.时には、最も怖いのはバグが変わったのではなく、あなたがどのように変えても、そのバグは変わったことがありません.これは何を意味しているか知っていますか.
2、私は时々感じて、私は心の中の変态で、私が特にシステムが大きいバグを出すことを望んでいるため、最も良いのはあのような、手のつけられないバグです.この考えはよくない,私は改めなければならない.
3、私は、バグを直すのはとても達成感と幸福感のあることだと思います.私は以前は苦い穴を掘っていましたが、今は幸せな穴を掘って、それから幸せな穴を埋めています.私はバグを直すのがとても楽しくて、やはり生まれつきの苦労、一生の私达....
転載先:https://www.cnblogs.com/hhx626/p/8320396.html
問題点:tokenの期限切れ
一、問題についての考え方
1,私は书いたログインロジックに问题があるかどうかを考えて、コードで现在のログインページの関连キャッシュの问题を制御して、ずっとコードと.はい、一部の工事は権限がなくて言わないで、それから同僚は私にまた論理にジャンプしていないはずだと教えて、死んでしまいました.私はログインページでそのsecurityのマーク(当時はそれが何なのか全然知らなかった、バカX)を見つけて、調べて、同僚と具体的な状況を理解して、論理に対する疑いを断固として放棄しました.私たちはコードでキャッシュの失効を制御していないからです.
2,ユーザコードの問題ではない以上,コンポーネントメカニズムの問題である.赤ちゃんはすぐにspring securityのドキュメントをめくって、本当にタイムアウトの概念に言及しました.リンクアドレスは次のような一元化されたソリューションが提案されています.https://docs.spring.io/spring-security/site/docs/4.1.3.RELEASE/reference/htmlsingle/#csrf-timeoutsいいでしょう.JS関数を使用して、フォームの提出前にtoken値(springで提供されたCsrfTokenArgumentResolverを使用することによって)を取得することについて説明していますが、赤ちゃんはこの時点でバグとは言えない提案されたバグをやめません.また、カスタム処理に関する異常の提案についても言及しています.しかし、私の赤ちゃんはいつも自分を守る人ではありません.やっとバグを作ったので、しばらく振り回さないと、天罰を受けます.以下は私の赤ちゃんの検証演算の案の例です.
a:もともとspring securityの安全保護メカニズムで、バグではなく、テストと製品と協議し、それを無視しています.ハハ、もちろんこれは下策です.最も手間が省けますが、99%が死ぬと予想しています.
b:滞在時間が長すぎて発生した問題である以上、ユーザーがいつログインをクリックしても、彼が口座情報を入力したばかりのように工夫します.だから私は考えました:HTTP-EQUIV=“REFRESH”CONTENT=“csrf_timeout_in_seconds”>しかし、私のケースの中で、役に立たないで、悲しんでいます.
c:token登録機を使って、時代遅れのものを作って、登録ページに使います.ハハ、私はとてもいいと思います.もうだめだ、このtokenの期限切れに関するコードを見つけて、それを変えた--やはりコードを書くのが死ぬ精神だ.
d:私を怒らせて、私はこのcsrfのtoken検証機能を消します——簡単で乱暴でしょう、へへへ——もちろん、これはできないことを決めて、私のそのバグを解決することができますが
e:とにかく異常が発生して、システムはブロックして、それから指定の403ページにジャンプして、それでは私はそれが403ページにジャンプする前に、この異常を遮断して、それから私がカスタマイズして処理します
f:これは実はd条と似ています.私はすべての検証を消すことができない以上、ログインページの検証総行を消しましょう.ログインページの検証はもともとこのページではなく、ユーザーの権限です.誰でもログインページに入ることができるのではないでしょうか、へへ.そして、当赤ちゃんはブロッキングを書き換え、ログインページのリクエストを流しました.--しかし、人柄に問題があるのか、私は正常にログインできなくて、悲しんでいます.どこか私に書き間違えられたに違いない.
実は私の考えは多くて、いつも1つのこのバグを乾かすことができて、何度も悲しんだ后で、私はカスタムの异常なブロックのこのような方案を选んで、この线の考えは:ブレークポイント、それが403にジャンプする前に见て、いったいどんな异常をブロックしました;異常を見つけて、私はカスタマイズして遮断して、そして私がシステムにしたい反応をします
二、キーコード
カスタム例外処理:
import org.springframework.security.access.AccessDeniedException;
import org.springframework.security.web.access.AccessDeniedHandlerImpl;
import org.springframework.security.web.csrf.MissingCsrfTokenException;
import org.springframework.security.web.savedrequest.HttpSessionRequestCache;
import org.springframework.security.web.savedrequest.RequestCache;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import java.io.IOException;
/**
* @author ~Angelina
*/
public class MissingCsrfTokenAccessDeniedHandler extends AccessDeniedHandlerImpl {
private RequestCache requestCache = new HttpSessionRequestCache();
private String loginPage = "/login";
@Override
public void handle(HttpServletRequest req, HttpServletResponse res, AccessDeniedException exception) throws IOException, ServletException {
if (exception instanceof MissingCsrfTokenException && isSessionInvalid(req)) {
requestCache.saveRequest(req, res);
req.getRequestDispatcher(loginPage).forward(req, res);
}
super.handle(req, res, exception);
}
private boolean isSessionInvalid(HttpServletRequest req) {
try {
HttpSession session = req.getSession(false);
return session == null || !req.isRequestedSessionIdValid();
}
catch (IllegalStateException ex) {
return true;
}
}
}はい、実はここでまた冗談を言いました.私は最初、転送をリダイレクトして、私は頼りにして、前はtokenが失って、今はパラメータ全体がなくなって、自分の心を絞め殺そうとしました.やはり長い間基礎コードを書かないで、手描きですね.
セキュリティ構成:
@Bean
public AccessDeniedHandler getAccessDeniedHandler() {
return new MissingCsrfTokenAccessDeniedHandler();
}
http.exceptionHandling().accessDeniedHandler(getAccessDeniedHandler());
三、まとめ
上の方法でやって、問題は解決しました.どうせ今のところ私は大丈夫だと自測しているから、問題があったらまた話しましょう.ハハハハ.
実はこの中でいくつかのエピソードが発生して、私は分かち合うことができると思います:
1、最初は403ページにジャンプしたが、結局私は変更し、403はジャンプしなかったが、404をジャンプした.この時、あなたはどのように問題を考えますか?どうせ私が考えているのは、403を404にジャンプできる以上、私は必ずそれを私が行きたい場所にジャンプさせることができて、私は成功まで最後の点しかありません.时には、最も怖いのはバグが変わったのではなく、あなたがどのように変えても、そのバグは変わったことがありません.これは何を意味しているか知っていますか.
2、私は时々感じて、私は心の中の変态で、私が特にシステムが大きいバグを出すことを望んでいるため、最も良いのはあのような、手のつけられないバグです.この考えはよくない,私は改めなければならない.
3、私は、バグを直すのはとても達成感と幸福感のあることだと思います.私は以前は苦い穴を掘っていましたが、今は幸せな穴を掘って、それから幸せな穴を埋めています.私はバグを直すのがとても楽しくて、やはり生まれつきの苦労、一生の私达....
転載先:https://www.cnblogs.com/hhx626/p/8320396.html