OK, I think I can say that I've figured out what I think the onauth API should be, so I'd like to get some comments on it. I haven't done any implementation yet (other than copying John's onchange function and doing the search & replace). Assuming I get positive feedback, I'll move forward with the implementation.
The onauth script will be given 4 parameters. the first three of which will come from the parameters to the call_onauth function. $1 is the username. [1] $2 is the domain name or NULL if it's a system user. [1] $3 is the numeric value associated with the service type. [2] $4 is the current timestamp as generated by time(NULL). [3] [1] The username and domain name are passed separately because they are already broken apart in order for vchkpw/vpopmaild to authenticate the user, and would have to be concatenated together before calling onauth, and then split back apart by the onauth script. That increases the workload on both ends, so why bother. [2] Except when being used to determine whether a particular service is authorized in vchkpw, this information is never used. I think it might be good to pass a long for logging purposes, but see no reason not to stick to numeric codes, and let the called script deal with the information as it sees fit. I'll add defines so that vpomaild and other have numeric code designations as well, and they remain static unless someone decides to renumber them. [3] While strictly not necessary (the script can calculate it on its own), if you are using a script that just hands off the parameters to a daemon which queue's up the updates, it's possible that any given onauth script won't be processed until after the timestamp has changed. Since we can't guarantee that the onauth script will be run atomically, it's better to send the timestamp as a parameter and let the script decide if it cares. Other API notes: The call to call_onauth should probably return the exit status of the onauth script, which can be gotten after the wait(&pid) call returns. And instead of returning 0 for a failed call, return -1. I'm not sure if we care about that, but it's information that might be useful later on. Other code notes: There's a couple of minor issues I see in the onchange code, which I'll fix in my onauth code and you can port back to the onchange code. Mostly the handling of a failed exec call - you should call _exit rather than return, since it's in the vfork and you don't want the vfork'd process doing anything more... Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
