Allow WORKING_COOKIES on cross-site requests#61
Merged
Conversation
Browsers often ignore or withhold cookies on cross-site requests unless they are marked explicitly for that use. WORKING_COOKIES may be used in an embedded cross-site LTI launch. Marking it SameSite=None; Secure allows browsers to include it in that third-party context, where the default cookie policy would otherwise prevent it from being sent. This improves compatibility, though some browsers may still block third-party cookies.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates how the WORKING_COOKIES marker cookie is issued so that it can be sent in embedded / third-party (cross-site) LTI launch flows by explicitly setting SameSite=None; Secure. This aligns the cookie behavior with modern browser cross-site cookie requirements and adds a regression test to validate the cookie attributes.
Changes:
- Set
SameSite=Noneon theWORKING_COOKIEScookie when marking a session as working. - Extend the Step 3 stateful test to assert cookie attributes (value, path, Secure, HttpOnly, SameSite).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
src/main/java/uk/ac/ox/ctl/lti13/security/oauth2/client/lti/web/OptimisticAuthorizationRequestRepository.java |
Marks WORKING_COOKIES as cross-site capable via SameSite=None and updates related inline documentation. |
src/test/java/uk/ac/ox/ctl/lti13/stateful/Lti13Step3Test.java |
Adds assertions to ensure the WORKING_COOKIES cookie is emitted with the intended security and SameSite attributes. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+11
to
+14
| * Checks to see if we already have a valid HTTP Session containing a token, if so we store details of the login | ||
| * in the HTTP Session, otherwise we use store based on the state. | ||
| * in the HTTP Session, otherwise we use store based on the state. When debugging things you can tell on the client if | ||
| * the login was done using the session as the redirect to the tool in step 3 is done as a HTTP 302 redirect, if the | ||
| * check is done by the browser using LTI Storage the step 3 is a HTTP 200 response where JS does the redirect. |
Contributor
There was a problem hiding this comment.
Updated the class Javadoc for grammar and clarity, and removed the trailing whitespace in commit 747c88a.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
sebastianchristopher
approved these changes
Jun 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Browsers often ignore or withhold cookies on cross-site requests unless they are marked explicitly for that use.
WORKING_COOKIES may be used in an embedded cross-site LTI launch. Marking it SameSite=None; Secure allows browsers to include it in that third-party context, where the default cookie policy would otherwise prevent it from being sent. This improves compatibility, though some browsers may still block third-party cookies.