Third party cookies blocked on iframe
Julien Gribonvald
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
--
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.