-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HttpSessionOAuth2AuthorizationRequestRepository storing one OAuth2AuthorizationRequest #9649
HttpSessionOAuth2AuthorizationRequestRepository storing one OAuth2AuthorizationRequest #9649
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @candrews.
The solution is quite simple. Instead of storing multiple OAuth2AuthorizationRequest
in HttpSession
, we store a single one only.
This would break existing applications if the backing store is external from the container. So to restore the current behaviour we need a way for applications to revert to this. So let's add this to HttpSessionOAuth2AuthorizationRequestRepository
:
@Deprecated
public final void setAllowMultipleAuthorizationRequests(boolean allowMultipleAuthorizationRequests) {
...
}
NOTE: The default will store a single OAuth2AuthorizationRequest
.
Makes sense?
* @see AuthorizationRequestRepository | ||
* @see OAuth2AuthorizationRequest | ||
*/ | ||
public final class OldHttpSessionOAuth2AuthorizationRequestRepository |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove this as all changes will be contained in HttpSessionOAuth2AuthorizationRequestRepository
7e2ea57
to
5187280
Compare
That sounds good to me. I've implemented that approach and updated this PR. |
@jgrandja what do you think? 🤞 this finally does it! |
5187280
to
e1fef10
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the updates @candrews. Please see review comment.
Also, please update copyright year. Thanks.
authorizationRequests = this.getAuthorizationRequests(request); | ||
} | ||
else { | ||
authorizationRequests = new HashMap<>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default behaviour should store a single OAuth2AuthorizationRequest
in session NOT a single entry in Map
. Map
is used only when allowMultipleAuthorizationRequests == true
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought of that too. But that would make the serialization data incompatible; if a user switched between allowMultipleAuthorizationRequests
then they would get lots of warnings logged. Maybe that's a small annoyance, but it still seems to be an issue that would best be avoided. That approach also requires more changes which seems contrary to your preference oo keep the fix as minimal as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jgrandja ping
I'd really like to get this work completed... can you please provide me the guidance necessary for that to happen?
Thank you again!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies for the delay @candrews. I have a lot of things I'm juggling so I'm just rotating through my priorities. I'll get to this tomorrow. Thanks for your patience.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also have a bunch of priorities, all conflicting and all urgent - I guess that's just how it goes :) Thank you for your continued attention to this issue, I greatly appreciate the opportunity to address it with you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for thinking about passivity. However, I'd like to consider that we are also deprecating and thus removing setAllowMultipleAuthorizationRequests
at some point. At that time, if there are values persisted as a Map
, user applications will break when they update. This is not a huge deal since we will remove the deprecated method on a major release, but it is not ideal.
Instead, I'd prefer to read the session attribute and do an instanceof
check. If it is a Map the code when the look up the proper value in the Map. Otherwise it would use the OAuth2AuthorizationRequest
found in the session.
When saving, we would always save according to the allowMultipleAuthorizationRequests
property.
This has the advantage that if users are not leveraging the deprecated setAllowMultipleAuthorizationRequests
, then they can expect that an update to Spring Security 6 will be unlikely to cause a ClassCastException
when they update to it. We also don't need any special code in Spring Security 6 to handle this scenario.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
private HttpSessionOAuth2AuthorizationRequestRepository authorizationRequestRepository; | ||
|
||
@Before | ||
public void beforeEach() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rename to setup()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
82b8ef9
to
9f21c76
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the pull request and your patience. I've provided feedback inline.
...ingframework/security/oauth2/client/web/HttpSessionOAuth2AuthorizationRequestRepository.java
Outdated
Show resolved
Hide resolved
authorizationRequests = this.getAuthorizationRequests(request); | ||
} | ||
else { | ||
authorizationRequests = new HashMap<>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for thinking about passivity. However, I'd like to consider that we are also deprecating and thus removing setAllowMultipleAuthorizationRequests
at some point. At that time, if there are values persisted as a Map
, user applications will break when they update. This is not a huge deal since we will remove the deprecated method on a major release, but it is not ideal.
Instead, I'd prefer to read the session attribute and do an instanceof
check. If it is a Map the code when the look up the proper value in the Map. Otherwise it would use the OAuth2AuthorizationRequest
found in the session.
When saving, we would always save according to the allowMultipleAuthorizationRequests
property.
This has the advantage that if users are not leveraging the deprecated setAllowMultipleAuthorizationRequests
, then they can expect that an update to Spring Security 6 will be unlikely to cause a ClassCastException
when they update to it. We also don't need any special code in Spring Security 6 to handle this scenario.
Thanks for that additional information. I think I've now updated this PR with that change. The approach I've taken creates a new |
9f21c76
to
b618cf9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see the feedback inline
...ingframework/security/oauth2/client/web/HttpSessionOAuth2AuthorizationRequestRepository.java
Outdated
Show resolved
Hide resolved
...ingframework/security/oauth2/client/web/HttpSessionOAuth2AuthorizationRequestRepository.java
Outdated
Show resolved
Hide resolved
...amework/security/oauth2/client/web/HttpSessionOAuth2AuthorizationRequestRepositoryTests.java
Outdated
Show resolved
Hide resolved
… default Add setAllowMultipleAuthorizationRequests allowing applications to revert to the previous functionality should they need to do so. Closes spring-projectsgh-5145 Intentionally regresses spring-projectsgh-5110
b618cf9
to
ba5157a
Compare
…questRepository WebFlux version of spring-projectsgh-9649
…questRepository Related to spring-projectsgh-9649 Closes spring-projectsgh-9857 Closes spring-projectsgh-9912
…questRepository Related to spring-projectsgh-9649 Closes spring-projectsgh-9857
Uses the same class name so users get this implementation by default,
whether they're specifying an AuthorizationRequestRepository or relying on
Spring Security defaults.
Note that this implementation intentionally does not handle multiple
OAuth2AuthorizationRequest's per session, regressing gh-5110
Closes gh-5145
FYI @jgrandja @rwinch