- 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