> > Even for resources that are readable for for anonymous users I get the basic > > authentication popup of the browser. Surely, this can be suppressed (maybe > > by wrapping the WebDAV servlet?). But this also made me wonder how the > > single-sign-on would work between a (raw, unwrapped) WebDAV-based part (that > > uses basic authent) and microsling (that uses the jsessionid cookie/Java > > appserver mechanisms)? microsling could of course accept the basic > > authentication headers if a WebDAV login occurred first, but how would it > > work the other way round? first, why does microsling do a jesseionid based auth? i don't see the need to this at all (at least for the default auth handler). the way basic auth should work is:
- grab the credentials from the request and construct SimpleCredentiials. if there are no credentials, use NULL - login to the repository - if login fails, send a 401 i don't know why the webdav servlet sends a 401...actually it should allow anonymous access. regards, toby > > > > Cheers > > Michael > > > > > > On 10/19/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > > Am Freitag, den 19.10.2007, 15:09 +0200 schrieb David Nuescheler: > > > > Therefore I think that a GET to the exact repository path should > > > > generally be handled the same way as the WebDAV GET. > > > > I think this is very easy to understand for everybody and > > > > means that microsling generally works just like every > > > > other WebDAV enabled webserver for everything that is > > > > static. > > > > > > This sounds very plausible, but has some implications, which turn out to > > > be somewhat problematic. Therefore, I just added a StreamServlet which > > > streams a resource of type nt:file (which is most likely what is > > > required by Michael) and in addition support If-Modified-Since header > > > such that a 304 may be sent back just in case. > > > > > > This more or less should match, what WebDAV does in this respect, and I > > > think we are done without any special handling. > > > > > > > Personally, I think that this is a very simple and > > > > straightforward solution that leverages a lot of features > > > > implemented in WebDAV entirely correctly. > > > > Think of etag or modified since behaviour on GET > > > > or PUT and DELETE which all would have to be > > > > re-implemented in microsling. > > > > > > Streaming out of a Sling Application currently only discusses reading > > > (GET) not updating, which is done as described by Betrand using access > > > to the WebDAV servlet included with microsling. > > > > > > > Generally I think WebDAV is very Restful and a very > > > > good basis to start and sort of decorate microsling > > > > on top of a webdav enabled server. > > > > > > This sounds like an interesting point, though: Running Sling/microsling > > > ontop of a WebDAV server instead of a repository .... :-) > > > > > > > I think assuming assuming that people add an extension > > > > to let's say /content/mypage when GETting /content/mypage.html > > > > though microsling is good practice anyway. > > > > > > Definitely, it also helps determine the default response content type. > > > > > > Regards > > > Felix > > > > > > > > -- -----------------------------------------< [EMAIL PROTECTED] >--- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 -----------------------------------------------< http://www.day.com >---
