mischback / django-miniuser Goto Github PK

• create Class Based View for creating new accounts
  • how much of Django's built-in views can be re-used?
  • Django's built-in views were introduced as CBV in Django 1.11. Up to 1.10 they are FBV. Should we seperate them logically? Or drop 1.10 support?
• create a corresponding form
• automatically activate if MINIUSER_DEFAULT_ACTIVE = True
• provide some mean of manual activation
  • no notification of staff members
  • with (email) notification of staff members
  • OPTIONAL: on-site notification of staff members moved to #14
• handle MINIUSER_REQUIRE_VALID_EMAIL
  • send verification email
• add specific actions to Django's admin to
  • activate / deactivate a user
  • re-send the verification email

As mentioned in #1, on-site notifications of superusers would be cool.

This is moved to this issue, because it is more like a long-term project.

Will be removed in #1.

• make email address changeable by the user
• create correspondig view
• create form (if validation is required; should be required, if not provided by Django's modelfield)
• consider process of re-verification (if REQUIRE_VALID_EMAIL)

Crazy clicking in the admin panel Manual testing showed, that while changing a MiniUser object in the admin panel, the (given) activation status (is_active) is overwritten by MINIUSER_DEFAULT_ACTIVE.

Found the respective code part in clean()-method. Needs a fix.

• make the package/application installable from pypi

• Lots of stuff has to be done, because I didn't do this step before. Major effort before 1.0

Situation:

• some project was started some time ago. A lot of users are already registered and are using the project and its applications actively.
• a (very smart) administrator decides to handle user-management with django-miniuser
• the (existing) user data-sets get migrated from Django's auth.User to miniuser.MiniUser
  • all existing fields get transferred
  • new fields are pre-populated with (sane) default values

modification of specific user objects

• create layout for single user modification
• integrate actions to interact with the user (see https://github.com/Mischback/django-miniuser/projects/2#card-8132604 ; activation/deactivation/re-send verification mail/...)

All templates of the app need some attention.

They should be as simple as possible, but include some features of the app.

They should not include any JavaScript code (probably, a fully responsive template-set may be provided within a different repo, probably with another license (depending on used technology and the respective licenses)).

Implement logging per account, meaning per user object.

• log failed login attempts
• log password changes
• log password resets
• log email changes
• log profile updates

This feature may be used to include

• deactivate accounts after x failed logins
• more details for email verification process

Implementation details:

• own model
  • user-object; a reference to the user
  • category; CharField with pre-defined values
  • message: CharField or TextField for custom messages

• make password changeable by the user
  • create password change view (or re-use Django's)
  • create password change form, that does validation stuff (if required)
  • consider how the process is affected by present settings

• Consider, if passwords should be resettable when there is no VALID_EMAIL address associated? (possible security issue)
  • first thought: passwords should be resetted if the user actually clicks a password reset link sent by mail
• determine, how long a password reset link should be valid? (-> configurable)
• implement password reset views
  • trigger password reset
  • enter new password view
  • is an error-page necessary?
• integrate with admin-backend
  • write corresponding action
  • make it accessible in MiniUser detail view as a button

This app will follow Django's supported versions IOT ensure, that as much code of Django as possible can be re-used. See https://www.djangoproject.com/download/#supported-versions

IOT enhance the admin panel, create custom permissions. This will enable a more flexible way of user management, because it does not rely exclusively on superusers.

• create custom permissions
  • view user list
  • activate user
  • deactivate user

Issues

• if an object/model is accessible in the admin-panel relies on the (given) can_modify-permission. Some dirty hack is required, to enable staff-users to actually view the user list.
• is_staff allows sign in into the admin panel
• can_modify is required to actually see a model
• create some custom admin view, to show the user-list to those users with custom permissions below can_modify.

See https://docs.djangoproject.com/en/2.0/topics/auth/passwords/#using-argon2-with-django for recommendations.

• should django-miniuser provide default settings for this?
• should the checks include a warning / info on this subject?
• should a migration-module be included for this?
• should some sort of update-mechanism be included?
  • migrate from one Hasher to the other?
  • let Django handle this stuff?