iFrame redirection not working #197
Comments
|
Clarification, we are being redirected from https://labtastic.bi.hc1.com/MIPreDashboard.i4 to https://www.hc1cas.com/ in the iframe, we were just expecting that we would not be asked to re-authenticate in the iframe context. We would expect the cookie in the container to not be blocked in the iframe in this case since the sites are related. |
|
Can you confirm that your iframe is calling Related Website Sets does not make cookies available by default within the set; it just allows sites within the set to skip the Storage Access API's permission prompt. (See documentation.) So your iframe must call |
|
I have confirmed that we are not currently explicitly calling
document.RequestStorage() from the iFrame, but we have never had to
explicitly do that for this transfer to work. Are you saying that we MUST
do that when 3rd Party Cookies are disabled?
…On Wed, Jan 3, 2024 at 10:44 AM Chris Fredrickson ***@***.***> wrote:
Can you confirm that your iframe is calling
document.requestStorageAccess() appropriately?
Related Website Sets does not make cookies available *by default* within
the set; it just allows sites within the set to skip the Storage Access
API's permission prompt. (See documentation
<https://developers.google.com/privacy-sandbox/3pcd/related-website-sets-integration#related_website_sets_integration_details>.)
So your iframe must call document.requestStorageAccess() if it wants to
access its cookies.
—
Reply to this email directly, view it on GitHub
<#197 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A743YZ5XUCAO455EFSN237DYMV4GXAVCNFSM6AAAAABBKUV5Q2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZVGU3TINRZG4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
This e-mail message and any file transmitted with it is confidential to
the intended recipient and may contain confidential and or legally
privileged information. If you are not the intended recipient, you may not
copy, distribute or disclose the contents to anyone, nor take any action in
reliance on its contents. Should you receive this message in error, please
delete it and all copies of it from your system immediately, destroying any
hard copies and notifying the sender. Please note that any email sent to,
or from the hc1.com <http://hc1.com> domain may be monitored for content.
Virus checking is the responsibility of the recipient. hc1 Insights, Inc.
and Health Cloud Ventures, Inc. do not accept any legal responsibility for
the content of this message or any attachments.
|
Can you clarify what you mean by this - has this kind of flow worked for you in Chrome (while third-party cookies are blocked) without having to call
Yes*, in order for the Storage Access API (and therefore Related Website Sets) to allow you to access those cookies. This requirement is for security reasons (see discussion here: privacycg/storage-access#113). I recognize that this requirement is restrictive, so I've proposed https://github.com/cfredric/storage-access-headers to improve ergonomics and utility without regressing security. Please take a look and let me know if that would help your use case. *Chrome is also implementing some heuristics (https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/yGhI6iTAfeA/m/Z4DR3K23AQAJ) to implicitly restore access to third-party cookies in some limited cases. But these heuristics may not apply to your usage patterns, don't have anything to do with Related Website Sets, and may or may not work the same in every browser, so you may choose not to rely on them. |
|
We have operated this way for a long time. We are seeing this when we
disable 3pc as part of testing in preparation for them being deprecated. So
for clarity, we work fine when 3pc are allowed, and are not able to work
when they are disabled. If we must add an explicit call to request storage
because 3pc deprecation forces it we can.
…On Wed, Jan 3, 2024 at 16:29 Chris Fredrickson ***@***.***> wrote:
we are not currently explicitly calling document.RequestStorage() from the
iFrame, but we have never had to explicitly do that for this transfer to
work.
Can you clarify what you mean by this - has this kind of flow worked for
you in Chrome (while third-party cookies are blocked) without having to
call document.requestStorageAccess()? To my knowledge, that kind of flow
was never supported in Chrome.
Are you saying that we MUST do that when 3rd Party Cookies are disabled?
Yes*, in order for the Storage Access API (and therefore Related Website
Sets) to allow you to access those cookies. This requirement is for
security reasons (see discussion here: privacycg/storage-access#113
<privacycg/storage-access#113>).
I recognize that this requirement is restrictive, so I've proposed
https://github.com/cfredric/storage-access-headers to improve ergonomics
and utility without regressing security. Please take a look and let me know
if that would help your use case.
*Chrome is also implementing some heuristics (
https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/yGhI6iTAfeA/m/Z4DR3K23AQAJ)
to implicitly restore access to third-party cookies in some limited cases.
But these heuristics may not apply to your usage patterns, don't have
anything to do with Related Website Sets, and may or may not work the same
in every browser, so you may choose not to rely on them.
—
Reply to this email directly, view it on GitHub
<#197 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A743YZ7ZNH6HT67OJDFB6STYMXESBAVCNFSM6AAAAABBKUV5Q2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZVHE4TMMBSHE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
This e-mail message and any file transmitted with it is confidential to
the intended recipient and may contain confidential and or legally
privileged information. If you are not the intended recipient, you may not
copy, distribute or disclose the contents to anyone, nor take any action in
reliance on its contents. Should you receive this message in error, please
delete it and all copies of it from your system immediately, destroying any
hard copies and notifying the sender. Please note that any email sent to,
or from the hc1.com <http://hc1.com> domain may be monitored for content.
Virus checking is the responsibility of the recipient. hc1 Insights, Inc.
and Health Cloud Ventures, Inc. do not accept any legal responsibility for
the content of this message or any attachments.
|
|
Thanks for the clarification. In that case I think this is working as expected from Chrome's point of view; if you update your iframe to call Closing. |
We have updated our well-know sites JSON to align with the guidance provided but we are running into a redirection problem that we are unsure how to resolve.
We have this defined (currently what we see showing up when looking at chrome://system/ under the Related Website Sets):
{
"AssociatedSites": [ "https://hc1.global" ],
"PrimarySites": [ "https://hc1.com" ],
"ServiceSites": [ "https://hc1cas.com", "https://hc1cas.global" ]
}
But we have the following situation (example):
Launch https://labtastic.hc1.com/
Inside of that, there is an iFramed page that references https://labtastic.bi.hc1.com/MIPreDashboard.i4 this url redirects to https://www.hc1cas.com/ for authentication.
When we launch this in the iFrame, we are not being redirected from the https://labtastic.bi.hc1.com/ url BUT if we launch https://labtastic.bi.hc1.com/ from another browser, it will redirect.
Is there something further we need to define for this to work properly in an iFramed context?
The text was updated successfully, but these errors were encountered: