mozilla / django-browserid Goto Github PK

So the code for adding a logout button to a page won't work, because you get infinite redirects from include.js if you include it after the user has logged in (It'll try to login again).

Instead we could add a URL parameter like we do for failed logins that the JS can look for and trigger a logout with.

http://identity.mozilla.com/post/27122712140/new-feature-adding-your-websites-name-and-logo-to-the

Perhaps a view that returns JSON for:

$.get('/browserid/settings.json', function(data) {
navigator.id.request(data);
});

or use a data-browserid-settings attribute on #browserid that contains the settings structure?

There's two more common error cases that deserve some mention on the troubleshooting page:

1. If SESSION_COOKIE_SECURE is set to true on a local instance that isn't running HTTPS, when you attempt to log in nothing will happen because the cookie isn't sent over an http connection. Although this is a general auth problem, it happens often enough that we should mention it here.
2. If sessions are stored in the cache (as they often are in playdoh projects that use this and django-session-csrf) and you don't have a cache configured locally, login will fail silently. Again, it's a general problem that comes up often enough that it deserves mention.

Django apps can run under multiple domain names; there is no way currently for SITE_URL to support sites that use multiple domain names.

One option is to allow SITE_URL to be a callable. I can't think of any major cons except that at a basic level it doesn't handle sites that use the Django sites framework (which typically, from what I can tell from the docs, get the current domain from the request). It'd be nice if we could either provide the current request as an argument to the SITE_URL callable, or just support the sites framework by default if it is installed.

Any keyword arguments to BrowserIDBackend.authenticate are passed to verify as extra parameters. This might expose data that shouldn't be exposed, though. Instead, it'd be better to add an optional browserid_extra kwarg to authenticate that is passed to verify instead.

So it turns out navigator.id.watch takes the user's email as a parameter. We should probably pass that somehow.

Currently if a verification failure occurs it is just logged

log.error('BrowserID verification failure. Response: %r '
          'Audience: %r' % (result, audience))
log.error("BID assert: %r" % assertion)

There should be an option to return an error page

I've been getting errors like this:
http://cl.ly/LbAB

These are hack attempts. The BrowserIDForm should not allow assertions that aren't ascii.

If login fails, the user is redirected to a page with the bid_login_failed parameter. If the user tries to login again on this page, it will always fail because the JS code looks for that parameter and cancels if it finds it, even if the login is user-triggered.

The Creating User Accounts section explains how to do custom authentication and user creation.

The first line of source code

from django_browserid.auth import get_audience, verify

does not work as these are methods on a class, not functions of django_browserid.auth.

it is advised when Python string formatting to use the str.format() method, because the % string operator will soon be deprecated.

However replacing all instances of the % string operator with str.format() will drop support for Python 2.5.

Python 2.5 is not supported in Django 1.4+ or Django dev

I'm trying to add browserid authentication to a site I'm creating using django-browserid.

The login button I created following the documentation works fine in chrome, the popup shows up and I'm able to login, however when I click the login button using either firefox or IE nothing happens. I'm not sure how to go about debugging this problem.

The site is at https://database.randonneurs.bc.ca

Any pointers about how to start debugging would be great, thanks!
-ryan

I'm pretty sure form_extras won't work with Django templates because you can't pass a dict as an argument there. Maybe it should take JSON? Hmmm.

Signup/login signals are very useful for analytics, among other purposes. It would be nice if we could just listen to a signal rather than override the entire functions to do that.

If the user includes browserid.js above the embedded form in their site, the click handler won't bind properly. We should be using on to bind to the body and handle the event when it bubbles up.

django_browserid looks for redirect_field_name in POST data, but it is not documented anywhere.

It will save some people's time if it is documented. For example, use a form like:

    <a id="browserid" href="#">'Log in'</a>
    <form method="POST" action="{% url 'browserid_verify' %}">
        <input type="hidden" name="next" id="id_next" value="{{ next }}" />
        {% csrf_token %}
        {{ browserid_form.as_p }}
    </form>

with next passed from your view.

The documentation is wordy and verbose and doesn't feel super clean. Would it be worthwhile to move this to rtfd?

For some reason I'm getting this issue

http://dpaste.com/723490/

Any ideas?

Because I'm a silly billy who doesn't tag releases.

Many sites will require a more human friendly username for all users. My strawman is to have a new setting:

BROWSERID_ACTIVATE_USER = False

When set to False, we leave user.is_active = False.

Then my verify view can check if user and not user.is_active and present a form to request a username and whatever else may be required by the specific site.

I have yet to be able to test it, but from mozilla/playdoh#117 it seems that the auth backend for django-browserid causes a DeprecationWarning to be raised in django 1.4.

/home/vagrant/project/vendor/lib/python/django/contrib/auth/init.py:26: DeprecationWarning: Authentication backends without a supports_inactive_user attribute are deprecated. Please define it in .
DeprecationWarning)
[21/Jun/2012 08:03:21] "POST /en-US/browserid/browserid/verify/ HTTP/1.1" 302 0
[21/Jun/2012 08:03:21] "GET / HTTP/1.1" 301 0

newton % sudo python setup.py install
newton % l /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django_browserid
total 152
drwxr-xr-x 3 root wheel 102B Jan 26 12:08 static
-rw-r--r-- 1 root wheel 364B Jan 26 12:07 init.py
-rw-r--r-- 1 root wheel 487B Jan 26 12:07 signals.py
-rw-r--r-- 1 root wheel 598B Jan 26 12:07 urls.py
drwxr-xr-x 20 root wheel 680B Jan 26 12:08 tests
-rw-r--r-- 1 root wheel 807B Jan 26 12:07 forms.py
-rw-r--r-- 1 root wheel 2.8K Jan 26 12:07 views.py
-rw-r--r-- 1 root wheel 3.5K Jan 26 12:07 context_processors.py
-rw-r--r-- 1 root wheel 3.7K Jan 26 12:07 base.py
-rw-r--r-- 1 root wheel 4.5K Jan 26 12:07 auth.py

I believe the templatetags folder is missing there.

Currently, if Persona is unavailable, we just throw a timeout error from Requests. It'd be nicer if we wrapped that and other possible errors in a BrowserIDError-type thing, and have our default view handle that smartly.

This may also be related to #57 depending on how PyBrowserID handles errors.

The verify view will redirect to the url given in the next parameter if it is in the URL or the POST parameters, but this functionality isn't documented. D'oh!

Using the latest django-browserid and the latest httplib2, I see the following error:

SSLHandshakeError at /browserid/verify/

[Errno 1] _ssl.c:480: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

The issue is the root GeoTrust cert isn't in httplib2's ca_cert file and/or chained certs.

There are a couple of ways to fix this:

• Use a custome ca_certs (I haven't test this to be true) which includes GeoTrust
• Use httplib2 version 0.6 and remove 0.7 keywords from django-browserid
• Add disable_ssl_certificate_validation=False config to django-browserid (weak sauce, tested works)

We're exploring fixing this at the browserid.org level also.

A new error just showed up to one of my Persona web apps using django-browserid. The only other library I'd updated recently was bleach. Has anyone experienced this error before or has advise to debug this further?

To use BrowserID with CSP you need to whitelist https://browserid.org/ in two places*.

CSP_SCRIPT_SRC = ("'self'", 'https://browserid.org',)
CSP_FRAME_SRC = ("'self'", 'https://browserid.org',)

Or in the default-src. Though some people report that it works without the CSP_FRAME_SRC

As I commented on the closed issue #1, the httplib2 project has released a working version and we should take that and not a commit from their repository.

django-browserid should be submitted to pypi

Hi,

I've been having problems using django-browserid, and they all seem to come from Httplib2.

Yesterday, it was the fact that the CA which authorised browserid.org is not included in Httplib2's set of default certificates. Today, I saw the option to specify the certificates file, and progressed past that, only to find that Httplib2 rejects the certificate as not belonging to the site (it has common-name="www.browserid.org").

My workaround is in my fork, in a branch named 'urllib'.

In commit 05cb056, it looks like two lines were added to django_browserid/init.py:

 from django_browserid.auth import BrowserIDBackend
 from django_browserid.base import get_audience, verify

Because of these two lines both of the following fail:

pip install git+git://github.com/mozilla/django-browserid.git#egg=django_browserid

mkdir t
cd t
git clone git://github.com/mozilla/django-browserid.git
cd django-browserid
python setup.py install

In both cases, I get the following error message:
ImportError: Settings cannot be imported, because environment variable DJANGO_SETTINGS_MODULE is undefined.

setup.py imports django_browserid/init.py to get the version number, but at setup time, the django environment is not available. These two imports should be removed from init.py or it should not be imported into the setup.py.

Is there a good reason you're using the requests module for one POST call, rather than urllib or urllib2?

Not sure if this is the correct project to file this.

If viewed from the address bar, server cert of https://browserid.org chains up to GeoTrust Global CA, while openssl s_client -connect -showcerts browserid.org:443 shows the cert chains up to Equifax Secure Certificate Authority.

Setting BROWSERID_CACERT_FILE = 'Equifax_Secure_Certificate_Authority.cer' (download) fixes the SSLError for me.

https://developer.mozilla.org/en-US/docs/persona/branding has some nifty CSS to make pretty login buttons, we should totally gank it. :D

I have a case where I need to make sure the user goes back to the current page, rather than my LOGIN_REDIRECT_URL so I am trying to use returnTo via navigator.id.request arguments in the docs.

What I am seeing is it takes me to my LOGIN_REDIRECT_URL anyway. I'd like it to take me to my data-return-to instead. Either that, or I need another mechanism for returning to a specific page.

According to the AMO team, django-browserid discards error messages from browserID verifier. Some way to log those messages would be very desirable. For example, at auth.py line 63.

-Mike H and Bill W

At https://github.com/mozilla/django-browserid/blob/master/django_browserid/base.py#L24.

That URL is deprecated, and the new URL is https://verifier.login.persona.org/verify

django_browserid.verify passes extra_params through urllib.urlencode, which breaks on unicode strings as it passes them through str. Since it looks like requests handles this automagically anyway, we should not pass it through and add a test for unicode params to ensure it handles them properly.

Let's face it: Setting up django-browserid has lots and lots of annoying steps and has lots and lots of annoying ways to mess up. This issue exists to track the ways we can make setup less painful.

In some cases, django-browserid will create a new user. It should call set_unusable_password before saving the new user.

It should not do this for existing users, since some apps might support multiple authentication backends.

A phishing attack is possible where a fake browserID dialogue is launched.

To allow the user to distinguish between a real browserID auth dialogue and a phishing dialogue do what many banks and sites like Yahoo do and allow the user to set a secret string or image for browserID to respond with.

This is only needed for the shim and when a site is not a browserID auth provider/primary

If users are using the included JS, they will need to know that jQuery is required to use it (alternatively, we remove the jquery dependency if possible).

In addition, the {% url gracefully_degrade %} placeholder is misleading as it currently stands. Either we need to explain better that it is a place for a fallback URL to a normal, non-JS login, or replace it with something better.

If BROWSERID_CREATE_USER is False, a valid assertion with no associated user can result in an infinite loop in Firefox 15.

browserid.js watches navigator.id for the "onlogin" callback. After navigator.id.request() returns with a valid assertion, Firefox 15 caches the result, and calls the onlogin callback, which asks Django to validate the email address. If that email isn't associated with a user, the call is redirected to the failure url. If the failure URL returns a page which includes browserid.js (which is reasonable, if we want to give people a second chance to log in), navigator.id.watch will immediately fire "onlogin" again with the cached assertion, asking Django to verify it again, etc.

Fixing this is complicated by the fact that the API does not expose whether verification fails because of an invalid assertion, and other browsers don't cache the assertion (so we can't just ignore the first firing of "onlogin").

The only workaround I can figure out right now is to always have the failure URL call "navigator.id.logout()" /before/ browserid.js executes.

e.target doesn't always refer to the link during the click handler, so it shouldn't be use to detect attributes on the link. this should be used instead.

Tests are failing because I have subclassed the authentication backend and I don't like that :P

I'm not sure if browserid.org always returns lowercase emails, but I'm pretty sure it won't hurt if the code also lowercases emails. If this is not done, users might type their email address with uppercase letters and create duplicate emails in the various services they use, particularly ones with two signon systems.

The docs(http://django-browserid.readthedocs.org/en/latest/setup.html#configuration) provide example code for the template which includes a link with:

class="browserid-login"

whereas the default JavaScript file looks for:

id="browserid"

This causes some confusion for newer users. Should the link be changed to the contain appropriate id instead of the class?

@jsocol pointed out that if JS loads slowly, users may attempt to click the login button before the click event for launching the BrowserID popup is bound.

MDN handles this by hiding the button with CSS and showing it after the event is bound. Our default JS and code example should do something similar to encourage good behavior.

hey-hi!

We've been working with @rfk on PyBrowserID (http://github.com/mozilla/PyBrowserID), and it seems that it could be great to integrate the two projects.

It would allow, into other things, to do verifications locally (rather than having to call a remote server), or to offload the crypto work to specialized workers (we are using this for our tokenserver at mozilla-services http://docs.services.mozilla.com/token/)

Into other things, here is what I'm proposing (which is partially implemented in my fork ):

• Adding some settings so that you can select the verifier you want to use. the choice would be between "local", "remote" and "custom" (which could be useful in some specialized cases).
• replacing the use of get_audience with the one specified in PyBrowserID, forcing users to define what's the intended audience they want (could be done using wildcards if needed).

However, it's important to notde that PyBrowserID stills need some love wrt to requests and certificates to cover all the cases you're covering. I've talked with @Osmose about that and he'll have a look at it prolly later this week.

Any thoughs?