By stri_berry on
I have a custom content type that I'm allowing even anonymous users to create. I would like to also give them the ability to come back and edit their creations after they've first published it, but that's the challenge.
Since they are "anonymous", I would guess there's no way for the drupal permissions system to tie the content back to the user that originally created it.
Where does that leave me? I'm thinking browser cookies or something along those lines? I'm not sure.
Is there an existing module that could help with this, or ideas to create a new one?
Comments
Generally, no. That's largely
Generally, no.
That's largely why so many sites for the last decade tried or required you to 'sign up' all the time. It's not about gathering user data or boring stuff like that, it's because for any sort of persistence, the system needs to know who you are to match you up with what you did last time.
Not only are anonymous users unable to be authenticated next time they "come back", but within the user management system, 'anonymous' is one user. So allowing 'anonymous' to edit posts by 'anonymous' would mean that all individuals could edit other folks content.
An attempt at making this happen would be to auto-create a dummy user of sorts behind the scenes when any 'anon' user does something worth noting. You'd be able to make that happen with logintoboggin or similar I think, though I don't know.
After that, cookies will help a little bit, but only so far.
And of course there's no security at that layer, nor would folk be able to recover their identity if lost. But that's all predictable.
So look at logintoboggin. It might provide enough of a slipstream into user creation to prevent the normal 'registration' annoyance.
.dan. is the New Zealand Drupal Developer working on Government Web Standards
I looked at what
I looked at what logintoboggin does, but couldn't find something in it to help with the dummy user creation. It's a good idea though. Thanks for the hint.
I am about half way there.. I
I am about half way there.. I made a form that can validate on a cck field. Right now the form sends you to the edit screen of that node if the pass words match. That was pretty easy..now I have to figure out how to limit access to the edit screen for only that particular form submitter. Otherwise, any anon user could go the node/#/edit and have access.
I got this to work. I used a
I got this to work. I used a session variable and a form template file to solve the access problem.. My form submit function stores a $_SESSION variable if the passwords match... it also sends you to the edit form of the node if they do... My form template file then does a check on that variable. If it returns true then it simply renders the form..if not it gives an error message. It also unsets the variable once its checked. This is a very simple way to do it for what I needed.. I'll happily post my module and template code if anyone wants to take a look.
Can test if needed
I'd love to try it out on localhost before you post it to the repo.
I also want to test out the Session Favorites module since it ties to the Sessions API.
http://drupal.org/project/session_favorites
Here is my module.. and the
Here is my module.. and the node edit form template below it.
Its very bare bones but does the job for one content type for now... This works with a cck content type I made called "an_content_edit_test" . The permissions are set so anyone can edit it.. I am using a field called "field_anon_pw" from that content type for the password. I also dump the form I made right on to the node page via the hook_nodeapi function. Thats a pretty ugly way to do it but it was easy to test. A better way could be to call the custom form on a node template with drupal_get_form.
Notes.. Like I said..it only works with one content type that is hard coded in the module. It will lock everyone out of that node content type edit screen unless they pass the check.. or you change themes. That part could easily be re-written to add a check for user roles or user ID =1. Also I did this pretty quickly and barely got a chance to test or review it so definitely use at your own risk.
The module name is anpwedit..
Here is the node edit template for the content type this one is called "an-content-edit-test-node-form.tpl.php". Keep in mind you have to register the the template in your theme template file. http://drupal.org/node/85908#comment-1972246 or like the bottom of the thread says..I think it could be added to the module as well.
Here is a working example that I will leave up for a few http://www.audiopolis.org/node/932 use mypass to edit it. You can also change the password if you want but it will muck up the demo for any one else till I can change it back :]
I noticed someone else asked
I noticed someone else asked this same question a little while back..
http://drupal.org/node/844780
I don't know of any module's out there that have this particular feature but ,the suggestion at the end of that thread sounds like it will work if you did it in a custom module.
Make a password field or an e-mail field that is not displayed in the node but, is required when you create it. Then you could use that password field in your custom module as the 'validation' for the edit button. I might need something just like this pretty quickly...so if I can come up with decent example I will post it.
Yeah interesting. [#844780]
Yeah interesting. #844780: How could an anonymous user edit own nodes only ? is an OK idea, a per-node keyphrase.
Still requires the user to think and remember - which is usually why folk want to skip the registration step, but the user can choose what they want, eg their own email. Up to them how 'secure' they want this to be.
Ideally I guess that could be a small contrib field widget. Shouldn't be too hard to lock the value and validate it and complain on submit.
Plus you can leave it blank to create a wiki page!
.dan. is the New Zealand Drupal Developer working on Government Web Standards
Looks like this is a popular
Looks like this is a popular request. Not sure why there isn't a module for it yet.
I'm very new to drupal, so not that familiar with its hooks and not sure if I can write a module yet. But if you can, we can brainstorm together.
I like dman's idea of the dummy user that gets created when a user does something of interest.
The fivestar module seems to be logging the voter's IP and UID 0 into the voting_api table, though that's not very reliable and won't be a persistent identifier for a considerable subset of users who use DSL or renew their IP.
The password field idea is good in that it isn't tied to the user's IP or cookies, so if the user changes their IP or clear their cookies, they can still edit their nodes. It's as close to an account as we can get. But I don't think it should be password per node. In other words, I wouldn't generate the password for the user. This way the user can enter the same password for all nodes they create.
I have a problem with it though. Because no session is saved, we can't alter the html to make it show an Edit link only for nodes created by this specific user. Users can't identify their nodes just from a very quick glance. Also there's no way for them to pull the list of nodes they created for example. This however is possible when sessions and cookies are used.
What's your take on this?
Well, most of those concerns
Well, most of those concerns are why we have (to have) registration.
It's so that you, for the duration of your interaction with the site, have an identity. Even on IRC, or if people are shouting in a crowd, you need to link who said what with what. Anything else is chatroulette.
Anything short of an actual userid is a limited work-around.
The two options briefly looked at here place temporary authentication either with the user session (browser-cookie only) or with the data itself. Both are sub-optimal, but may have their place.
Trying to blend both half-baked ideas will lead to madness.
Making a user account silently or by default has hidden problems that surface later, and can create headaches whenever you want to do anything more advanced or expected from social media sites. An anonymous user cannot reclaim their content or account if they can't prove themselves later.
.dan. is the New Zealand Drupal Developer working on Government Web Standards
How about the Session Favorites module
Want to add that I just found an interesting module called Session Favorites, which depends on sessions (the Sessions API)
http://drupal.org/project/session_favorites
Maybe in conjunction with the password field idea, it could give us the best of both worlds. I'm thinking this:
- When the user creates a node, they enter a password, AND a session is logged in the database like Session Favorites does it.
- Until the user clears their cache, editing is based on the session
- The password field comes to play when the user clears their cache, or if the user tries to edit a node that isn't associated with their session
I don't want edit option to anonymous user in navigation menu
hi
I have just opposite prblm...in my site , its giving edit option in content to anonymous user. How can i restrict it?
/admin/user/permissions
/admin/user/permissions
.dan. is the New Zealand Drupal Developer working on Government Web Standards
Weird, very weird... I also
Weird, very weird... I also have content types that anonymous users can create, so they're owned by UID=0. At
./admin/user/permissionsI set the permissions fornodemodule so that no anon could delete or edit his/her "own" node. I believed that this would be what I wanted: Allow good anons to create content, but disallow bad anons to vandalize it. Too bad I never bothered to verify this.Alerted by my recentchanges, dozends of these anonymously created nodes just got vandalized by a Turkish link spammer. And indeed, anons can edit content created by UID=0, they even can delete it. The actual permissions are simply ignored. That's really nasty.
This happened on Pressflow 6.22 with up-to-date modules and no pending database updates. Also I'm running Nodeaccess (6.x-1.3), and I suspect that this "access control" module breaks the core settings by overrding them by more permissive settings. Could someone please check if "just" my Drupal is borked, or if this can be repoduced on other sites with/withour the "Nodeaccess" module?
Workaround: For now I disallowed anonymous content creatation completely and changed ownership of all anon content to a system user. As it seems this fixes the security issue (at least the "Edit" button for anons is gone), but it is not the way I want the site to behave... :-(