Firefox bug on LocalStorage (i.e. idp.storage.htmlLocalStorage=true)
Takeshi NISHIMURA
takeshi at nii.ac.jp
Mon Jul 16 22:41:06 EDT 2018
Simple reproducible steps:
1. Select "Keep until: I close Firefox" in cookie preference.
2. Confirm you are in multi-process mode.
3. Authenticate with your IdP.
4. Open another tab and invalidate JSESSIONID.
5. Re-authenticate in the new tab.
6. Repeat step 4 and 5.
If you see a login prompt in step 5, maybe you hit the browser bug I mentioned.
For step 4, I made a simple JSP file (attached). Place in edit-webapp/ and rebuild. Then you can access
https://idp.example.org/idp/xsession.jsp
to invalidate JSESSIONID (more precisely servlet session).
If your IdP is in a cluster, you may not need step 4. That step is there because a non-clustered IdP ignores LocalStorage data when JSESSIONID is in effect. (by default in 30 minutes)
> Plausibly it may be this bug?
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1453699
Yes. Also the following bug is the same though its title denotes opposite.
https://bugzilla.mozilla.org/show_bug.cgi?id=1436231
Private browsing RFE is here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1410701
On 2018/07/17 5:19, Cantor, Scott wrote:
>> If you have a trouble with Firefox 61.0/61.0.1 and with Shibboleth IdP
>> configuration idp.storage.htmlLocalStorage=true, it may be caused by Firefox
>> bug.
>
> Plausibly it may be this bug?
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1453699
>
>> I found LocalStorage provides out of sync data (stale or empty) if:
>> 1. multi processes (e10s) used
>> and
>> 2. cookie preference "Keep until: I close Firefox" is selected
>
> I think it's kind of the opposite. It seems be an issue with tabs started up later picking up the updated data. When I set the cookie option to that, I was definitely getting unwarranted login prompts in new tabs. I set it back to see if it's observationally any different, but I'm not sure the cookie setting actually matters if that's the relevant bug. If it does, it may be worth noting in that bug as a comment, they may not have made the connection to that setting.
>
> -- Scott
-------------- next part --------------
<%
request.getSession(false).invalidate();
%>
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Session Invalidated</title>
</head>
<body>
</body>
</html>
More information about the users
mailing list