Problems? Is your data what you think it is? | |
PerlMonks |
RFC: Updating and Claiming Ownership of Nodes initially created by Anonymous Monkby Perlbotics (Archbishop) |
on Aug 06, 2011 at 17:17 UTC ( [id://918960]=monkdiscuss: print w/replies, xml ) | Need Help?? |
This RFC shall address the following two issues
Current Situation
After hitting the create button, a node owned by AM cannot be updated anymore.
This is obvious since several AMs cannot be distinguished from each other (AM#1 could edit node of AM#2).
Basic ApproachThe basic idea is to present an unlock-phrase that can be used for a given node to editing and/or to claim ownership of this node. The unlock-phrase is presented after hitting the create-button. An AM who intents to update the given node or who later wants to claim ownership has to remember this unlock-phrase. Maybe the unlock-phrase can be saved as a cookie? Usecase: Updating a Node owned by AMWhen logged in as AM, presenting the unlock-phrase allows to edit the node. A new unlock-phrase is created after the update button has been hit. The option to edit a node owned by AM is time-restricted (e.g. 5 days). After this time, no further update is possible. The time window restriction makes it easy to protect old nodes owned by AM. Furthermore, it might reduce the PM servers load. Updating a node must not reset the time-window. Usecase: Claiming Ownership of a Node owned by AMDuring a time window of e.g. 5 days, a regular PM user, who is logged-in, sees an option to adopt a node that is currently owned by AM. Maybe this option can be switched on/off by means of CSS and/or Display Settings? If the user enters the correct unlock-phrase, the ownership is transferred. Since the node is now owned by someone else than AM, the option to transfer ownership vanishes. Reputation and XPI am not sure about that. Maybe reputation is transferred completely but not XP. So, XP changes while the node is being owned by AM goes to AMs account, while XP-changes after claiming the node go to the users account. Implementation Considerations
It should be possible to implement this RFC without introducing changes to the database layout.
The unlock-phrase could be created by hashing (e.g. MD5) a secret initial vector + the node-content + the node-ID + some other unique node-specific value. Then the digest is transformed into some human-readable unlock-phrase. Something along the idea implemented by Digest::BubbleBabble.
Update: I assumed, that the DB has no spare field left to store the hashed key-phrase. If it actually has, wonderful. Just generate a random unlock-phrase and store it's salted hash (e.g. bcrypt) for later validation. Drawback of this method: If the node is edited by a janitor, the unlock-phrase will change, making it impossible to edit/claim that node later on. From a security point of view, the secret initial vector is the weak point (security by obscurity). If this is a constant value (e.g. hard-coded), an attacker that gets
into possession of this value could hijack/modify every AM post within the time window. That could be alleviated by using a secret vector that changes daily (lookup-table or computed = f(creation time)). Ideally this vector would be an individual salt, but storing that would require an extra DB field. Time window (response to #919042): 5 days was a first guess, but I consider 5hours too short. If I come back one day later and want to update a node, than I need a bigger time window than 5 hours. In principle, it would be possible to have two time-restrictions: maybe 24 hours to claim a node and 48 hours to update a node?
AcknowledgmentsThis RFC has been refined during a short CB-discussion involving the feedback of tye and mr_mischief.
Back to
Perl Monks Discussion
|
|