Comments (7)
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()
.
from django-browserid.
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.
from django-browserid.
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?
from django-browserid.
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):
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.
from django-browserid.
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.
from django-browserid.
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.
from django-browserid.
This isn't completely solved, but it's solved enough for me to release a new version.
from django-browserid.
Related Issues (20)
- Document context processor removal in upgrade docs HOT 4
- csrftoken cookie not set by Django for most views HOT 4
- Impossible to override the redirect URL
- CsrfToken view should not be cached
- Use stateless Persona API HOT 1
- Updates to Goldilocks API HOT 2
- Docs for Custom User Model are a bit screwy HOT 2
- Disable autologin.js when BROWSERID_AUTOLOGIN_ENABLED = False even if it on the page. HOT 1
- Template tag browserid_logout breaks when link_class attribute is set HOT 2
- SSL certificate error HOT 3
- [Errno 32] Broken pipe on POST to /browserid/login/ and /browserid/csrf/ HOT 3
- The fancy_tag library isn't actually necessary HOT 4
- CSRF token fetching does not work with Django 1.8 HOT 4
- Document how to add a DTL template engine for 1.8 sites HOT 4
- Removal of /info/ endpoint causes problems for sites not using Django templating HOT 5
- Internet Explorer 11 specific error: "Relay frame could not be found " HOT 6
- Django 1.9 compatibility HOT 1
- Provide wheel package on PyPI HOT 11
- Django 1.8+ deprecation warning for urlpatterns in urls.py:28
- Verify.success_url never used with {% browserid_login %} HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from django-browserid.