Item10822: Ajax-Interface: Handling of WikiGuest / unauthorized access
Priority: Normal
Current State: Closed
Released In: n/a
Target Release: n/a
When viewing a table as
WikiGuest and then trying to edit a single cell, the log-in dialog gets displayed in this very table cell. Looks nasty.
The modification gets saved, but the redirection after log-in is broken.
- Maybe it would be best to hide all editing features if the current user doesn't have write permissions?!
- Or instead of hiding, the invocation of a single-cell edit should rather forward the user to the log-in screen and afterwards send him back to the original topic for editing the cell.
Setting priority to "normal", but feel free to change it...
--
PhilippLeufke - 01 Jun 2011
If the current user doesn't have CHANGE access to the topic, then none of the edit features are displayed. What rights does
WikiGuest have to the topic?
--
CrawfordCurrie - 03 Jun 2011
Well,
WikiGuest doesn't have editing rights, that's why a not logged-in user (
WikiGuest) currently gets forwarded to the log-in dialog after he tried to edit a table field.
Changing of the topic I'm talking of is not allowed to
WikiGuest. Trying to edit the topic results in the log-in dialog, as it should.
And yet, the edit features of the table are definitely visible for
WikiGuest in my case, using the most recent
EditRowPlugin.
--
PhilippLeufke - 03 Jun 2011
Yeah, I see now that it's a special case for wikiguest. Well, there has to be some way to prompt with a login, and there's no clean way to redirect the page in an XHR callback that I can find, so there's no choice but to do the prompt in the cell. There is definitely a problem though when saving on.
Similar issue applies when moving rows from a non-0auth starting point.
--
CrawfordCurrie - 03 Jun 2011