>> so I think WebdavResource needs another constructor, where you can pass in a HttpState (WebdavState in our case), that you have configured to your own needs.
Probably. Torsten > The problem is essentially the same as with proxy > authentication. These things are held in the HttpState of > HttpClient. Basically that state is configured in > WebdavSession. I have already added constructors to WebdavResource to > pass in proxy information. Adding more constructors for the various > cases would be overkill, so I think WebdavResource needs another > constructor, where you can pass in a HttpState (WebdavState in our > case), that you have configured to your own needs. > > Regards, > Ingo > > > >Just to help me understand a bit better: What kind of cookie mechanism > > >is that? When surfing the web from a regular browser, how does that > > >single-signon look like? > > > > > >Torsten > > > > Our intranet sites require a certain cookie to be present that has your > user > > id and a hash string that validates you. If you don't have it, you are > > redirected > > to a login page. When you login, you get the cookie, and then are > redirected > > back to the original page. > > > > Our WebDAV server (which is not Slide, BTW) has this protection in front > of > > it, so it doesn't use basic HTTP auth to authenticate- it requires the > cookie. > > > > So I need to add this cookie to the initial request. I noticed that the > > > Slide Client > > tries to connect, and then asks for username/passwd if it gets an auth > > exception. > > What I am looking for is a way to set the Cookie before the request, > just like > > the username/passwd. > > > > Thanks --Joachim > > > --------------------------------------------------------------------- > 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]
