Your reply begs a question as to whether forms auth can be used with MS
WebFolders, Adobe Acrobat, NetDrive and other commonly available DAV
clients. Have you used forms auth with these clients before? I would
assume the client would need a browser to be able to support forms auth
which _may_ be possible for webfolders (though I haven't gotten it to
work) but I'm less confident that clients like Acrobat and NetDrive
could support it. 

I would be very interested to hear people's experiences with using auth
mechanisms other than basic auth with these clients.

Thanks,
Warwick


> -----Original Message-----
> From: Michael Smith [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, February 10, 2005 5:47 PM
> To: Slide Users Mailing List
> Subject: Re: AW: accessing slide on the server side
> 
> 
> Daniel Florey wrote:
> > Hi Kolja,
> > I've been facing similar problems when working on the Projector 
> > framework. The main problem is that you'll not get the full 
> > user/password information out of the user credentials that tomcat 
> > provides (for security reasons). My choice was to provide a 
> login-box 
> > at portal level and not to use the standard http auth schema. The 
> > entered data can be used to pass this information to Slide 
> using the 
> > standard http authentication on Slide level. If you want to 
> provide a 
> > single user base and expose this to the end user with http auth the 
> > only way is to implement Kerberos authentication in your portal and 
> > Slide as this enables you to pass the user information from 
> the client 
> > to the portal and finally to the Slide server.
> 
> Another possible approach is (if you're using only HTTP Basic auth - 
> whether over SSL or not) to simply parse the Authentication header 
> yourself, and get the username (well, you already have that from the 
> servlet API) and the password (which is the key bit!) from it.
> 
> Then you can use the client lib as normal.
> 
> It does limit you to Basic auth, though, which may cause problems 
> elsewhere. Using an HTML form login, as Daniel suggested, is a good 
> alternative - or you could provide both.
> 
> Mike
> 
> ---------------------------------------------------------------------
> 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