Oliver Zeigermann wrote:
I still do not see the real need for the external repository to identify a user with every request.
Lets say we have a "repository" that is a document management system, not RDBMS, like the examples I already gave, it cannot be a proxy user like a database connection and I cannot 'do it myself' if I don't have it in the first place. The interface/API to this application is all we have to work with to map as the Store.
OK, got it now. I'd say the path to go is one level above the stores then. There are those interfaces Structure, Security, Macro, etc. with their respective default implementations StructureImpl, ACLSecurityImpl, MacroImpl, etc. All those interfaces/classes get the SlideToken in all their relevant methods. Have a look at SecurityImpl.getPrincipal to get an idea how to find the user stored in CredentialsToken accessed by SlideToken.getCredentialsToken() and what to do with it then. So, what I would propose is changing those implementations to your needs. I do not think those implementations are really configurable, but at least they are all initialized in the ctor of NamespaceAccessTokenImpl. Just change it there for now. If you get it all working, I am pretty sure we will find a way to integrate all this into Slide and make it configurable.
Oliver
So with Slide no thought was given to stores other than databases? Sad and I thought Slide had a lot more promise!>
I guess I will just have to extend from a higher level, this sucks.
Let's have a look at an RDBMS as used in the J2EEStore. Upon connect there is a single authentication for *all users*. No need for later authentication. I guess that's the way authentication is done in most application server environments: Do not use RDBMS authentication, but use a single user and do the rest yourself. Doesn't this work for you? If not, adding user information to store requests would really be a *HUGE* impact and nothing you can you adhoc IMHO.
Oliver
Mike Oliver wrote:
What about a callback that we could use from the Store to request the Principal related to a Transaction? Don't we have the TxId on just about all the methods and with that wouldn't we be able to get the Transaction and the Principal with that?
I know that any external repository is going to need to authenticate, so I think this is going to be a needed capability, the Stores will need to know who is asking. Is their someplace where adding a getPrincipal could be easily added and inherited by the Stores? I for one REALLY need this info.
Ollie
Oliver Zeigermann wrote:
Mike Oliver wrote:
One of the features of Slide on the web site since 1.0.16 is the following, " It can integrate and manage data stored within external repositories, requiring only small abstraction layers to be written for each repository." If I want to use Livelink, Lotus Notes, Documentum, FileNet, PcDocs, SAP, and the list goes on as an "external repository" THAT repository will undoubtedly want to know "who stores content". Are not the Stores this "abstraction layer" the web site still refers to?
Hmmmm. I am certainly not a security expert, but I understand the SecurityStore together with Security (package org.apache.slide.security) is in charge of identifying users and rights. Haven't I heard somebody talk about a LDAP implementation of SecurityStore? Can not find it any more...
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
