I think that was the reason nobody responded, as it is indeed right
there to see.  I think I missed it the first time because uri.toString()
was just about the only method on the uri object I saw in the sample
stores and thought it was a simple object.

Michael Oliver
CTO
Matrix Intermedia Inc.
3325 N. Nellis Blvd, #1
Las Vegas, NV 89115
Phone:(702)643-7425
Fax:(520)844-1036

-----Original Message-----
From: Fallin, Jonathan A. [mailto:[EMAIL PROTECTED] 
Sent: Monday, July 19, 2004 9:57 AM
To: 'Slide Users Mailing List'
Subject: RE: Getting at User Principal in Slide

I am blind!  At almost the same time I received your last post I was
looking
again at the URI object in the javadocs.  Thank you!

Jonathan 

-----Original Message-----
From: Michael Oliver [mailto:[EMAIL PROTECTED] 
Sent: Monday, July 19, 2004 12:52 PM
To: 'Slide Users Mailing List'
Subject: RE: Getting at User Principal in Slide

I learned this the hard way as when I asked this question, nobody
responded
to tell me to look at the Uri object passed to almost all store methods.

In it you can drill down with 

uri.getToken().getCredentialsToken().getPrincipal().getName()

The uri is the golden key to get at most every object.

I needed one more bit of info that I couldn't' get through the uri, and
I
used AspectJ to extract that and write it to a shared table that was
keyed
on my thread, so now I have everything I need.

Michael Oliver
CTO
Matrix Intermedia Inc.
3325 N. Nellis Blvd, #1
Las Vegas, NV 89115
Phone:(702)643-7425
Fax:(520)844-1036

-----Original Message-----
From: Fallin, Jonathan A. [mailto:[EMAIL PROTECTED]
Sent: Monday, July 19, 2004 9:31 AM
To: 'Slide Users Mailing List'
Subject: Getting at User Principal in Slide

I have "successfully" written my own custom content store that
integrates
with an existing custom Content Management Application.  My CMA exposes
methods via an API that I have hooked into under the relevant store
methods
like retrieveRevisionDescriptor() and retrieveRevisionContent() etc.  I
put
"successfully" in quotes because right now all if the method calls to my
Content Management API have a hard coded username variable that's
required
for each call. 

I'm using a third party Servlet filter wrapped around the WebDAV Servlet
that's able to put the Windows Active Directory username into the
HttpServletRequest Principal object.  This works perfectly and wholly
unrelated to Slide.  I know that it works because the Slide WebDAV
Servlet
logger writes out the value of
HttpServletRequest.getUserPrincipal().getName() to the logs.

My final issue is this...How can I get at that User Principal name value
when making my content store method calls?

I see that the NodeStore, RevisionDescriptorStore, etc objects all
extend
the Service interface, and in fact my custom store implementation is
extending AbstractSimpleService.  I see a method in the Service
Interface
connect(CredentialsToken crdtoken) which is close to what I need.  I
know
that you can get at the name of the User Principal from that class.
However, unlike a store implementation built on top of a database, my
existing API methods do not really have a connect(), isConnected()
equivalent.

I do not have a requirement to implement varying access control levels.
Either the user specified in the Principal object has full access or
none at
all on a given URI.  I've tried playing around with <auto-create-users>
tag
in Domain.xml but am still not sure how to get at the value when making
the
retrieveRevisionDescriptor() and retrieveRevisionContent() methods that
make
the eventual API calls.  And since I'm dealing with a user base of ~1000
people with constantly changing access rights at the existing Content
Management Application level, configuring usernames within the
Domain.xml is
not feasible.

Any help is appreciated.

Thanks

Jonathan


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

Reply via email to