I have a need where site visitors should be able to create and then later update content without ever creating an account on my Drupal site.
For example, think of a donor registry, where the donor creates a personal profile and perhaps several items they might be able to donate. Let's say we don't want to create a Drupal user account for every donor (they rarely login, or abandon the account completely). So instead, we email them a link containing a special hash/token. Later, when they click the link, Drupal verifies the hash and through clever manipulation of the menu system (see hook_menu_get_item_alter) bypasses the 'access callback' and lets them in.
What security issues do you see with this approach? Are there better approaches? Are there already other modules that do this? I've already looked at the tokenauth module, which solves a completely different problem.
Comments
I have a similar use case
I have a similar use case to implement on one of my sites. It would be great if we had a module for this.
Subscribing for now... :)
A different approach would be
A different approach would be to create an special user, for instance called: "accountless" and log all access without account as that single user when a certain token has been received.
In that way you could track by uid if they are logged in and setup general permissions for that special user (that could have also it's own role).
If you do otherwise, without using the Drupal login funcions/cookies, keep in mind that those "accountless" users are still of role Anonymous.
cube inspire - web design and web development solutions !
Users.
You haven't said anything that would suggest not using user accounts.
@DamienMcKenna, what I mean
@DamienMcKenna, what I mean is that technically is impossible not to use user accounts... even anonymous users are registered on the database as user 0. Permissions and accesses wise...
If you want to keep users as Anonymous then you can generate access tokens to postpend to an url. If the token is correct then the normal content is displayed if it's wrong then it can redirect to a different page.
hook_menu(), declaring and url of type myurl/token with a page callback that test the validity of the token and redirects with drupal_goto() in case of wron/expired data for instance!
For the token generation you could use hook_schema() to create a simple table to store valid tokens and their creation and expiration timestamps
.
hook_cron() could automatically generate and delete those tokens when the expiration date arrives.
After to easily attach those tokens, as they are not specific to any user, you could just show them on an administration page...
Regarding security, as the tokens doesn't give any permission, all depends on the nature of the content displayed on the page that will be accessible once the token is valid.
cube inspire - web design and web development solutions !
I agree with Damien. What is
I agree with Damien. What is the problem with creating user accounts and just hiding the username/password stuff and telling the person they have to login using the special tokens they get in emails?
That seems like a lot less work than trying to bypass all the user access/permissions code.
knaddison blog | Morris Animal Foundation
because anonymous users allow for better edge-side caching
I agree that there isn't much gained in avoiding the creation of user-accounts etc. But the real gain is the performance boost one could get from edge-side / front-end caching (such as Varnish / nginx), since most users are anonymous, they get a cached version of the pages.
This can lead to significant performance gains if you have thousands of active users. Most users' requests will never touch Drupal because they are anonymous and can be served cached copy of the pages by the web-server (nginx) or proxy-server (Varnish).
Combine that will jQuery/AngularJS -based single-page-apps and you get best of both worlds - CMS capabilities of Drupal, with the performance of static HTML front-end and hand-crafted RESTful back-end.
--Jitesh
SpinSpire - Enterprise Drupal!
You can only achieve
You can only achieve significant performance gains with edge-side caching if the content is the same for all users.
In your example, you want the content to be unique per user, so therefore it can't be cached.
It is still possible to have
It is still possible to have a globally same content for all users (cached), with the exception of a few blocks whose per-user content is fetched in real time with Ajax (non-cached).
This of course requires some specific development on your site.