This is a username field that matches (and slightly tightens) the constraints on usernames in Django's `User` model. Most people use RegexField, which is totally fine -- but it can't provide the fine-grained and user friendly messages that come from this field.
Suppose you want a decorator which takes multiple permissions. You can use permission_required which takes a single value.
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.
This tag builds on top of the [ifusergroup/else tag](http://www.djangosnippets.org/snippets/390/), fixes a small bug and introduces support for else blocks. This adds a way to provide multiple groups via group1|group2|group3
Sometimes the only way to reproduce a bug on a production site is to login as the User who encountered it. This form allows you to login as any user on the site. **Usage** @staff_member_required def login_as(request, template="login_as.html"): data = request.POST or None form = LoginAsForm(data, request=request) if form.is_valid() form.save() return HttpResponseRedirect(settings.LOGIN_REDIRECT_URL) ...
This code monkey-patches the default User model to rather use a primary key of UUIDField (see http://www.djangosnippets.org/snippets/1496/). This code also makes the email field required. This code is wildly dangerous, not completely future proof, and probably not advisable to use. If you do wish to use it, it will be easiest to implement on a fresh db with a syncdb. If you need to migrate existing user data the onus is on you to figure out an appropriate db migration plan. I placed this code in a models.py, but it is probably more reliably placed in urls.py
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.
I use this snippet to simplify my auth system with flash uploader SWFUpload. flash_login_required ensures that the user is authenticated and inject the context dictionnary into the specified template. To redirect a user, just set the variable `context['redirect']` with an url. Remember to include the cookie js in your template to get the sessionid variable POSTed to your view: `<script type="text/javascript" src="/static/js/swfupload/swfupload.cookies.js"></script>`
This is a somewhat simpler alternative to [http://www.djangosnippets.org/snippets/243/](http://www.djangosnippets.org/snippets/243/) that does not return a 401 response. It's meant to be used along with the login_required decorator as an alternative way to authenticate to REST-enabled views. Usage: @http_basic_auth @login_required def my_view(request): ... If an HTTP basic auth header is provided, the request will be authenticated before the login_required check happens. Otherwise, the normal redirect to login page occurs.
This blog post outlined how to get the user from the session key: http://scottbarnham.com/blog/2008/12/04/get-user-from-session-key-in-django/ Unfortunately, it assumes DB-backed session and auth backends. This isn't required, so this snippet provides a backend-agnostic way to do the same thing. >>> skey = 'ea0ed02d35d43aeaf20b3ef516f51396' >>> user_from_session_key(skey) <User: jeremyd>
Wraps specified URL patterns with login_required decorator. Allows you to quickly require login for an area of your site based only on a URL pattern. Similar to [zbyte64's snippet](http://www.djangosnippets.org/snippets/966/)
This is a simple fixture that is useful for many tests. It contains the following users: * admin * staff * user0 * user1 * user2 * user3 * inactive0 * inactive1 The password of every user is the same as his username, e.g.: admin/admin
A simple backend which allows you to login with either an email address or a username. It should be combined with another backend for checking permissions: AUTHENTICATION_BACKENDS = ( 'myproject.accounts.backends.EmailOrUsernameModelBackend', 'django.contrib.auth.backends.ModelBackend' )
Decorator for views that checks that the user is staff, redirecting to the log-in page if necessary. A wrapper for user_passes_test decorator based on login_required Possible usage: @is_staff def view.... urlpatterns = patterns('', (r'^databrowse/(.*)', is_staff(databrowse.site.root)), )
64 snippets posted so far.