- From: Yves Lafon <ylafon@w3.org>
- Date: Thu, 2 Sep 1999 11:47:21 +0200 (MET DST)
- To: Zahid Ahmed <zahid.ahmed@commerceone.com>
- cc: www-jigsaw@w3.org
On Wed, 1 Sep 1999, Zahid Ahmed wrote:
> Would it be OK, to add a 3rd field as a authentication parameter in the
> client-side HTTPCredential and send as part of the basic cookie? It seems to
> be received by the Jigsaw Web Server fine
> > (in addition to userId/password)? Obviously, this would mean that
> > we will need to write our own custom auth handler on server side.
> > E.g.,
> > HTTPBasic decoded cookie: userId:password:3rdAuthField
> >
> > Will the 3rd field added to HttpCredential as part of basic cookie
> > impact any standard WWW proxy authentication? E.g., should the
> > 3rd field order be at the end s.t. proxies continue to process
> > the first two field according as userId/password?
You can also add other fields, like what we did in the DigestAuthFilter
with such headers:
WWW-Authenticate: Digest
realm="test",nonce="4e4d1061bcabbf8243e88635f1ed82ea",domain="/HTTP/Digest",algorithm="MD5"
The only problem is that you lose the "basic" scheme, but as you add
another parameter, you may called it extended-basic. THere is a hack if
the scheme is "basic" as the cookie is not send in a name=value pair, so
you may want to modify org.w3c.www.http.HttpCredential if you choose to
not to say cookie="mycookie".
And of course you will always need to write the client and the server part
to handle this new scheme...
Hope this helps,
/\ - Yves Lafon - World Wide Web Consortium -
/\ / \ Architecture Domain - Jigsaw Activity Leader
/ \ \/\
/ \ / \ http://www.w3.org/People/Lafon - ylafon@w3.org
Received on Thursday, 2 September 1999 05:47:26 UTC