Eric,
Here is the security stuff we talked about on Friday. I ended up refactoring the entire service, supporting interfaces and classes to make things more flexible.
Here is a quick run down:
SecurityContext: Individual "thing" that can be secured. Examples: template, action, portlet, etc. It's very basic.
ClassicSecurityContext: SecurityContext implementation based on current T2 security.
SecurityContextLoader: Basic interface for something that can load SecurityContexts.
Scope: This interface extends SecurityContextLoader and gives it a little more meaning. A Scope acts as a container for a logically grouped set of SecurityContexts. It uses ContextKeys to locate individual SecurityContexts.
ClassicSecurityScope: Concrete implementation of Scope based on T2 security. ClassicSecurityScope loads SecurityContexts defined within an xml file based on the SecurityScope.dtd. ClassicSecurityScope uses ClassicSecurityContext to create it's SecurityContexts.
QuarterMasterService: Turbine (Fulcrum) service interface that helps load and retrieve any number of disparate SecurityScopes.
JDOMQuarterMasterService: Concrete implementation of QuarterMasterService that uses an xml file based on the ScopeDescriptor.dtd to load any number Scopes.
ContextKey: Interface describing how to uniquely identify a SecurityContext.
GenericKey: A base concrete implementation of ContextKey that is a comparable key and can be used to uniquely identify an individual SecurityContext within a Scope.
ActionKey: Convenience class that extends GenericKey to identify Actions and ActionEvents.
TemplateKey: Convenience class that extends GenericKey to identify templates.
TR.props entries:
services.QuarterMasterService.classname=org.apache.turbine.security.turbine.JDOMQuarterMasterService
# location of the Scope descriptor file.
QuarterMaster.scope.descriptor= /WEB-INF/conf/ScopeDecscriptor.xml
That's about it. I hope the code format is up to standard, I ran it through Jacobe http://www.tiobe.com/jacobe.htm. If it is not, let me know and I will do whatever is required to clean it up.
Also, I took some liberty with the naming. If there are any concerns, disagreements or name collisions (and I'm sure there will be ;-) we can work through them.
Regards,
Scott
-----Original Message-----
From: Eric Dobbs [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 08, 2002 1:27 PM
To: Turbine Developers List
Subject: Re: Security Changes (3 of 3) - Subject, Principal, Project
detai ls
On Friday, February 8, 2002, at 11:27 AM, Weaver, Scott wrote:
> I'm buried today, but will work on de-coupling the service from my
> stuff and
> cleaning it up this weekend.
>
> Does that sound like a plan?
Sounds great.
-Eric
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
security.zip
Description: Binary data
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
