On Tuesday 24 January 2006 12:04, Boris Mann wrote:
1. Client requests a service token, sends username/password of a Drupal user 2. Drupal loads the $user matching the crudentials - creates a random alphanumeric token to send back to the user - serializes, and caches the $user object, key = md5(token + ip address of client) - sends the token back to the client 3. Client makes an RPC call to say: module.createListing($token, $arg1,$arg2,...) 4. In createListing(...) -- Checks the token, if valid does it's thing, otherwise, returns an error message.
Two questions: 1. Expiration of the token -- has that been considered? Probably these should have a very limited lifetime. Reasons: a. The token may be stored in a temp file on the remote system; we might all agree that's a bad idea, but we can't stop them from doing so. If the remote is later compromised, then so are we. b. If we accumulate too many such tokens that are out there in the world and valid, a large Drupal site that has too many of them may become vulnerable to a brute-force attack. 2. This sounds a lot like a miniature Kerberos. Has anyone done anything to Kerberize Drupal itself? One comment: This is probably something that, if it ends up in core, should be disabled by default and turned on by the sysadmins who want/need it. Err on the side of paranoia when it comes to authentication. #2 may be a dumb question; it isn't something I've had time to research. If so, please feel free to thwack me with an RTFM. :-) None of the above are meant to criticize the concept; I think it might be useful in certain situations, and adding it wouldn't take away anything that exists now, especially if it's an add-on rather than core. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher