DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=42952>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42952 ------- Additional Comments From [EMAIL PROTECTED] 2007-08-03 01:49 ------- (In reply to comment #15) > (In reply to comment #13) > > > this patch introduces two special cases: > > * the "visit" role is used by the PolicyAuthorizer to grant access to pages > > * the "users" group is given visit rights and is presented as "default > > group" > > in the addUser usecase. > > Do these have to be added to each publication manually? the visit role yes. but currently, all roles have to be added manually, as well as a workflow, so that does not count against the approach imho. the users group is a convenience thing that users could do without if they want. i'd like to add a default="yes" attribute to the gml file grammar, and new users will be in that group unless the admin explicitly untags a checkbox in addUser.jx. gets rid of the hardcoded stuff. wdyt? > > this is ugly. but it could be remedied with a new "pseudo-usecase": > > ac.visit. > > it doesn't do anything, but it has roles attached to it via > > usecase-policies.xml, and the policyAuthorizer could maybe delegate the role > > checking to the usecaseAuthorizer. gets rid of the hardcoded visit > > semantics. > > that leaves the default group. it could be made configurable in the gui > > (thus > > putting the semantics into the publication, where they belong), or we could > > introduce a new accreditable <anyUser/> that includes all authenticated > > users. > > probably easier to maintain than an extra group... > > Well, I have to admit that the ac.visit pseudo-usecase doesn't sound more > appealing than the current implementation ... I guess I'd even prefer the > visit > role + default group approach. But maybe it needs a bit more of discussion. Is > it really necessary to tackle this before 2.0? actually, i find the usecase idea quite appealing - basically it means that users can define a "visit" policy for ac.visit using an existing mechanism, and the policy authorizer uses that policy. not too quirky imho. we can even implement a real ac.visit as a document usecase... right now, the policy authorizer does not implement a policy for viewing pages, and i consider that a blocker bug - it opens up security holes whenever somebody tries to do something clever with our otherwise nice role and permission model. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
