-
Notifications
You must be signed in to change notification settings - Fork 61
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
FPS - embedded use case is not working as expected #161
Comments
@jagadeeshaby Thanks for testing out the feature! I have a couple of clarification questions for you:
|
I just realized that this could be a potential use-case for #94? |
I believe Chips aren't optional so yes i went with
Was testing both the scenarios, in production we have the popup model, here is how it works a) scenario 1 - site11.com embeds connect11.com -> and connect11.com opens a login popup hosted on connec11.com/login and it sets a cookie under connect11.com partition key. b) scenario 2 - site 11.com embeds connect11.com -> and connect11.com does make use of iframe to invoke connect11.com/login and completes the process and eventually removes it from DOM -> in this case cookie is set on site11.com partition. |
Hi @jagadeeshaby, thanks for the detailed description, another question:
I assume you meant "site22.com embeds connect11.com" here? If so, are you saying that the iframe just assumes that connect11.com had previously gotten a cookie? What happens if site22.com is visited before site11.com? |
the use case i'm trying to test is about our enterprise customers having 2 top level sites which embeds the SaaS app. So in this case both site11.com and site22.com would embed connect11.com. Typical working model here would be - in few cases customer go to site11.com first and from their to seek help they may head over to site22.com or vice versa.
The way i was thinking about this is -> will have a restful endpoint on connect11.com which would indicate whether there is a cookie exists or not, based on that i would go ahead and trigger iframe login process and repeat the same flow. |
I see! So, if the cookie is not there then on both sites it will fall back to opening the popup? Based on your description it sounds like an "implicit" login through connect11.com, e.g. immediately when the user loads site22.com would be difficult to reconcile with the new privacy boundaries established by our APIs. However, given that this seems to be a login flow where the user has to interact with the iframe anyway (for the initial login), you can make it smoother for them the second time around by just calling requestStorageAccess(), fetching the credentialed cookies after that was granted and not showing the sign-in popup then. Does that make sense? |
Yup exactly!!!
It seems like there is a missing co-ordination between how FPS + Chips + Storage partition are working currently. To add in more details: here is the current production use case for my customer
The way it's working today is - customer opens site11.com which loads the embedded connect11.com. and connect11.com opens up a login popup and spins up a shared worker and all works happily. customer could either navigate to site22.com or open multiple site11.com all works. with Privacy sandbox proposals , here is how i'm thinking about the new flow
would now add partition into the login cookie, most likely to adopt to CHIPs - connect11.com now needs to do the login process in an hidden iframe so that the cookies are set against the site11.com and the embedded connect11.com would continue to have access to cookie and works
As you can see above FPS + CHIPS + storage partition are not working together and making it difficult to support our customer use cases. Is there known issue chrome is tracking on this and how is chrome thinking about addressing these differences? |
That's what i would like to avoid and make use of FPS proposal instead.
this one didn't work well with CHIPS unfortunately. is that a known issue? read my above comment for the detailed explanation on this |
So, I don't think that this will solve your SharedWorker access, but since you're using requestStorageAccess I think your flow should work if you just don't use CHIPS, i.e. don't flag your cookies as Partitioned. I'm honestly not sure if CHIPS is what you need here given that your users seem to visit connect11.com as a top-level document (in the pop-up). For the SharedWorker case, this may be something we should track and discuss separately, I think it's related to privacycg/storage-access#157 @jagadeeshaby I have another ask: On Chrome side, we'd like to track non-trivial broken use cases like this one, would you mind filing a new bug here (you can either add another description or link to the description in this issue)? It would be great if there was some real-world site you could link to as an example, but it's fine if not. This will help us keep track of your issue (though we're also happy to discuss here to the extent that FPS can help you). |
Popup is only for the login flow and used only as a workaround to handle the limitations with some of the IdPs (identify providers) as they doesn't work in an embedded context. Regarding Chips usage - i don't think we have an option here as connect11.com is an embedded app on the enterprise domains. ( runs within the third party context)
yeah i have raised an issue here wanderview/quota-storage-partitioning#6 , probably will tag the same on the issue you called out
Sure will cut one and share it here. |
Right, I'm saying that if you first call (and await) requestStorageAccess() you may use third party cookies inside the iframe without CHIPS. It does need a user gesture but for browsers with First-Party Sets it would automatically resolve without a prompt or anything. So this seems like the easiest path forward, assuming you can make the user click a button on first visit of both site11.com and site22.com. This is likely also the easiest way to ensure Shared Worker support once we figure out privacycg/storage-access#157. |
Make sense, let me try that out. Here is the Chrome bug - https://issuetracker.google.com/issues/288288924 |
Unfortunately this seems to be in a component that isn't made accessible by its admins (not even to our team inside of Google), I should have given you the better link which is https://issuetracker.google.com/issues/new?component=1306484&template=1777152. Could you either move your bug to the "Public Trackers > Third Party Cookie Breakage Issue Repository" component or file a new bug under that link and paste in your previous description? Thanks and sorry for the hassle. :) |
I have a situation where i'm not able to test the FPS for one of the core use cases. details are below
I have 2 top level sites www.site11.com and www.site22.com and both of them embeds www.connect11.com website, and now when i first visit www.site11.com , i could go ahead and login to www.connect11.com and everything works, and then i try visiting to set22.com which doesn't seem have access to the login credentials which were set earlier.
My understanding so far
open -a "Google chrome" --args --enable-features="FirstPartySets:FirstPartySetsClearSiteDataOnChangedSets/1,StorageAccessAPI,StorageAccessAPIForOriginExtension,PageInfoCookiesSubpage,PrivacySandboxFirstPartySetsUI" \ --use-first-party-set="{\"primary\": \"https://www.site11.com\", \"associatedSites\": [\"https://www.site22.com\"]}" \ https://www.site22.com:2000
but couldn't get the seamless login to work between the 2 top level sites for the embedded widget.
Are there any pointer here on how to fix this setup, i did use storage access APIs to grant access but didn't work.
Note: i could get this working if i associate connect11.com as a associatedSites which i would like to avoid as it's a SasS solution which provides embedded chat widget functionality
The text was updated successfully, but these errors were encountered: