Complete.Org: Mailing Lists: Archives: freeciv-dev: April 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: kaufman@xxxxxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: client/server authentication (PR#1767)
From: "Raimar Falke" <rf13@xxxxxxxxxxxxxxxxx>
Date: Fri, 11 Apr 2003 00:30:57 -0700
Reply-to: rt@xxxxxxxxxxxxxx

On Thu, Apr 10, 2003 at 10:00:27PM -0700, Mike Kaufman wrote:
> attached are a second set of three patches leading to server/client
> authentication. With the previous commit of the preparation patches, these
> should be quite readable.
> 
> auth3-4d.diff: variable name changes to make nomenclature consistent.
> 
> o pconn->name becomes pconn->username. 
> o pinfo->name becomes pinfo->username. 
> o In the client player_name and default_player_name become user_name and 
>   default_user_name.
> o find_[player|conn]_by_* function names also suitably changed.

Looks ok altrhough you could have done more indent cleanup if you
touch these lines.

> auth4-5k.diff: implement _simple_ server-side authentication. 

enum authentication_type doesn't have a docu.

> o add database.[ch] to handle a user database. currently can only create
>   a new entry, search for an entry by username and do a search by usernamd
>   and return the password. Note: the db_entry struct is rudimentary and
>   most of the fields present are unused and for demonstration purposes.
>   Our current ranking system is expected to be plugged in here somehow.

The name "database" is too general.

> o note: the database is binary. we could do this using freeciv registry,
>   but I'm afraid this would be really slow and not really suited for 
>   sequential search. comments welcome. tools will need to be written to 
>   manipluate the database for administrative purposes.

The current code is bad since it isn't endian nor 64bit safe.

The freeciv registry is the way to go. If you have 100 logins/s the
speed may matter and you would have to cache the DB in memory. But
this isn't the case.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Last year, out in California, at a PC users group, there was a demo of
  smart speech recognition software. Before the demonstrator could begin
  his demo, a voice called out from the audience: "Format c, return. Yes,
  return." Damned short demo, it was.




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