>> I'm inclined to move the MD5 generation into the Freeciv core
>> code, where the MD5 verification already is.
> I propose to do it in freeciv (or lua). Thus, there is no
> dependency on the database backend to have this function. I
> will check this.

I've moved all MD5'ing into the core code as part of bug #18170.

Some random questions:

Unless I've missed something, the area of authentication and databases in Freeciv is short on documentation. It would be nice if there were some sort of README.auth or README.fcdb explaining how a server operator would set up authentication -- I'm finding that I have to reverse engineer it from the code. (This was true already, but the instructions will presumably be different after this work.)

Is the database.lua checked in to trunk intended to work with backends other than MySQL? I ask because it references luasql._MYSQLVERSION. Is a server operator who wants to use (say) SQLite expected to rewrite database.lua?

Talking of dependencies on MySQL, we've discovered in bug #18170 that database.lua:user_save() depends on the SQL function "md5()" (as did the C code that pre-dated it). Is this supported by backends other than MySQL (SQLite, Postgres)? It smells like a proprietary extension; I can't find mention of it in the SQLite docs.
I'm inclined to move the MD5 generation into the Freeciv core code, where the MD5 verification already is. Alternatively, verification could be moved out of the core code into Lua, I suppose.

the following patches belong to this metaticket:

[01/04] patch #2114: [fcdb] add luasql files
[02/04] patch #2115: [fcdb] redo lua script
[03/04] patch #2116: [fcdb] freeciv database lua script (fcdb)
[04/04] patch #2117: [fcdb] use fcdb for authentication

WIP patch to implement the database connection via luasql:

• split auth.c into auth.c (autentication) and fcdb.c (freeciv database)
• add luasql files (only mysql working; postgres prepared)
• add database.lua file with the needed functions
• changed options for the server:

-D (--Database <file>)
-a (--auth)

• new command: fcdb (at the moment only reload)
• cleanup definition of database config
• split common lua script functions into a new file (luascript.c)
• rename script.c/api.pkg to script_game.c/tolua_game.pkg
• add script_fcdb.c/tolua_fcdb.pkg as entry point for luasql
• add api for logging (api_log.c)
• check arguments to script functions against the defined values

The patch will be splitted into smaller part before submission. At the moment I would like some comments (that should be changed; are the lua function correct, that directory layout should be used for ./server/scripting/, ...).

Using this patch as well as the newcommer patches freeciv 2.4.x should be ready to be used by the longturn community ...

> Question is, does book's code work? Is it complete or missing
> something?

I can affirm to you it works well. All warservers run it for more than 2 years with it for the authentication and for the ranking system.

> Such code has been already done in warclient by Book. See trunk/server/database.[ch].

I through more about doing this in lua. As said in comment #0 this could/should support mysql as well as postgres or any other database which lua supports.

@Ulrik Sverdrup: would it be possible to support user authentication (database) via a lua script? It would need mysql (mainline freeciv) and postgres (longturn) connectors

I propose that the current auth code and all
future database interfacing code be written
in lua scripts.

This would have the following advantages:
- No need to recompile to change the way the
database is used (e.g. table field names,
sql statment format, etc.).
- Support for databases other than mysql.
- Easily extended beyond just auth.

For example longturn currently uses postgresql
instead of mysql, and warclient servers use
password salt.

The lua database bindings are provided by LuaSQL
(http://www.keplerproject.org/luasql/). It would
be added to the 'dependencies' directory, with
specific driver libraries only being compiled
and linked to the main server executable if the
corresponding database is detected by configure.

As a first step the lua integration would
proceed by combining much of the functionality
of the functions

authenticate_user
process_authentication_status
handle_authentication_reply

into a single script entry point (i.e. a function
that is expected to exist in the database script).
A stand-alone lua state is created for this script
in auth_init().

The lua function will need to return a status
value indicating how the connection should be
handled (e.g. 'accept', 'wait', 'reject').

The script would need to be able to manipulate
'user' objects, which correspond to 'struct
connection'. Methods should be provided which
allow access to at least 'id', 'name' and
'password' information. An alternative would
be to pass the required information to the
script function each time it is invoked.

Possibly all "auth" string occurences in the code
and in filenames should be changed to "database",
in preparation for future generalization.

I'll clarify and revise the details as I test out
a tentative implementation (though this will not
be very high priority for a while).

----------------------------------------------------------------
誰かが月を一口食いちぎたようだ。