This snippet is an improved version of the [ifusergroup](http://djangosnippets.org/snippets/1576/) tag that allows spaces in any of the group names. It also fixes a small bug where if a group didn't exist none of the subsequent groups would be checked.
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', )
Uses the token generator located at django.contrib.auth.tokens as an authentication mechanism aimed mainly at API calls. Any POST request with a valid token and user parameter will work as if the user were logged in normally.
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",]
Simple decorator definition to authorize particular IPs access to a view function.
Splitting the information about a user across two models (User and UserProfile) is not to everyone's liking. This snippet monkeypatches the User model so that users can access transparently their profile information while still storing the data in two tables under the hood. Thus it is similar to the inheritance approach (http://scottbarnham.com/blog/2008/08/21/extending-the-django-user-model-with-inheritance/) but has the benefit of (a) not requiring a custom authentication backend or middleware and (b) loading the profile instance lazily, so there's no extra overhead if the profile infromation is not accessed. Read the docstrings for more details.
This code adds new field to Django user model. It must be executed early as much as possible, so put this code to __init__.py of some application.
Authentication through Facebook's Graph API. See [http://developers.facebook.com/docs/authentication/](http://developers.facebook.com/docs/authentication/) [http://developers.facebook.com/docs/authentication/permissions](http://developers.facebook.com/docs/authentication/permissions) [http://developers.facebook.com/docs/api](http://developers.facebook.com/docs/api) [http://github.com/facebook/python-sdk/blob/master/examples/oauth/facebookoauth.py](http://github.com/facebook/python-sdk/blob/master/examples/oauth/facebookoauth.py) Define the facebook tokens in settings.py and replace <app_name> with the name of your app. You will probably want to modify the scope on the authorize link in the template, see the authentication permissions link. This updates the user model every time the user logs in but I think that it is okay so the data is always correct. I have tested this but not rigorously. If there is a hole and everyone gets admin rights to your site don't say I didn't warn you :). Comments are appreciated. 16 June 2010 Added missing imports. Cleaned up the template. Shouts out to @obeattie and @whalesalad
Here's a signal handler to log a user in on registration activation. It took me an hour to figure out that I needed to put the user.backend in quotes and google wasn't being my friend. from [the django-registration documentation](http://docs.b-list.org/django-registration/0.8/faq.html): How do I log a user in immediately after registration or activation? You can most likely do this simply by writing a function which listens for the appropriate signal; your function should set the backend attribute of the user to the correct authentication backend, and then call django.contrib.auth.login() to log the user in.
Here my piece of code for managing users with WSGIAuthUserScript.
Middleware to decorate views with user_passes_test in a centralized, url-matching manner. Makes it easy to apply permissions across large sections or all of a site.
Based loosely on [Eric's middleware](http://ericholscher.com/blog/2009/sep/5/debugging-django-production-revisited/), this middleware will show the technical 500 page (which you'd get if DEBUG == True) to any user who is (1) superuser and (2) a member of the settings.TECHNICAL_500_GROUP_NAME group. (If no setting exists, 'Technical Errors' is the presumed group name. I agreed with the comments that caching should be unnecessary given the (presumptive) edge case of exception + superuser. Assuming you don't have tons of superusers, this code is a good bit simpler.
This snippet provides a @group_required decorator. You can pass in multiple groups, for example: @group_required('admins','editors') def myview(request, id): ... Note: the decorator is based on the snippet [here](http://fragmentsofcode.wordpress.com/2008/12/08/django-group_required-decorator/) but extends it checking first that the user is logged in before testing for group membership - [user_passes_test](http://docs.djangoproject.com/en/dev/topics/auth/#django.contrib.auth.decorators.user_passes_test) does not check for this by default. It is important to check that the user is first logged in, as anonymous users trigger an AttributeError when the groups filter is executed.
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
64 snippets posted so far.