Experimental project
This is a sandbox project, which contains experimental code for developer use only.
Overview:
Mail Role grants roles to users based on their email address. A site developer can configure a list of domain names to detect and a user role to grant. Mail Role then examines a user's email address and if it determines that the email addresses' domain name matches one of the configured domain names, it will grant the user the configured role.
Possible scenario:
Assume we have a content rich site with a proper permission system set up. Roles are created to grant certain permissions to certain content types. Further assume that we want users from a certain company, say ACME, to be granted one of those roles whenever they register. It would be a boring process to grant each user that role manually.
That's where Mail Role comes in. Using a simple configuration approach, we can configure it to detect all email addresses ending in @acme.com and it will do the rest.
Security considerations:
Like all modules, site developers should take special care when using this module. First, do not ever use this module to grant the administrator role to users. This can have a very negative effect if used incorrectly. The administrator role, or any role that has permission to alter your site's configuration should always be granted manually.
Secondly, only use this module if, and only if, you have email verification enabled as part of of your site's registration configuration. This will prevent users from gaining a role using a fake email address.
Third, consider using this module to grant roles that have are created to grant access to view something along the lines of premium content. So if you configure it incorrectly, worst case scenario is that users will only see content they are not meant to see and not meddle with your site's configuration. The module has a logging option that, if enabled, can help you with your auditing review down the road.
Finally, take special care when configuring this module with generic third party email service providers like @gmail.com and @yahoo.com. This can have a dire effect on your site unless you know what you're doing. Chances are the majority of your site's users are registering using an email address provided by these email service providers, even if the email address is not fake.
Limitations:
Currently, Mail Role only supports a single list of domain names to detect and an associated user role to grant. This means that while you can configure multiple domain names to detect, they will all be granted the configured user role if detected. Furthermore, only a single user role can be granted.
Depending on the feedback I receive, I will consider adding a feature to allow site developers to create detection lists, where each list can have its own configured list of domain names to detect and a user role to grant.
This will permit a scenario where site developers can specify domains D1 and D2 should be granted role R1 and domains D3 and D4 should be granted R2. Like I have mentioned above, currently this is not possible.
Alternatives:
I am currently not aware of any other module that performs this functionality. My instinct tells me that it might be accomplished with Rules but after several attempts, I could not get it to work properly. If any one is aware of a method to implement this functionality using Rules, please let me know!
However, even if it is possible with Rules, this module can still serve as a light weight alternative for those site developers that are not, or do not wish to, use Rules.
Note to developers:
I am a OOP advocator and thus I usually prefer it over procedural programming. While some of the code follows a procedural style, which is required to obviously implement Drupal's hooks and all callback functions, you'll find that most of the module's core logic is actually implemented in classes.
While most of the classes are more or less static classes, that is they have no instance members at all, I still prefer them over defining procedural functions that, in my opinion, do nothing more than pollute the global namespace, especially if there are functions that are meant only for internal use by the module. You might consider them a replacement for a modular design without the need for requiring PHP 5.3's support for namespaces.
Project information
- Module categories: Access Control
- Created by 9ee1 on , updated