Phillip Susi wrote:
> Yes, as I said before, the password is to decrypt the client
> certificate, not to send to the server. Why would you use both a
> client certificate and send a password to the server?
>
> I always figured that it just did not store the password because it
> was 'a different level' as you said, but having looked at my auth
> cache during this discussion, it seems that the password IS being
> saved, but not read and used the next time.
>
> FG wrote:
>> Did you build your SSL certificate with a challenge password?? If
>> so, this is at a different level than the SVN authentication. So it
>> would most likely NOT get cached.
>>
>> Food 4 thought.
>>
>> Regards,
>> Frank
>>
>
The reason I am asking is because you potentially have two separate
levels of authentication here. The first level is when you hit your web
server for the SSL connection. If you built your SSL certificate with a
challenge password, it will require that you enter that password just to
get use of the SSL connection. This is neither part of the Subversion
client caching of any password mechanism nor part of the authz_svn
authentication layer. It's still one level to high.
Humor me....If you try to hit any other non-protected part of your
website on https://, does it still ask for a password? If so, then you
do have a challenge password on your SSL certificate, and that
configuration is not part of the Subversion authenication caching
mechanism. The password being asked for is to begin any sort of SSL
transaction. In a "standard" scenario, the client is able to actually
create the connection and then the subsystems (authz_svn / basic auth)
will ask for their own authentication.
HTH
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Dec 17 05:23:48 2005