Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Tony Hoyle wrote:
> Brian Smith wrote:
>
> Personally I'd rather not have either and just have it automatically
> detect, but supporting multiple protocols on a single dll makes that
> difficult on the client side - the server loads every protocol up anyway
> so that'll work without any help.
Actually, I changed my mind. I would like to have a seperate DLL
(gserver_sspi_protocol.dll) for the gserver/sspi.
My first reason is that I would like the new protocol DLL to be
responsible for registering/deregistering the service-protocol-name
(SPN) in Active Directory (AD). I would like to do this by adding two
functions to protocol_interface:
void server_install(); -- called when service gets installed
void server_uninstall();-- called when service gets uninstalled
For most protocols, server_install() and server_uninstall() would do
nothing (be NULL). For gserver_sspi_protocol, I will use server_install
to add the SPN to AD, and I will use server_uninstall to remove the SPN
from AD. By encapsulating this functionality in a gserver_ssp_protocol I
can statically link the DLL to the to the AD library (ntdsapi.lib)
without affecting :sspi: mode or any other protocols.
The second reason I want the seperate DLL is because I don't want to
support the "cvs login" .cvspass functionality for gserver. This enables
me to just not install sspi_protocol.dll and pserver_protocol.dll on my
client machines and thus avoid the security issues cause by .cvspass.
gserver mode never supported login anyway and the CVSROOT syntax for
specifying username and password conflicts with the server at realm sintax
needed for gserver mode in any case:
:gserver:server[@REALM]:/path
:sspi:[username[:password]@]server:/path
If we want to support specifying a username & password for gserver, it
would have to look something like this:
:gserver:[username[:password][@user_server[@REALM]]@server[@REAM]:/p
in order to support cross-realm authentication across trusted domains.
The third reason for the seperate DLL is that there is no need to change
the signature of get_protocol_interface since the new "method" parameter
is now not necessary. And, it simplifies the first-generation support
for gserver_sspi_protocol.dll because the DLL-loading code can do
something like this:
if method is :gserver:
load gserver_sspi_protocol.dll if it exists
otherwise, load gserver_mit_protocol.dll if it exists.
until I can get something that is more user-friendly/configurable working.
I was easily able to factor out the common code between
gserver_sspi_protocol and sspi_protocol.dll into a single source file
(sspi_common.c). This ended up being much cleaner than my original
method where :sspi: and :gserver: code was inter-mingled. So, I already
have the seperate DLL version working correctly for both :gserver: and
:sspi: modes.
sspi_protocol.dll is 28,748 bytes
gserver_sspi_protocol.dll is 28,672 bytes
so there isn't a lot of bloat.
A final reason is that it doesn't require any change to the
get_protocol_interface signature (no new "method" parameter).
> I just want to get the wire protocol right, the rest can wait. rc2
> needs releasing soon as there are fixes (like the cvs passwd stuff) that
> are needed so people can use the program properly. I expect rc2 will
> probably just become the release version - it's pretty stable now.
When testing :sspi: it didn't work right because the sspi v2 client was
sending the netogiate line which my sspi code didn't expect. But,
regardless, I did the merge and it seems to be working (I tried both
combinations of client/server).
> Generally I just do a couple of release bugfixes until everyone is
> happy, then start another development cycle. I could create a branch
> if there was a really good reason for it... I'd like to avoid releasing
> off two branches though.
That sounds good. A stabilization period is really all I need.
- Brian
_______________________________________________
Cvsnt mailing list
Cvsnt at cvsnt.org
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs