FPS - embedded use case is not working as expected
jagadeeshaby opened this issue · comments
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
- Connect11.com within site11.com would set a cookie on site11.com cookie partition and hence the same isn't available when i visit site22.com which make sense
- so to allow this access i used FPS by locally launching chrome by using below command
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
@jagadeeshaby Thanks for testing out the feature! I have a couple of clarification questions for you:
- Does Connect11.com use cookies or storage to save login credentials? If cookies, are they being set with the Partitioned attribute, or without?
- Could you say more about how the login flow is implemented? Is there a popup/top-level redirect to Connect11.com where the login happens, or is it only embedded in an iframe on site11.com and site22.com?
Does Connect11.com use cookies or storage to save login credentials? If cookies, are they being set with the Partitioned attribute, or without?
I believe Chips aren't optional so yes i went with Partitioned attribute for cookie
Could you say more about how the login flow is implemented? Is there a popup/top-level redirect to Connect11.com where the login happens, or is it only embedded in an iframe on site11.com and site22.com?
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:
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.
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?
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.
What happens if site22.com is visited before site11.com?
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?
I just realized that this could be a potential use-case for #94?
Yup exactly!!!
Looks like one my previous issue thread is more suited for this topic so copy pasting the same here.
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
- site11.com, site22.com are the enterprise customer domains
- connect11.com is a SaaS app which gets embedded on customer domains and it makes use of login cookies and also hosts a shared worker which basically acts a gatekeeper for managing audio, notification if there are multiple instances of this app open(meaning only one browser tab could be the owner for playing audio and the states are managed within shared worker) along with multiplexing backend requests and broadcasting the response on all the open tabs. Shared worker is mainly used to support seamless multi-tab use case.
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
Chips
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
Storage partition
- Strangely shared worker doesn't get access to cookies anymore as chips restricted cookies within a partition. It seems like shared worker is still looking into cookies set under connect11.com without a partition which would be null in my case. My expectation here was storage partition should also follow the same CHIPS model while retrieving the cookie for the embedded context which is to look up cookie based on the partition (site11.com, connect11.com) key instead of just (connect11.com)
- and if customer loads site22.com , now there are 2 shared worker spun up with the same name which is strange too because the whole point of shared worker is to avoid this - my expectation was to have the same logic in place as CHIPS while creating a new storage partition, in this case as site22.com is recognized as the FPS site , we should have connected to the same existing shared worker instead.
FPS
- i have declared the top level sites in a FPS list to support multi top site use cases (site11.com, site22.com) and used requestStorageAccess() methods to see if i can get hold of cookies on site22.com, unfortunately that didn't work as i presume it's due to CHIPS. even in here i anticipated FPS to work along side with CHIPS. meaning if there are FPS definitions found then on site22.com , look at cookies from primary domains (site11.com + connect11.com) and make it available for site22.com as well.
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?
I see! So, if the cookie is not there then on both sites it will fall back to opening the popup?
That's what i would like to avoid and make use of FPS proposal instead.
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.
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).
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)
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)
For the SharedWorker case, this may be something we should track and discuss separately, I think it's related to privacycg/storage-access#157
yeah i have raised an issue here wanderview/quota-storage-partitioning#6 , probably will tag the same on the issue you called out
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
Sure will cut one and share it here.
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)
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
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. :)