This module provides a way to transparently log a user into the web site when they follow a link. Every effort has been made to minimize the potential security risks.
USE CASE
========
* The main use case is for mass emailing where it is unlikely
that the recipients will go through the hassle of creating
accounts and passwords. Assuming an account has been created
for them, email to them contains a customized link which will
automatically log them in and take them to a target page.
* This permission would only be given to accounts with "low
value" privileges (e.g. no admin, financial or access to
confidential data).
* The reason for logging users into the site would typically be
so that they can do activities such as:
o sign up for events
o comment, rate, "like", or otherwise interact with the site
o unsubscribe from email or change email preferences
* Usage tracking
o Widely used mass email tools such as MailChimp and Campaign
Monitor allow the sender to track which links in the email
recipients have clicked on.
o Using this module, Drupal's own tracking system can be used
to accomplish this, providing a far more integrated
solution than provided by third-party mailers.
FEATURES
========
* Security
o The login access link is encoded with a high level of
security based on sha256
o All encryption/decryption functions are encapsulated in a
separate file so that an alternative can easily be dropped
in as a replacement
o All currently issued access links may be instantly
"expired" by simply changing an administration setting,
giving full control over the active lifetime of the links.
o All access failures are logged together with the reason for
the failure
o The main security weakness would be from emails going
astray or being intercepted. This can be mitigated by:
- giving access links a short lifetime
- limiting the permissions of users who are allowed this
mode of access.
* Design Features
o The module is designed to scale to over 100,000 users,
(although only tested with 15,000).
o Both users and spam detectors are suspicious of long URL's,
so every effort has been make to keep the login link as
short as possible
o For this reason, the embedding login string is only 11
characters long.
- e.g. HTTP://example.com/l/zjIR0AeOzef/blog/myarticle
o base64URL encoding has been used to avoid problems
o The link can take the user directly to any page on the site
for which they have permission
o The module is integrated with persistent_login
DIFFERENCES FROM OTHER SIMILAR MODULES
======================================
The most similar module is easylogin although the similarities
are only superficial because easylogin has an entirely different
use case. There is almost zero overlap of code between these two
projects because of the opposite approach to architecting the
solution. Both projects have valid use cases so there would be
nothing to be gained by attempting to combine them.
USE CASE
* urllogin:
o mass emailing
* easylogin:
o allowing a small number of individual users to manage their
access using a URL string
ARCHITECTURE
* urllogin:
o All encryption/decryption done on the fly
* easylogin:
o All users have an extra "password" added to the database.
User can log in by putting this "password" in a URL
ARCHITECTURE STRENGTHS
* urllogin:
o Highly secure
o Large number of users can be managed easily
o No database tables need to be created/maintained
o mass download of access strings to csv file
* easylogin:
o Detailed individual-level control possible
ARCHITECTURE WEAKNESSES
* urllogin:
o No individual control (except by permission)
o no way of re-setting an individual access string
* easylogin:
o Low Security: access strings are stored unencrypted in the
database
o No way of making access strings have an expiry date
o methodology does not scale to a large number of users
o no mass download of access strings possible
CONFIGURATION
=============
1. Set a passphrase and validation numbers on the urllogin
administration page (/admin/settings/urllogin)
2. Give the "login via URL" permission to users who are allowed
to log in with this module
3. Generate login strings (can be downloaded as a CSV file)
POSSIBLE FUTURE DEVELOPMENT
===========================
* Integration into simplemail
Licensed under the GPL 2.0.
http://www.gnu.org/licenses/gpl-2.0.txt
Comment | File | Size | Author |
---|---|---|---|
#3 | urllogin_screenshot.png | 60.33 KB | andrewfn |
#2 | urllogin2.tar_.gz | 14.97 KB | andrewfn |
#1 | urllogin.tar_.gz | 13.73 KB | andrewfn |
Comments
Comment #1
andrewfn CreditAttribution: andrewfn commentedComment #2
andrewfn CreditAttribution: andrewfn commentedUpdated version of module: Improved documentation and tidied up help messages.
Comment #3
andrewfn CreditAttribution: andrewfn commentedAttached screenshot of administration page.
Comment #4
andrewfn CreditAttribution: andrewfn commentedMy initial description of the project seems to have lost its formatting and is hard to read. Here is the formatted version of the above description.
Description
I have developed the urllogin module for my company who would like to release it back the community.
This module provides a way to transparently log a user into the web site when they follow a link. Every effort has been made to minimize the potential security risks.
Use Case
Features
Differences from other similar modules
The most similar module is easylogin although the similarities are only superficial because easylogin has an entirely different use case. There is almost zero overlap of code between these two projects because of the opposite approach to architecting the solution. Both projects have valid use cases so there would be nothing to be gained by attempting to combine them.
strengths
weaknesses
Another similar module is One-time login links which is a very minimal utility module that simply re-creates the link that a user would get had they forgotten their password and needed to re-create it.
Configuration
Possible Future Development
Licensed under the GPL 2.0.
http://www.gnu.org/licenses/gpl-2.0.txt
Comment #5
arianek CreditAttribution: arianek commentedHi. Please read all the following and the links provided as this is very important information about your CVS Application:
Drupal.org has moved from CVS to Git! This is a very significant change for the Drupal community and for your application. Please read the following documentation on how this affects and benefits you and the application process:
Migrating from CVS Applications to (Git) Full Project Applications
Comment #6
andrewfn CreditAttribution: andrewfn commentedHere is a link to the sandbox project: http://drupal.org/sandbox/andrewfn/1076736
Comment #7
Berdir- I suggest you integrate your (awesome) project description from above into your sandbox project.
That project is not a temporary thing, it will simply be marked as a public project as soon as you're through the approving process. So everything you can do to make it look real will help you :)
You even got issue about it already which you can close after you've done that ;)
- Also, you need to remove the LICENSE.txt file, that will be automatically added by the packing script, it's not necessary that every single module on d.o has it version controlled.
- Next thing, you need to use {some_table} in all SQL queries and none of , for example this one:
Drupal needs {} to apply an eventually existing $table_prefix.
- version = "6.x-1.x-dev"
You can remove this from your .info file, it will be added automatically by the packing script.
- ; $Id: urllogin.info 102 2011-02-16 20:57:42Z andrew $
You can also remove these lines, git doesn't use them.
- function urllogin_version()
You can probably just remove that function because with git, these placeholders aren't updated anymore and the version is already visible on the modules page.
- $items['l_test'] = array(
Not sure what that test stuff is exactly doing, is that useful on a production site? If not, you might want to move it to an optional test module or something like that.
- function urllogin_uninstall() {
This needs to be in a .install file
- I think the security stuff needs review from someone with good knowledge about that stuff before it can be made public.
Comment #8
andrewfn CreditAttribution: andrewfn commentedThanks Berdir for your very helpful review:
version = “6.x-1.x-dev”
You can remove this from your .info file, it will be added automatically by the packing script.; $Id: urllogin.info 102 2011-02-16 20:57:42Z andrew $
You can also remove these lines, git doesn’t use them.function urllogin_version()
$items[’l_test’]
Not sure what that test stuff is exactly doing, is that useful on a production site?README.txt
and on the project page under CONFIGURATION.urllogin_uninstall()
This needs to be in a .install fileurllogin.install
createduser_pass_rehash()
). What I have done is to follow the Drupal 7 guidelines: Use of hash functions: “For Drupal 7 modules, md5() and sha1() should never be used, since they are considered obsolete and potentially insecure for some applications. For a normal hash function use sha-256 by callinghash(’sha256’, $data)
.”Thanks again for all your comments!
Comment #9
andrewfn CreditAttribution: andrewfn commentedChanging the title to something useful.
Comment #10
Grayside CreditAttribution: Grayside commentedI took a look at this after discussing with andrewfn the distinction between this module and tokenauth in #1110002: Token Authentication difference?.
Aside from some minor whitespacing issues around parentheses, it looks pretty good. You might try running the coder module to catch that. (Example: http://drupalcode.org/sandbox/andrewfn/1076736.git/blob/HEAD:/urllogin.i...)
Two minor points worth considering, you are creating some encryption methods there, and I wonder whether it might not be better to lean on http://drupal.org/project/encrypt. Also, I find some of the page callback function names to be confusing, and wish that some of the more operational aspects of the code were handled via dedicated API functions.
Comment #11
andrewfn CreditAttribution: andrewfn commentedThanks for the review.
I had been running the module religiously against the coder module to keep it clean, and was getting zero issues. It occurred to me that you might be using the Drupal 7 coder or the online version. I tried coder (7.x-1.x-dev version) on one of my D7 sites and indeed, it caught a lot more things. I tried the online version and it was exactly the same as D7.
However neither of them caught the spacing issue you pointed out:
while ( $data = db_fetch_object($result) ) {
What version of coder were you using?
I will certainly have a look at the encrypt module.
Comment #12
Grayside CreditAttribution: Grayside commentedI didn't actually run coder, or would have known it wasn't picking up on it! :)
The whitespace pattern I saw was a space before and after parentheses. Saw maybe three different lines demonstrating it, didn't make a careful count because I thought coder would notice.
Comment #13
andrewfn CreditAttribution: andrewfn commentedSo coder is not quite ready to replace all humans! :)
I had a look through the style guidelines and I couldn't see anything about spaces within parentheses, so maybe coder is simply going by the book. (However it is very good at picking up missing spaces after commas in parameter lists.) So I went through by hand and corrected the lines. You are right, there were three.
Thanks!
Comment #14
andrewfn CreditAttribution: andrewfn commented#10 - I have looked at the Encrypt module. Some while ago there was a proposal to combine it with the (very similar) AES module. Since that time the AES module has been under active development and the Encrypt module has languished, so it is probably better to go with AES. A key advantage of AES is for those who do not have the ability to install mcrypt on on their webserver--it provides an alternative way of getting the required libraries.
Because of the way I have separated out the encryption aspects of URL Login, it will be very easy to integrate it with AES. I will make this an option because it does come with a disadvantage (24-character tokens instead of 12).
Thanks very much for the suggestion!
Comment #15
andrewfn CreditAttribution: andrewfn commentedThere was a discussion for the Encrypt module where it was decided that a good (although not perfect) place to store the passphrase is in settings.php.
The thread itself seems to have been lost in the move from cvs to git (gives a page not found) but the details of the commit can be found here:
http://drupalcode.org/project/encrypt.git/commit/baba0ec
The same ability has been added to urllogin.
Note that once an intruder has write access to the database, no solution is secure, since they can turn on the php input filter and add/modify a node to contain the php to display the passphrase. If it can be accessed from php, it can be exposed! For this reason, storing the passphrase in another file does little to improve security.
However using settings.php to store the passphrase does protect against an intruder who only has database read access (through, for example, cross site scripting).
Comment #16
logickal CreditAttribution: logickal commentedAt this point, this looks to me to be very well thought out and the code looks good to me. I'm going to mark this one reviewed at this point.
Comment #17
logickal CreditAttribution: logickal commentedActually, spoke a little too soon. One more pass with Coder to fix some minor code convention issues (else if, PHP constant capitalization, use of check_plain() inside l()) and you should be good to go.
Comment #18
andrewfn CreditAttribution: andrewfn commentedThanks for the review!
I'm a little confused about the coder convention issues. I ran the April 16 version of Coder on the highest setting and it didn't find any problems.
Line 136: l() already contains a check_plain() call by default. See http://drupal.org/node/28984
However, I did find an extra space in an if statement which I have corrected.
Can you point me to where you saw the problems because I have sometimes found Coder misses things.
Thanks.
Comment #19
logickal CreditAttribution: logickal commentedSure thing Andrew - I'm sorry, I made a hash of that whole process, apparently and got two modules I was reviewing confused. I'll go back to my original statement - "this looks to me to be very well thought out and the code looks good to me." Sorry for all of the confusion, everyone.
Comment #20
rfayGit vetted user role granted - thanks for this contribution and all your future ones!
Wonderful, clear communication. Thanks for that. Please keep it up and teach others!