Fixed minimal version, works with Django 1.7+, tested on Django 1.9. Add the following to your settings: AUTHENTICATION_BACKENDS = [ 'project.backends.UserModelEmailBackend', # Login w/ email 'django.contrib.auth.backends.ModelBackend', # Login w/ username ]
The backend lets you quickly get an idea of all emails that are sent out. Helpful for debugging or keeping an archive of all communications. Use instead of Django's SMTPBackend.
A project I'm working on requires multiple different classes of users, all with different fields/attributes. Having a single UserProfile class with a generic relation was a complete pain in practice. So, I changed my classes to all subclass User directly and then used django-model-utils to create a custom ModelBackend that returns the appropriate class when accessing request.user. The InheritanceQuerySet manager provided by django-model-utils makes it all possible and with only a single database query. No need to add anything directly to the User class, by the way. Just subclass it directly with each of your custom classes: class CustomUser1(User): field1 = models.CharField(...) class CustomUser2(User): field2 = models.CharField(...)
[Chris' code](http://djangosnippets.org/snippets/1845/) adapted to django 1.3. Basicly E-mail authorisation backend. Put it as one of your AUTHENTICATION_BACKENDS in settings.py: AUTHENTICATION_BACKENDS = ( 'community.auth.EmailBackend', )
You can use this cache backend to cache data in-process and avoid the overhead of pickling. Make absolutely sure you don't modify any data you've stored to or retrieved from the cache. Make deep copies instead if necessary. The backend is basically identical to Django's stock locmem cache (as of r15852 - after 1.3rc1) with pickling removed. It has been tested with that specific Django revision, so basically it's >=1.3 compatible. See [Django ticket #6124](http://code.djangoproject.com/ticket/6124) for some background information.
Based on discussion on [http://thebuild.com/blog/2010/12/14/using-server-side-postgresql-cursors-in-django/](http://thebuild.com/blog/2010/12/14/using-server-side-postgresql-cursors-in-django/) and [http://thebuild.com/blog/2010/12/13/very-large-result-sets-in-django-using-postgresql/](http://thebuild.com/blog/2010/12/13/very-large-result-sets-in-django-using-postgresql/) but instead implements them via extending the psycopg2 backend which allows you to use all of django's machinery without having to resort to using raw cursors. Usage: qs = Model.objects.all() with server_side_cursors(qs, itersize=100): for item in qs.iterator(): item.value if random_reason_to_break: break Setup: In your own project create the package hierarchy myproject.db.backends.postgresql_psycopg2 and place the code in base.py. In your settings.py set the database ENGINE to be 'myproject.db.backends.postgresql_psycopg2'. If you using south you'll have to let it know its a postgresql_psycopg2 backend by adding to SOUTH_DATABASE_ADAPTERS (see south documentation). Note: Make sure your using psycopg >= 2.4 for efficient named (server side) cursor iteration.
This snippet implements an authentication backend for MoinMoin user accounts. If you have a MoinMoin running on the same server which has users, you can allow those users to sign into a Django site with the same username and password. To use, define the following settings: MOIN_DATA_DIR = "/path/to/moinmoin/data/dir" AUTH_BACKENDS = ( 'django.contrib.auth.backends.ModelBackend', '<this snippet module>.MoinMoinBackend', ) # optional list of groups that authenticating users must be in MOIN_AUTH_GROUPS = ["EditorGroup",]
email backend which use sendmail subprocess
Because the db caching doesn't support atomic operations, it was unsafe to store a list of 'keys' in a single key. So, rather than store the list, I just append each key with a specific tag, and then filter for it later. This means I don't need to worry too much about atomic usage with lists (i.e. queued requests). However - I still can think of many instances where I would need atomic usage, so I will probably implement this later on down the line. Hopefully, the atomic modifications will be accepted by the core devs. This also contains threaded cache cleaning, which means you no longer need to rely on requests to clean the cache (which would have potentially slowed the user query down), and will remove any cache entries past their expiry date every 3 minutes. Enjoy! Cal
This code uses oracle as an authentication back end. It creates a new connection to the db and attempts to login. If successful it will then create an upper case User account with _ORACLE appended to the username. My urls.py call: from django.conf.urls.defaults import * urlpatterns = patterns('', (r'^accounts/login/$', 'django.contrib.auth.views.login', {'template_name': 'login.html'}), ) My setting.py specific settings: AUTHENTICATION_BACKENDS = ( 'oracleauth.views.OracleAuthBackend', ) LOGIN_URL = '/accounts/login/' ORACLE_CONNECT = 'database-host:1521/database' DEBUG=True
This backend will allow you to have users login using either their username or the email address as it is in the User model. In addition, it will allow anyone with the staff priveleges to login as another user. The method is to user the user you wish to masquerade as (either email/username) as the username and then a string of the format *username*/*password* as the password, where *username* is the username of the staff member, and *password* is their password.
TwitterBackend is the twitter authentication backend. This backend makes use of OAuth based "Sign-in with Twitter" Configure your settings.py as per [Django - Specifying Authentication Backends](http://docs.djangoproject.com/en/dev/topics/auth/#specifying-authentication-backends)
This is based on [snippet 501](http://www.djangosnippets.org/snippets/501/), with some corrections: 1. if user doesn't exist and AD.authenticate passes, then create new user - don't store password - prevent default django auth backend authentication 2. if user exists and AD.authenticate passes - django User object is updated 3. various error handling 4. fixes (some mentioned in original snippet) 5. some settings removed from settings to backend module 6. other changes (ADUser class, re-indent, logging etc.) 7. ignores problem with search_ext_s (DSID-0C090627) 8. caching connection - when invalid then re-connect and try again Note that there is also ldaps:// (SSL version) django auth backend on [snippet 901](http://www.djangosnippets.org/snippets/901/). Possible improvements: 1. define new settings param - use secured - then LDAPS (snippet 901) 2. define new settings extra ldap options - e.g. protocol version 3. fetch more data from AD - fill in user data - maybe to make this configurable to be able to update user.get_profile() data too (some settings that has mapping AD-data -> User/UserProfile data)
By enabling this backend: AUTHENTICATION_BACKENDS = ( 'path.to.my.backends.CaseInsensitiveModelBackend', ) Your users will now be able to log in with their username, no matter whether the letters are upper- or lower-case.
This allows various implementations of a common interface to be loaded. Back end modules can be specified in settings.py, and from there be loaded and treated polymorphically by an application.
22 snippets posted so far.