That sounds like a good place to me. One thing that might be worth noting is that the sslfile class (if i remember correctly) sets the connection as static, which means that you can't access the session from outside sslfile. It was for this reason that I started adding accessors. Would it be better to have the connection/session not be static?
It's hard to say what's right without a few application to look at. It definitely should be possible to get access to some or all of the certificate chain from an sslfile. One simple way is to just add a method
sslfile->get_peer_cert_chain() { return session->peer_cert_chain; }
but perhaps one should also have some more friendlier functions to be used by clients that do https-style server authentications.
/ Niels Möller (vässar rödpennan)
Previous text:
2004-01-15 21:26: Subject: Re: SSL part two
I think the authorities and auth_level should be removed from handshake.pike. Having the same variables in handshake.pike and context.pike is confusing and invites bugs.
I thought the same, but didn't want to delete it on the chance someone else is counting on it being there. I will remove the duplicate copy.
I don't see where the certificates are used for verifiction. Is that done at all?
I don't believe that they're currently looked at for validity (it seems that it might be possible to send gibberish and have pikessl accept it.
I think the received certificate chain, as well issuer/subject and other information we dig out from it, should be saved in the session object.
That sounds like a good place to me. One thing that might be worth noting is that the sslfile class (if i remember correctly) sets the connection as static, which means that you can't access the session from outside sslfile. It was for this reason that I started adding accessors. Would it be better to have the connection/session not be static?
Bil
/ Brevbäraren