Third party cookies blocked on iframe

14 views
Skip to first unread message

Julien Gribonvald

unread,
Jun 24, 2022, 4:04:38 AM6/24/22
to uport...@apereo.org

Hey folks,

I'm watching on the way we could beat some problems on browsers that blocking third party cookies now by default.

The main problem is mainly for iframe portlets that need an authentication, ie in details :

  • your portal is on domain A
  • your SSO CAS is on domain B
  • when accessing into the portal to an iframe app, even with the same domain than your portail, the auth on the iframed app won't be possible as the CAS (on which the app redirect into the frame) won't be able to access to his cookies as it's on domain B

That's the default comportment of all browsers now as they are on strict/blocking third party cookies by default, and users don't know easily what to do in this case. So we need to find a way that they don't need to change any configuration. We've documented how to create an exception that authorize cookies on domain B, but not a lot of users do the tips, and our indicators are showing less uses, so....


So to avoid this problem, the only ways to fix it for everyone, without any user action, is to open the iframe on his own window to init the auth (not as iframe) and so there are two choices:

- do the job into the app to redirect after auth to the iframe fname uPortal page

- provide the uPortal environment into the app (I mean integrating the uPortal header (title + menu) into the app, could be done with the esco-content-menu. But we need again some developments like for managing the portal session, the theming into the app, etc...


I exclude the webPorxyPortlet because it's not really efficient as it creates persistent connexions and it doesn't realease them efficiently, it cause a lot of trouve on heavy load, I just mean that's not efficient when having a large public, and in this case we need to deploy several servers (cost expansive).

Also I've experimented to open iframes with a popup window (with window.open() in JS), but that's not really usable for users as they need to accept popup, and some browsers don't manage that !


If anybody have other solution feel free to expose it/them ;)


Else on an other way, to apply any of the two solutions I would need to add an extra attribute to portlet definitions that would say how we should the alternativeMaximizedLink, but what do you think ? The attribute would be required for the href target, to fill values like "_blank", "_self", "_parent", "_top" and any custom framename value. The target "_blank" will be the default value to keep the default compatibility.

So what do you think about adding the attribute "alternativeMaximizedTarget" or maybe you prefer the name "alternativeMaximizedLinkTarget" ?


Thanks

-- 
Julien Gribonvald
Développeur Opérationnel
Service E-Éducation / Pôle Logiciels Libres
GIP RECIA

Benito Gonzalez

unread,
Jun 27, 2022, 12:19:03 PM6/27/22
to Julien Gribonvald, uport...@apereo.org
Hi Julien!

I like "alternativeMaximizedLinkTarget" as it an attribute of that eventual tag.

Best,
-bjagg

--
You received this message because you are subscribed to the Google Groups "uPortal Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uportal-dev...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/uportal-dev/54339f52-3d15-1347-6ab5-d5baef8eb6d4%40recia.fr.
Reply all
Reply to author
Forward
0 new messages