Skip to content
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

FR: Request header to indicate storage access #130

Open
lghall opened this issue Oct 24, 2022 · 8 comments
Open

FR: Request header to indicate storage access #130

lghall opened this issue Oct 24, 2022 · 8 comments
Labels
future Will consider for a future revision

Comments

@lghall
Copy link

lghall commented Oct 24, 2022

Currently, the server has no way of knowing whether a particular document request was initiated from an iframe without storage access. Many applications wish to serve a different page when the requested frame does not have storage access, to prompt the user for access (for example, we do this in Google Docs on Safari and Firefox). Currently, we’re forced to do this check on the client. It would be preferable if there could be a request header indicating whether the given request is from a context that does not have storage access.

@annevk
Copy link
Collaborator

annevk commented Oct 24, 2022

Can't you tell this from a cookie?

@lghall
Copy link
Author

lghall commented Oct 24, 2022

Maybe I'm misunderstanding the suggestion, but we want to disambiguate between "The user is not logged in" and "The request is coming from a frame without storage access".

@annevk
Copy link
Collaborator

annevk commented Oct 24, 2022

If you use a different cookie for "got storage access" and "got storage access and user logged in" that seems possible to achieve. One thing that might be tricky is identifying a partitioned context. w3c/webappsec-fetch-metadata#80 and variants aim to address that, although not much progress has been made recently.

@cfredric
Copy link
Contributor

If I understand correctly, a cookie-based approach doesn't really solve the problem @lghall is describing, since the server would have no way to distinguish a new user (or new device) which doesn't yet have cookies from an existing user/device that just hasn't granted storage access yet.

My first thoughts for this issue are of:

  1. Fetch Metadata
  2. User-Agent Client Hints

Adding a new Fetch metadata header would work AFAIK, but would mean the browser always leaks the "has storage access" bit (which may be fine, since its value would change so often). A new UA-CH header would require an extra round-trip, but would avoid leaking that bit by default.

@miketaylr
Copy link

User-Agent Client Hints

(nit: this would probably just be a client hint, not a user-agent client hint - since it has nothing to do with the User-Agent string)

@cfredric
Copy link
Contributor

Hi - I've published a proposal for HTTP request/response headers that I believe would satisfy this feature request: https://github.com/cfredric/storage-access-headers

Please take a look and let me know if that proposal would be helpful for this, and/or how it could be improved!

@DavidScales
Copy link

I share the underlying issue here (which is also partially captured in #189 ) for Google Classroom add-ons (3P EdTech embeds in classroom.google.com). @cfredric has already captured the problem description accurately in explainer.

@remko
Copy link

remko commented Jan 4, 2024

Our EdTech tool is embedded in several contexts, including Google Classroom add-on (as @DavidScales mentioned).

I want to confirm that @cfredric 's proposal looks good to us:

  • For our Google Classroom add-on, "Key Scenario 1" would apply, because we want to restore previously authenticated sessions (without the client-side check first) so we don't need to go through the sign-in flow for these.
  • We are also embedded as an LTI tool. LTI is basically an IdP-initiated OpenID connect flow in an iframe. The difference between this flow and the add-on flow is that the iframe needs to first redirect from our domain back to the IdP domain before being redirected back to our domain. We need to preserve a cookie across this redirect (amongst others for CSRF mitigation). This means "Key scenario 2" also applies to us.

One thing I wanted to point out is that the LTI flow's final step can be a form POST instead of a GET, i'm not sure if this has an impact on the retry behaviour.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
future Will consider for a future revision
Projects
None yet
Development

No branches or pull requests

6 participants