Complete.Org: Mailing Lists: Archives: freeciv-dev: July 2003:
[Freeciv-Dev] Re: client/server authentication (PR#1767)
Home

[Freeciv-Dev] Re: client/server authentication (PR#1767)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [Freeciv-Dev] Re: client/server authentication (PR#1767)
From: "Mike Kaufman" <kaufman@xxxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 5 Jul 2003 13:55:27 -0700
Reply-to: rt@xxxxxxxxxxxxxx

On Sat, Jun 14, 2003 at 08:43:42AM -0700, Raimar Falke wrote:
> 
> This means only one password for all servers. There should be multiple
> password keys by "user@host".

no, this is much too complicated for this patch.

> > +enum authentication_type {
> > +  AUTH_NORMAL,     /* request a password for a returning user */
> > +  AUTH_NEW,        /* request a password for a new user */
> > +  AUTH_BAD,     /* inform the client that the new password was bad */
> > +  AUTH_WRONG,   /* inform the client that the entered password was wrong */
> > +};
> 
> Can be abstract this?
> 
> AUTH_LOGIN_FIRST,
> AUTH_LOGIN_RETRY,
> AUTH_NEWUSER_FIRST,
> AUTH_NEWUSER_RETRY

yes, done.

> We should remove the tries and just use a delay of 2-5s. Maybe even
> random *evil grin*

no. although I took Chris' advice, now a good password has no delay.
 
> > +#ifdef GUESTS_DISALLOWED
> 
> This is now GUESTS_ALLOWED

yep. done.

> > +static const char *get_guest_name(void)
> > +{
> > +  return GUEST_NAME;
> > +}
> 
> Doesn't provide much by itself since high-level code shouldn't use
> this function anyway.

yep, gone. 

> > +      pconn->server.authentication_stop = 2147483640; /* big enough */
> 
> You can use 0 as a flag value.

yeah, ok, though it requires an extra conditional.
> 
> Here and also in other comments: please write sentences.

Whatever.

> > +struct user {
> > +  char name[MAX_LEN_NAME];
> > +  char password[MAX_LEN_NAME];
> > +
> > +  /* add more fields here as warranted */
> > +};
> 
> What is the current state for the idea that struct user is moved to
> common and struct connection gets a pointer to the user? I like the
> idea. It is the correct thing if you do OO-modeling.

I don't think so. see my previous reasons.

-mike

Attachment: auth6r.diff.bz2
Description: auth6r.diff.bz2


[Prev in Thread] Current Thread [Next in Thread]