"Magic Link" Management Command
Django Management Command to print a "Magic Link" for one-click log-in. This is nice for people who project switch or don't want to remember passwords.
- authentication
- magic
- management
- command
Django Management Command to print a "Magic Link" for one-click log-in. This is nice for people who project switch or don't want to remember passwords.
Requires to install "basicauth" package, which does basic-auth header encoding/decoding cleanly according to RFCs. Could be improved to return a "realm" in case of http401, like in https://djangosnippets.org/snippets/1720/, although I'm not sure it's really useful in django usecases.
### settings.py MIDDLEWARE = [ 'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', 'utils.LoginRequiredMiddleware', ] LOGIN_REQUIRED_URLS = [ r'^panel/(.*)$' ] this will help any url under `panel/` require login.
This is an example of Django auth with JWT tokens, you can find how to add [jwt auth to Django Rest Framework in this tutorial](https://www.techiediaries.com/django-rest-framework-jwt-tutorial/)
Say you want to keep your API secure and thus it has authentication, but there's this one View action in a ViewSet which unlike the rest of the ViewSet's actions needs to allow free access without authentication. This solution applies the good old `IsAuthenticated` permission to all ViewSet actions except those defined in a `login_exempt_actions` list. That's a list of the ViewSet action's names. This is a simple solution for this particular problem, which I imagine could be quite common. Any case where the requirements are more complex should implement one of the DRF permissions extensions which allow for the use of logical operators. **NOTE**: Remember that `request.user` will be an `AnonymousUser` instance, so be careful with any code which assumes it'll be a `User` instance. This could be the case with, say, a custom `get_queryset` implementation.
This hasn't been thoroughly tested yet but so far it works great. We had no use for sessions or the built in authentication middleware for django as this was built to be a microservice for authentication. Unfortunately if you just use the django rest framework-jwt package the authentication occurs at the view level meaning request.user.is_authenticated() will always return False. We have a few internal non-api views that needed @login_required. We have a stripped down version of django that is very performant that we are using for microservices with built-in authorization using JSON Web Tokens. This service is authentication which has access to a `users` table. Any questions or curious how well lightweight django is working for microservices, or we he are doing the the authorization on the other services, or just improvements please drop a line - thanks.
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 ]
Instead of the default Django User the Auth Model is 'customer' from the usercp App. User's can use username as a display to the public, without disclosing their login information. This way they can use a forum with their username, which is seen by everyone. The login credentials, however are more privat, since it is the e-mail address. Allowing the user to not disclose any information.
Showing a list of logged users using the *user_logged_in* and *user_logged_out* signals. See [login and logout signals](https://docs.djangoproject.com/en/1.4/topics/auth/#login-and-logout-signals) in Django docs.
A very basic Basic Auth middleware that uses a username/password defined in your settings.py as `BASICAUTH_USERNAME` and `BASICAUTH_PASSWORD`. Does not use Django auth. Handy for quickly securing an entire site during development, for example. In settings.py: BASICAUTH_USERNAME = 'user' BASICAUTH_PASSWORD = 'pass' MIDDLEWARE_CLASSES = ( 'app.module.BasicAuthMiddleware', #all other middleware )
This is auth_data_required decorator analogous to login_required where authentication data must come in POST of request. It's useful for API. I took the idea from [Tumblr API](http://www.tumblr.com/docs/en/api).
This authenticate together django.contrib.auth.models.User like django normal login does.
Use django_openid_auth from https://launchpad.net/django-openid-auth to authenticate your users with their Google Account. This snippet will allow your users having a Google Account address as username to log in using it.
Point '^accounts/login/$' or whatever your custom login path is to the 'negotiate_ntlm' view. This allows you to keep anonymous authentication enabled on IIS and easily lock down just the parts of the site you need to (e.g. [admin](http://djangosnippets.org/snippets/2127/)).
Forces admin site to use your custom login. Very useful when using RemoteUserBackend. See [here](http://djangosnippets.org/snippets/2128/) for a use case.
50 snippets posted so far.