Firefox 15 caches assertions, which can result in an infinite loop about django-browserid

[seanmonstar]

Indeed, since the user has a session with Persona, and that email address is sent back to watch as the loggedInUser param, Persona will keep letting you know the user is trying to login.

If you use an XHR to submit your login form, you could handle the error case by calling navigator.id.logout().

[yourcelf]

Hmm; looks like it's slightly worse than I thought, once I pared down my implementation: naviagor.id.logout() no-ops until the GET's to https://login.persona.org/wsapi/session_context and https://login.persona.org/wsapi/list_emails return, which is after document.ready. So if I do a full page load and not an XHR to submit the login form, I need to register a listener to onlogin which logs the user out then, and not load browserid.js from django-browserid at all.

This means I can't use {{ form.media }} to load the BrowserID shim; I have to do it manually. And having a signin button on that page won't go, unless I write browserid.js into the page after after logout has succeeded.

[Osmose]

Yeah, not a huge fan of this behavior; IMO "stay logged in" should be implemented by a long-lived session, while the onlogin callback should represent a user action. It'd be nicer if BrowserID exposed a user's desire to be remembered as a flag rather than auto-login on visit. It'd save a request per visit.

One thing we could do is have the failure redirect include a url parameter like ?loginfailed that the JS could read, and if it's present it would ignore the first onlogin callback. The only problem this might encounter is if a site uses a failure URL that itself redirects without preserving the GET parameters, but this is enough of an edge case that I'm okay just adding a note to the docs about it.

Thoughts?

[yourcelf]

Another approach, rather than work with potentially fragile GET params, would be to add a field to BrowserIDForm which is present only if a logout is desired or failed. For example (note I haven't tested this implementation):

yourcelf@b679ca2

This strategy only works, however, if every browser will reliably trigger "onlogin" if the user has an active persona session. I didn't test super extensively, but when first exploring this issue, it seemed that Chromium 19 wasn't always triggering onlogin. If a browser doesn't trigger "onlogin", then a hack like this (or the GET param version) will result in the user's first attempt to legitimately log in will no-op.

[Osmose]

I don't quite understand how not triggering onlogin will break either of our solutions: If a user visit the site and onlogin isn't triggered, both of our solutions will work fine, as all they do is stop automatic login after a login failure. The first login attempt always works, whether it is automatic or manual.

Nice patch! The only two small issues I have with adding a field to the form are that it requires sites to support anonymous sessions to work, and it's a more complex implementation. IMO it's worth living with the rare edge cases for a more straightforward implementation.

[yourcelf]

Ah, I think I figured out why Chromium wasn't calling onlogin for me -- I had it set to disallow third-party localstorage, and so the session with persona was not cached. As long as login works the first time, the top level site's cookie retains the local session without retaining the persona session.

The issue is distinguishing "automatic login" from user-initiated login (as you mentioned, it would be nice if onlogin always represented a user action, but it doesn't). If a browser doesn't call onlogin at first (e.g. through disabled 3rd party storage), then a user's first signin attempt becomes the first "automatic" one and gets suppressed. Unless you went down the ugly road of timeouts or some such.... or if the signin button click could be bound to a callback which said "I'm really a user action!". But that would lose some flexibility of implementation of the sign in button.

IMHO, I'd prefer if the browserid shim did not attempt to talk to mozilla persona at all unless explicitly invoked. I don't see the point of caching persona's session in the context of the BrowserID consuming site -- the consuming site could always set its own cookie/storage to represent the session if it wanted to. In the context of the Django implementation, that automatic action is redundant at best, and leads to problems as well. It forces you to logout from two session stores instead of just one.

[Osmose]

This isn't completely solved, but it's solved enough for me to release a new version.