An excellent aspect of the Django is that it provides the three A’s and it provides them well. Those three A’s represent authentication, authorization and access control. Now, to try and improve on these three is something that many companies decided to try, but none of them succeeded in entirety.
The goal of this project is to improve on excellent features that Django tagging provides, and that is necessary due to flaws of the said tool. Django isn’t perfect, and every improvement that removes an imperfection from the calculation is welcome.
Authentication – The best aspect of the Django
If you’d like to store additional info that is related to users, Django’s authentication application provides a method to specify a site-specific model – termed a “user profile” – for this purpose. The a3c app uses this feature for including a status_code (ready, pending confirmation and pending approval) for each user. The status_code complements the User.is_active and User.date_joined attributes. This last attribute could be used to implement “user self-registration attempts time out.”
The authentication that comes with Django is good enough for most common cases, but you may need to use different authentication source, use other authentication methods, or take other aspects into account as the UserProfile.status_code. So, to manage situations like this, Django’s authentication system lets you plug in other authentication backends. The a3c app defines three authentication backends: ModelBackend, ExternalBackend, and TrustedExternalBackend.
Authorization – The membership system in its near perfect form
The a3c’s permission system is implemented in the UserProfile (apart from the auth’s approval system). It uses the initial_data fixture to include READ, WRITE and CONFIGURE permissions, and EMPTY, READER, WRITER and ADMINISTRATOR roles.
The permissions of a user in a project are granted using memberships, and a project has a default_role utilized in the case of a user that doesn’t have any approved groups (Membership.satus_code: pending or approved) in the project.
The UserProfile.has_perm(self, perm, project) replaces the User.has_perm and takes into account that an inactive user doesn’t have any permissions while a super-user (User.is_superuser) implicitly have all of them.
Access Control – The lack of improvements is alarming
This part is still in its infancy. Django’s auth has a permission_required decorator, but we need a project parameter that makes things more complicated. So, what does that mean for us who want to create a separate app that won’t rely on the Basie and other chat software?
This means that we still have issues that troubled our predecessors. The lack of a sophisticated access control makes it easy for third parties to alter the software and ruin everything that the owner created. This is an issue we want to correct, and the only viable way to do it is to write new lines of code. They should make the access control complicated and provide layers of access that will make it impossible for unauthorized individuals to access the project.