Users, Accounts & CRM apps

App screenshot

The users app stores basic information about first, last name, emails and sessions.

Logic for authenticating users can be found in the accounts app.

The CRM app in the control panel is for viewing information about users, managing the waitlist etc. Models and logic for the CRM app are in the dashboard app.

Emails and basic account information.

Emails are the primary means of authenticating users. Emails can be managed from the user's profile page. A user can add/edit/delete emails and also manage password information.

Social Accounts

Users can connect different social accounts. The social authentication method must be from the dashboard or in code. Please see the authentication configuration docs for how to disable/enable social accounts.

User Sessions

Users can expire/logout of active sessions directly from the dashboard. They can also view any ongoing sessions directly from the profile page.

User sessions architecture

The app uses a CustomSessionMiddleware class in place of Django's SessionMiddleware.


   "apps.users.middleware.CustomSessionMiddleware", <-- replaces django's SessionMiddleware

The custom middleware modifies the standard behaviour in the following way:

  • When a request is created, the standard session store object is extended to include information about the user's IP and user agent.

     def process_request(self, request):
         session_key = request.COOKIES.get(settings.SESSION_COOKIE_NAME)
         request.session = self.SessionStore(
              ip=request.META.get("REMOTE_ADDR", ""), <-- new
              user_agent=request.META.get("HTTP_USER_AGENT", ""), <-- new

The session backend used has also been modified to use the custom CustomUserSession model class which stores additional information about the session, namely, the ip, user_agent, account_id and last_activity.

Sessions for anonymous users

Django only saves the session if request.session was modified, or if the configuration is to save the session every time. This means that for anonymous users, the request.session.session_key will be empty (None), the session object will also NOT be present in the database.

If you need to store/monitor session information about anonymous users you will have do this manually.

To create it in a view.

    if not request.session or not request.session.session_key:

   # request.session.session_key now set

See this from stackoverflow - sessions for unauthenticated users . Please note that once a user signs in/up the session key may be modified. It maybe useful to store the key in another variable called anonymous_user_session key. That way once a user signs up, you can map the user session keys.

Another more complex option would be to modify the behaviour directly in middleware. This is not recommended unless you are fully aware of how Django's SessionMiddleware & Vanty's CustomMiddleware work.

User API Keys

As of version 0.9.1, users can manage their API Keys directly from the dashboard.

This is enabled via the restframework api key library.

Remember API Keys are NOT for authentication

API keys are ideal in the following situations:

  • Blocking anonymous traffic.

  • Implementing API key-based throttling. (Note that Django REST Framework already has many built-in utilities for this use case.)

  • Identifying usage patterns by logging request information along with the API key.

Enable User API Keys

Add the IsAuthenticatedOrHasUserAPIKey permission to the view. You can enable this globally or on a per view basis.

 # in   
"DEFAULT_PERMISSION_CLASSES": "rest_framework_api_key.permissions.HasAPIKey"

 # enable in view
 permission_classes = [IsAuthenticatedOrHasUserAPIKey]

Revoking keys

You can revoke user keys directly from the django admin.

Deleting user accounts

Admins can delete accounts from the django admin. Since version 0.10.0, users can now also delete their own accounts from the dashboard.

Currently the delete account flow will expire/delete all sessions, delete the user account and send the user an account deletion email. Modify the delete account method on the user model to suit your use case.