django-allauth configuration doubts

Question

I'm using django-allauth with Django 1.5.1 and I have a few questions when setting it up:

1. Configure urls.py

The docs says that you have to add the following to urls.py file:

urlpatterns = patterns('',
    ...
    (r'^accounts/', include('allauth.urls')),
    ...
)

The problem is that I already have a custom app called accounts and I already use the following URL pattern:

(r'^accounts/', include('accounts.urls')),

So I have a naming collision here with the accounts/ regex URL. My question is: can I rename the allauth URL pattern to (r'^auth/', include('allauth.urls')) without having problems, or is it unsafe to do so and it'd be better to rename my own URL to something like (r'^users/', include('users.urls')) (and rename my accounts app to users for naming consistency).

2. Customize allauth default templates

What is the proper way to customize the default templates for login, etc.? I think that modifying the library directly is not the best approach. I guess it should be done through templates directory using some concrete directory hierarchy. Also, I don't know if some kind of base.html file must be provided to extend from when overriding these templates or the site's base.html that all pages extend can be used without problems. Could you illustrate me with this?

3. Admin login form shows logins and logouts the first time it's accessed

When I access the admin panel after some logins and logouts the history appears, but if I refresh the page then it disappears. I think this must be something related with the django messages:

4. Setting SOCIALACCOUNT_PROVIDERS

Is the dictionary setting called SOCIALACCOUNT_PROVIDERS optional or must it be set?

5. How is the password calculated when a user signs in with a 3rd party app?

When the user is created it has a password, but how is it calculated? And... is it useful or is it only a placeholder for this required field? Can the user use it to local login?

Thanks!

Answer 1

With respect to 1):

• There is no collision as long as there is no overlap in the fully matched URL patterns. For example: if your accounts app has a match for "/accounts/login/" then there is indeed a collision as allauth is gunning for that URL as well. But, if your accounts app simply matches other URLs with /accounts/ as prefix then you are fine.

• If you insist, you can indeed put allauth URLs below a different path. allauth uses name based URL reversal, so the new path prefix will be picked up automatically.

As for 2):

• There is nothing special about allauth templates. You can override them just like you would for any other Django app.

• Have a look at the example app. It has both Bootstrap and uniform template overrides. They can be enabled by uncommenting this line: https://github.com/pennersr/django-allauth/blob/901485557d4ddee30fed920f2159cdf499c39e1c/example/example/settings.py#L126

• All allauth templates inherit from a base template, called base.html. I would expect that your project also has a base template. Either override the base.html with yours, or, override base.html with a template that extends from yourbase.html

3): allauth uses the Django messages framework. See: https://docs.djangoproject.com/en/dev/ref/contrib/messages/#expiration-of-messages -- if you do not iterate over the messages in order to display them, they do not expire. So apparently you are not showing the messages in your templates. Therefore, they heap up until the admin appears which renders (and clears) all messages collected so far...

4) Optional

5) There is no password set, meaning, the user can only login using the 3rd party account until he actually sets a password (/accounts/password/set/).