Last modified: 2010-11-26 14:16:45 UTC
There are few things worse than losing a long edit because the wiki says "you are not logged in" after committing the changes. For whatever reason, the back button on the browser doesn't work, and you've lost all your work. This can be approached as a workflow problem. As a user is not permitted to commit edits, he never should have been allowed to imagine he were. One solution is to presented the user the log-in page the second he clicked "edit". Then this problem would have been avoided. But that's not the best solution. If this were applied as a general rule to all wiki pages, it would make it impossible to see something neat on a wiki page and then "edit" it in order to understand the code, even if it's impossible to commit. So the ideal workflow would be to be presented with an edit page if logged in, or a static view of the wiki code if not. Or perhaps if not logged-in to be presented with a wiki page that only has the "preview" button, not the "submit" button. In any case, the idea is that an unauthorized user not be allowed to try to submit to a site when it's clear he can't. This seems like an easy feature to add (as a first step see if the user is authorized to commit edits before drawing the submit button), and would add another layer to prevent loss of data. P.S. I am filing as a bug, not a feature request, because loss of data is always a bug, no matter who is at fault.
Semantic Forms already does this, no?
Yaron, could you point to a wiki installation that does that? Ours doesn't with a standard setup, requiring emailconfirmation to be able to edit pages. There are three parts to this problem: 1. The Form Namespace. Solved this by using the Lockdown extension and the following rules: $wgNamespacePermissionLockdown[106]['edit'] = array('sysop'); $wgNamespacePermissionLockdown[106]['read'] = array('user'); 2. The Special:FormEdit page, solved as well using Lockdown: $wgSpecialPageLockdown['FormEdit'] = array('user'); 3. The formedit action, solved, again, as $wgGroupPermission doesn't have a 'formedit' key, using Lockdown: $wgActionLockdown['formedit'] = array('user'); Failing to do this, forms are always accessible, even when not logged in. While the "edit with source" link says that login is required, the formedit action displays the form and loads the data. All it does it say that instead of a username, the IP will be logged. Have I missed a SemanticForms config option then?
Ah, I see - I bet this is an issue with the Lockdown extension specifically. I'll try to look into it. I also changed the bug title, to more accurately (I think) reflect the issue.
No I believe I wasn't very clear in my description. The Lockdown extension actually works. The behaviour I described at the end is without lockdown. The only behaviour that could be improved would be the page displayed on lockdown's actionlock. Now there is only an empty page. But I'm not sure whether is is up to lockdown or SF to fill that page.
Well, now I'm completely confused. Wasn't the issue that SF displays an editable form for a page that's not actually editable, due to Lockdown?
Sorry for confusing you. No, actually not. The issue is that SF displays a form, regardless whether a user is actually logged in and has thus edit rights on the loaded page. Take this example, leaving lockdown totally out of the loop: Your wiki is set only to allow emailconfirmed users to edit pages. Now when a person that is not logged in visits the site and clicks the "edit with form" link, he or she is presented with a form and data, as well as enable Save and Cancel buttons/links. The person only notices that she wasn't allowed to edit until after she submits the form. Lots of typed text is lost and fury ensues.
Oh, I've just now noticed that the subject says exactly that. Well then the subject is plainly wrong. Sorry, that would have been a miscommunication between Kenn and myself then.
Actually, I was the one who set that bug title. Anyway, SF shouldn't be doing that. Do you have a URL that shows this?
Give me 2 minutes to disable lockdown, then try any of the Forms under the Tools menu at https://www.hackerspace.lu/wiki/Syn2cat
Aha, now I see the issue; I changed the title, again, to reflect it.
You uncovered a bug in MediaWiki, which I sent a note about. Anyway, this was good timing - I put in a workaround for it into SF, and I just released a new version of SF (2.0.5), so this fix is already in the new version.
Neat! I have now updated the SF extension and removed the LockDown extension. I can confirm that access controls are working correctly now. Thanks Yaron.
