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.
> I understand what you are saying but I don't understand why you want to
> alias users but you don't want to use :pserver:. Why can't you just let
> everybody use their domain account?
- I currently use pserver :-), because this is the only way to do it...
... but it is not very secure.
I currently have to use pserver for native Unix-projects, because they have
to use their native CVS-clients (maybe changes in future, when I'm able
to compile CVSNT under Linux and Solaris).
- I want descriptive "real" names (e.g. Matthias_Mohr) for the CVS, so that
the source-files tags (e.g. in $Log$) contains real user instead of the
(unfortunately) shortened NT-Accounts (e.g. MMohr).
- Not all of the Unix-users have NT-Domain-Accounts, so I need to alias
them to NT-Domains.
- We use several NT-Domains and it is sometimes necessary, to give a foreign
user CVS-access.
- For native Windows-projects I also wanrt the possibility to define descriptive
names for CVS-users.
And I think for a clean design, that possibility of defining aliases (e.g. for
mapping several CVS-users to one NT-user) has to be in every supported
protocol.
It should not matter if a user chooses (or have to choose) :pserver: protocol
or :sspi:-protocol or whatever...
Currently I have to tell the user that they always have to user the :pserver:
protocol and loose the security...
- For mixed projects (Windows and Unix), I need to have the same CVS-
username, it should not matter if he uses a Win-Client or an Unix-Client.
Currently I have to possibilities:
* always use the NT-usernames (which are unfortunately for some users
very "cryptic" and may not be changed by me). Then the user is able
to use every protocol.
* only use the pserver-protocol and define my "aliases" in two steps, first
with "cvs password" command and then directly at the CVS-server
by editing the passwd-file by hand and removing the password-field.
So I still think, the functionality of defining user-aliases is very usefull.
And for a "good" software-design, it should be implemented in such a way,
that it does not matter which protocol currently is used.
When a CVS user logs in, it should in my oppinion work (shortened) like that:
First a protocol-part extracts the user-information from the protocol and
transfers the extracted user-information to a common check-part. This
part tries to identify, if the given user is a real user or a mapped alias.
If it is an alias it gives back the real user to the protocol part. If no
alias is present, it gives back the given user.
Then the protocol-stack tries to authenticate the real-user with the given
protocol (or additionally with a password set in the passwd-file).
Would this be a feasable way to do it ?
with regads,
Matthias
_______________________________________________
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