By oliver soell on
okay this might sound a little strange but I'd like to have a drupal site which has no usernames or passwords. Users would have accounts, but their username would essentially be their email address, and they would log in by entering their email address which would trigger an email being sent to them with an unique url, and clicking on that url.
How might people go about this? The passwordless part could be done using a custom login module and this module:
http://drupal.org/project/identity_hash
But how would people suggest I create a site where people don't have usernames?
cheers,
-o
Comments
depends
What exactly are you trying to accomplish?
so many things in drupal require verifying against the userid,
that its not practical to NOT pass a userid (you could just use '0' which is the anonymous user.
Your idea intrigues me, and i'm willing to help, but i need a better idea of WHAT you seek to accomplish. what will users do while at your site? make posts? upload files?? more info please.
well
briefly, I'm planning on moving my company's newsletter system to drupal/massmailer/phplist (with some major mods because we require bounce processing and better templating/mime-multipart-alternative support than the unadulterated massmailer system gives you). We would like it to remain such that there are no usernames and passwords, since we have usernames and passwords on our main site and I don't want to try and synch them up. We can easily migrate the userbase from the older newsletter system to this newer one, creating drupal users who indeed are all "verified" since we communicate with them through email. New users would go through the regular signup process (modified slightly as per the username issue).
So, at the bottom of each newsletter, there will be a unique URL (using the identity_hash module, if I can figure out how it actually works) to access our system as their user account. We do not want to have "usernames" but rather have each account represented by the email address itself. I suppose we could fudge it and hide the ability to change one's username, and simply load the email address into the user field, updating the "username" if the email address changed. This would probably be a fine idea if the username key is relied upon heavily in the core. yes?
thanks for any thoughts on the subject!
cheers,
-o
well, first off:
well, first off:
translating the old system's User/passwds is almost dead simple.
But i think we can manage something.
lets forget about the identity_hash, as it doesn't do what you want/need.
Here are my questions:
* are your 'users' allowed to create nodes/newsletters
or are they strictly limited to comments?
* is there any reason you can't treat the users as real users?
ie: custom login function that takes a email address and NO passwd. each unique email will get a user id, and plugin to the permissions system as normal.
for now, the users will ONLY
for now, the users will ONLY be able to modify their newsletter subscriptions and their own demographic information. nothing else - no node creation. everything else on the site will be available to anonymous users, and there will be no comments or anything.
the users will be treated as real users, except that they will not have a username that is different than their email address. we don't want to confuse our users (don't laugh). they should be identified as their email address only.
The more I think about it, the more it seems like I should just hide the username field in the registration process, and put people's email addresses in their username field. simple.
I do think that the identity_hash will work though, unless I am totally misunderstanding what it does - it will allow me to create a hash for a user (during the emailng of a newsletter, for instance), which then can be used to avoid the username/password pair on login?
cheers,
-o
identity_hash just give you
identity_hash just give you an alternative means to refer to a user in posts etc.
The more i think about it,
The more i think about it, the key here is storing info in a table
indexed using the session id.
That user 'exists' for as long as their session is open.
One side effect of this, is that evry node created would be 'not verified' since it would be linked against uid 0, but have the emailaddress as the users name.