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: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? > 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? -- 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]
