Comment 4 for bug 1468422

Pushed some more stuff. Tests are now pgtap tests. (Script will fail of pgtap extension is not installed). Added a lot more comments. Added support for storing more crypt info (iter_count) in the password type (so it can be raised in the future) and support for storing un-encrypted (or externally crypted) passwords, i.e. passwords we don't crypt() directly.

--

Looking at the API, I've run into a snag with backwards compatibility. If we're to use the main password salt as the seed value returned by open-ils.auth.authenticate.init, we need to know which user is attempting to login during init. However, the API only requires the caller to specify if it's using a username or barcode in the secondary authenticate.complete call. The init call has no knowledge of which patron is trying to login.

To avoid modifying the client API's to specify username or barcode in authenticate.init, we need to add logic to authenticate.init to determine for ourselves if the value provided is a username or barcode, so we can lookup the patron and find their salt. This may be a blessing in disguise, since we should probably be doing this on the server-side anyway. Sound sane? Am I missing anything?