On Thu, 2006-09-28 at 08:58 +0200, Jann Forrer wrote:
> Joern Nettingsmeier wrote:
> > Thorsten Scherler wrote:
> >> On Tue, 2006-09-26 at 17:50 +0200, Jörn Nettingsmeier wrote:
> >>> before we start a REOPEN war on bugzilla, let's discuss this here first.
> >>>
> >>> imho an exception caused by a normal gui operation is always a bug.
> >>> imnsho a "deny" credential for the role "edit" that leads to a loss of
> >>> "visit" for the user admin is a blocker bug.
> >> The thing is a user can have more then one role. Lenya e.g. has the role
> >> "edit, admin, visit", now we test whether we find credentials for this
> >> roles, if there is a credential (with high priority) which deny access
> >> for editor then lenya get locked out. To allow lenya and not any other
> >> editor have a look at our documentation. 
> > 
> > again:
> > 
> > log in as user lenya.
> > go to site overview, select page "document type examples".
> > open "ac authoring" tab.
> > as an inheritable credential, add { group:edit, role:edit, deny}.
> > press "add".
> > as an inheritable credential, add { group:admin, role:edit: grant}.
> > press "add". pooof.
> > 
> > 
> > the problems are these:
> > 
> > 
> > the usecase permissions for tab.acLive are "admin/grant".
> > lenya (as an admin) should be able to commit the second change, even
> > after taking away the edit permission for one of its own group
> > accreditables, as changing ac calls for the "admin" role (which was
> > never touched). that seems like a big bug.
> > 
> 
> I reconstruct this ac behavior and i agree with joern. I really can't
> find a reason why an admin user is not able to change ac entries (if for
> the group edit the role edit is denied). The consequence of the first
> transaction should only prevent the user lenya (if he is a member of the
> group edit) from editing the content of a document.

Hmm, did you try to create another admin user (which is not in the
editor group) and logged in? 

Try http://lenya.zones.apache.org:9999/default/authoring/concepts.html
before the next build with user lenya. -> Access Denied

Now try with (user: admin, pass: 123456) -> Access Grant

It looks out the user lenya which is as well member of the editor.
http://lenya.apache.org/docs/1_4/reference/ac.html#Concept
"The order of credentials at a node is important."

http://lenya.zones.apache.org:9999/default/authoring/links.html
Here I changed the order allowing the admin group first and then deny
the editors. Login with lenya now works like a charm.

...and even if we use a slightly different use case it pins down to
http://lenya.apache.org/docs/1_4/reference/ac.html#samples

If we want to change this see my bugzilla comment.

> 
> 
> > the user does not get a meaningful error message, and lenya throws an
> > exception. that is perhaps a small bug, but it needs to be fixed.
> > 
> 
> As joern said I think no gui operation should throw an nasty java
> exception. The user should be redirected to some page e.g. the login
> page or getting a meaningful error message.

Like I stated in the bug, I agree to catch this exception before it
happens asking the user if he wants continue regardless he will get
looked out afterward. If he agrees then yes there should be a redirect
instead of an exception.

salu2

> 
> 
> [...]
> 
> Jann
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to