Sascha Wilde <wilde@intevation.de> writes:
Timo Sirainen <tss@iki.fi> writes:
On Wed, 2008-10-22 at 16:15 +0200, Sascha Wilde wrote:
There are more than 250LOC in deliver/auth-client.c and I wonder if there is already a higher level api for auth clients? I would have expected something like this in lib-auth, but the stuff in there seems not to be what I'm looking for. Any hints?
plugins/expire-tool/auth-client.c has copy&pasted that code also.. So it would be nice if it was put to lib-auth :)
Ok, I'll consider doing so... :)
Having a first look it turns out to be less straight forward then I hoped it would be. While there are significant amounts of code similar in deliver/auth-client.c and expire/auth-client.c they differ in many aspects:
1.) It seems that some code in deliver/auth-client.c has been revised after it was copied to expire/auth-client.c, this is a small problem as I would expect simply using the newer code to be the right thing[tm].
2.) The exported interface in the respective auth-client.h files is different. The solution would be to figure out what the right interface would be and change the current code to use it. My problem I'm not sure what the right interface would look like, for my use the one in expire/auth-client.h looks more compelling, what do you think?
3.) The deliver version does more than I need, and most certainly more than it should in the generic case: the most obvious example is that it sets up RESTRICT_* environment and calls restrict_access_by_env(TRUE); which surely is nothing I want to do in my code...
My current plan is to take only the code from deliver/auth-client and check which parts I need, factor these out to new file in lib-auth (unfortunately lib-auth/auth-client already exists) and finally ask the author of the expire plugin to change his code so that it uses the new stuff in lib-auth (I doubt that I will have the time to do this on my own).
Obviously a god answer on 2. is badly needed... ;-)
One final question: All the code saves the gathered user data by setting the environment accordingly (especially HOME, which is the one of interest for my code) -- but in my case I'm requesting the data for foreign user so setting HOME wouldn't be good idea.
I see two possible solutions:
- Simple and stupid: save HOME, call the client-auth code, read HOME and reset its value to the saved one.
- Clean but grows the API: export another function from auth-client, which does not set env-vars but returns the requested data in some struct.
Any thoughts on that?
cheers sascha
Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner