DUMB
Dragon Writer
Upping from bizarre side effect to bona fide bug.
Apparently, whenever you click the "Edit" link on an article (ANY arbitrary article), this automatically places an editing lock on that article. That's right — any arbitrary HTTP GET request on the article's Edit URL causes the article to be locked down from other edits for 15 minutes.
This is bad HTTP practice (GET requests aren't supposed to have any lasting effects) according to the W 3 C guidelines, and can theoretically enable mass denial-of-editing attacks.
Suggested fix:
- Only POST requests should actually place a lock on the article. Clicking the "Edit markup" link brings up the normal editing form without checking for a lock. It's only when you submit the form (via POST request) that it actually checks/places a lock on the article in question. If there's already a lock in place, it displays the error and bounces back to the editing form.
That fix completely misses the point of the lock feature, though.
Couldn't you change the edit article link into a tiny form and submit that via POST?
BTW, I'm a chick.
Lost in Space
This is like record-level locking in a database. If you open a record for editing, nobody else can edit it until you're done, at the risk of causing data conflicts.
I admit that it does present some denial-of-feature issues, but I'm not sure what a workaround would be - if someone puts an edit link to a page as a URL, Google's crawlers will try to traverse it. Eddie might be able to set things up so that agents identified as search engine crawlers don't trigger a page lock, or set it up so that the call to the edit feature has to be made from the actual edit button, maybe via Javascript.
"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"
DUMB
Well, would there be any way to make it so that the article is only locked after the "edit password is 'foamy'" dialog is resolved? That would keep out crawlers who can't read.
[1] This facsimile operated in part by synAC.
Only one lock is allowed per IP address. Being told you can't save a change after you have done the work is very annoying.
Editing is already restricted from agents that can't fill in the 'foamy' password.
I think this 'mediapartners' encounter is a spoofed user agent.
edited 28th Sep '10 8:47:32 AM by FastEddie
Goal: Clear, Concise and Witty
Dragon Writer
Well, user-agent is clientside data, so....
Reminds me of Media Wiki's "Edit Conflict" screen, where the editing form stores the revision number of the article at the time, and it checks for other commits upon submit. If there is, it bounces back to the form with an error, a diff, and instructions on how to resubmit the form.
I guess I'm just used to hitting the "Edit" button when I need to simply copy/paste or view markup, since (being a Serial Tweaker and all) I often end up making some kind of edit anyway.
An Ear Worm is like a Rickroll: It is never going to give you up.
Lost in Space
I try to always cancel my edits if I inadvertently hit the button or was just copying markup, so I don't keep the page locked for someone else.
"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"
If you do forget, getting the lock on the next page you edit surrenders any other lock you may have out there.
Goal: Clear, Concise and Witty
This entry is checked out until 10:14 Pacific Daylight Time by Mediapartners-Google.
(ScreenshotWait, what?
edited 27th Sep '10 10:05:19 AM by Stratadrake
An Ear Worm is like a Rickroll: It is never going to give you up.