Don't use cached user if session has been reset #79
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a bit of an edge case, but if the user is logged in and then the session is reset (or at least its
current_uservalue is reset) andRpiAuth::Controllers::CurrentUser#current_useris called within the same request, then previously it would have returned the user "cached" in the@current_user. Now it will returnnilwhich seems less surprising.This was highlighted by this example in code-club-frontend. In that case the example passes, because that app has its own implementation of
#current_user. However, when I added a similar example in experience-cs where we're usingRpiAuth::Controllers::CurrentUser#current_user, the example failed.I've added a rather contrived example by adding a new
HomeController#reset_useraction to the dummy app used in the specs. However, hopefully it helps explain a bit about why the change is necessary.It looks as if the only two RPF repos that use
RpiAuth::Controllers::CurrentUserare experience-ai here and here and experience-cs. I'm pretty confident this change won't affect either of those apps, so this can probably be a minor version bump.I think a possible alternative to making this change would be to provide a
#reset_usermethod which could both reset the session and reset the ivar-cached user. However, given that the code-club-frontend implementation already uses this approach, I think that probably makes more sense for now.