Opera 12 cookies question
-
A Former User last edited by
(Yeah, I know, it is old, but I still haven't found a sufficient replacement and it mostly works for the sites I visit.)
Does anyone have a more complete insight into Opera 12's cookie handling code? I am running it with cookies disabled and, when necessary, whitelist exceptions. But once in a while I encounter a site which I can't get to work no matter how much I try, unless I enable cookies (in Quick Preferences). It is particularly common with single-sign-on services, e.g. https://timetable.fit.cvut.cz redirects me to https://idp2.civ.cvut.cz/idp/Authn/UserPassword and I just can't figure how to set the cookies up so that the second page recognizes that cookies are enabled. I tried whitelisting (all cookies, including 3rd party) timetable.fit.cvut.cz and idp2.civ.cvut.cz, then I added fit.cvut.cz and civ.cvut.cz, even cvut.cz, but still no luck. In any of these setups, the Site Preferences tell me that cookies are enabled, but the actual websites fail to recognize this and complain that cookies are disabled. If I enable cookies generally, then the sites work fine, but I most certainly don't want to run with cookies enabled. If anyone can suggest a working whitelist-based setup, I would be quite interested in it. Thanks.
-
A Former User last edited by
No, I was under the impression that cvut.cz would be the same. But apparently it isn't, as I added *.cvut.cz now and it works! Thanks a lot!
-
A Former User last edited by
Hmm, seems my last message was a bit premature. It seems that I still don't quite understand how Opera 12 handles the cookies. I managed to get past the first barrier (*.cvut.cz helped there), but eventually I run into an endless redirection loop. Using Fiddler, I discovered that the problem apparently lies with handling Shibboleth's responses:
-
Opera makes a request to https://timetable.fit.cvut.cz/Shibboleth.sso/SAML2/POST which sends me a redirect and a cookie:
Set-Cookie: _shibsession_ID1=_ID2; path=/; secure
(the Set-Cookie header appears before the Location header, even, not that it should matter). -
Opera then makes a request to the redirect URL https://timetable.fit.cvut.cz/public/cz/ but without the cookie. Then I get redirected back to single sign on page, which notes that my cookie is valid and redirects me back to #1. If I enable all cookies in Quick Preferences, then the cookie
_shibsession_ID1
is present and I get the data I requested.
I just can't understand why the cookie from #1 doesn't get passed to #2. As far as I understand it, it should be valid for all https://timetable.fit.cvut.cz URLs and it doesn't have an expiration date. So why is Opera discarding it? Even when I enable cookies for cvut.cz, *.cvut.cz, fit.cvut.cz, *.fit.cvut.cz, timetable.fit.cvut.cz, *.timetable.fit.cvut.cz, which I did out of sheer frustration, because timetable.fit.cvut.cz should be sufficient. Could anyone shed some light into this, please? Thanks.
-
-
blackbird71 last edited by
Would there be a problem in simply using Site Preferences to enable all cookies just for the log-in site, rather than trying to get to the bottom of 'why' the cookie-handling does what it does? Given that Opera 12 is fast aging and nobody's developing Presto code any more, the prospects of getting any "expert" direction depend purely on a 'greybeard" expert passing by here who just happens to know the answer. I'm thinking in terms where triage may be the best way to go...
-
A Former User last edited by
I would be glad to. The problem is, I just can't figure WHAT to enter into Site Preferences to "enable all cookies just for the log-in site". I would say I did just that, and more, by enabling cookies for all levels of the domain, both exact match and wildcards, but still it doesn't work
-
blackbird71 last edited by
Try going to the log-in page, right click > Site Preferences > Cookies > Accept cookies> OK. If there is an immediate redirect after you enter your password that still blocks you, you may also have to do the same thing on that redirected page as well. If a redirected page gets past you too quickly, temporarily block redirection via ctrl+f12 > Advanced > Network > uncheck Enable automatic redirection > OK in order to set Site Prefs on that page as well (be sure to set it back to Enable after trying these things). My thinking is that there may be other verification cookies involved in the log-in process besides "site cookies" at that one or two particular sites.
-
A Former User last edited by
He could check it in history. My 11 usually keeps such BS at least in the tab's history.
-
A Former User last edited by
blackbird71: As I wrote above, I monitored all the requests in the login session to make sure I catch them all, IMO a much more reliable process than blocking redirects. All servers concerned were added to the Site Preferences, without any apparent effect. That's why I started studying the communication in more detail. The missing cookie I described above is the only discrepancy I found.