On Thu, 2008-10-23 at 16:18 +0200, Sascha Wilde wrote: > 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].
Yes, I haven't really looked at expire/auth-client.c much lately.
> 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?
Perhaps something like:
struct auth_user_reply {
uid_t uid;
gid_t gid;
const char *home, *chroot;
ARRAY_TYPE(const_string) extra_fields;
};
struct auth_connection *auth_connection_init(const char *auth_socket);
void auth_connection_deinit(struct auth_connection *conn);
/* Returns -1 = error, 0 = user not found, 1 = ok */
int auth_connection_lookup(struct auth_connection *conn, const char *user,
struct auth_user_reply *reply_r);
I'm not sure about the struct, but maybe something like that. deliver
would then use the struct to set up environment etc.
> 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...
Right. And in general putting all the stuff to environment directly
isn't that good. With v1.3's config rewrite I'm hoping to get rid of all
this environment usage.
> finally ask the author of the expire plugin to change his code
That'd basically be me.
> - 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.
Yep.
signature.asc
Description: This is a digitally signed message part
