- From: Yves Lafon <ylafon@w3.org>
- Date: Mon, 23 Mar 1998 16:27:15 +0100 (MET)
- To: Paul Pazandak <pazandak@OBJS.com>
- cc: Jigsaw Email List <www-jigsaw@w3.org>
On Thu, 19 Mar 1998, Paul Pazandak wrote: > > Yves, > > Thanks, that worked great! Now, I have a related problem. Here is a scenario: > > I have two resources: > - foo.html with username/password of foo/foo -- one MUST enter the > proper username/password to see the file > > - bar.html > - if the username/password is bar/bar then the user gets all of > the file > - if the username/password is foo/foo then the user gets some of it > - otherwise, all of the confidential content is stripped out before > sending it to the user > > The problem is that if the user first views foo.html, the credential > has the value foo/foo & it hangs around on subsequent requests from a client. > Now, when he wants to view bar.html he may want to view all of the content > & therefore would need to be able to re-enter a username/password (specifically, > bar/bar). Is there anyway a client can cause this to occur? Otherwise, he'll > only get some of the content since the credential is still foo/foo. The main problem is that the browser caches the credential, and there are no way to tell the browser to invalidate its cache. One solution should be to have a realm per protection level. Main drawback, the user will have to enter again the foo/foo for the new resource. But he will have a chance to use the bar/bar instead. You could wrap everything into a servlet and do some link at the top of the page to have the full version (ex: normal access foo.html, with link to foo.html?full, displaying the credential for the complete URL stored in another realm). Hope this help... > While it would be nice to allow the user to roam the site only having > entered a username/password once, the only way I can think of to enable the > above situation would be to delete the credential whenever content filtering > is turned on for a resource, then do a WWW-Authenticate to get a new user/pswd. > > Any other ideas? > > Regards, > > Paul. > > > Yves Lafon wrote: > > > On Wed, 18 Mar 1998, Paul Pazandak wrote: > > > > > Is it possible to generate a username & password dialog (on the client) within a filter as > > > part of an auxiliary authorization mechanism (the same dialog that appears when logging > > > into the Admin pages on the server)? I would like to be able to do this independent of > > > any Jigsaw authorization mechanisms -- e.g. ask a client for a username/password before > > > letting them see a document. > > > > The best way should be to use the Proxy Authentication. It then allow > > users to browse pages with "normal" authentication > > >From the server... > > If the Proxy-Authorization field is not present and do not contain the > > right values, it should return a HTTP.PROXY_AUTH_REQUIRED (407). > > And a Proxy-Authenticate header, (same as WWW-Authenticate field in an > > "unauthorized" answer, see GenericAuthFilter). > > > > > Second, IF the user already provided a username/password (for site access let's say, using > > > Jigsaw auth mechanisms), is there a way for the filter to access this information? > > > > Yes, the Proxy-Authorization field will be there (requested by the > > filter). We use a trick to check the user taken from an AuthFilter in > > w3c.jigsaw.filters.PutListResource (org.w3c.filters.PutListFrame). > > Regards, > > > > /\ - Yves Lafon - World Wide Web Consortium - > > /\ / \ Architecture Domain - Jigsaw > > / \ \/\ > > / \ / \ http://www.w3.org/People/Lafon - ylafon@w3.org > > -- > > ******************************************************************** > Paul Pazandak pazandak@objs.com > Object Services and Consulting, Inc. http://www.objs.com > Minneapolis, Minnesota 55420-5409 612-881-6498 > ******************************************************************** > > > /\ - Yves Lafon - World Wide Web Consortium - /\ / \ Architecture Domain - Jigsaw / \ \/\ / \ / \ http://www.w3.org/People/Lafon - ylafon@w3.org
Received on Monday, 23 March 1998 10:27:25 UTC