[OPEN-ILS-DEV] Duplicate authtokens

[Mike Rylander]

Bill,

Can you find the log entries for the offending sessions (should all be
around 6am, obv) for calls to open-ils.auth.authenticate.init?  The
first parameter is the username and the second is the nonce
(http://stackoverflow.com/questions/5050932/nonce-usage-in-authentication)
used to disambiguate session requests coming in at the same time.  The
nonce is based on the return value of rand($$) in the client (a random
number between 0 and the client pid minus 1), and if they're the same
then the same auth token could be generated.  They should not be the
same, of course, but if they are ... we may need to upgrade our PRNG
to something stronger from CPAN, like
http://search.cpan.org/~frew/Math-Random-Secure-0.08/lib/Math/Random/Secure.pm

Thanks,

--
Mike Rylander
 | President
 | Equinox Open Library Initiative
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at equinoxinitiative.org
 | web:  http://equinoxinitiative.org


On Wed, Feb 8, 2017 at 12:30 PM, Bill Ott <bott at grpl.org> wrote:
> I'm not sure this if this is a bug, as I haven't totally wrapped my mind
> around it, but we've had some bizarre behavior that I wanted to put on the
> radar.
>
> Ever since we upgraded to 2.11 in Dec., we've had occasional situations
> where our automated book drops would start reporting the wrong OU on
> checkin.  The WS name would be correct, but not the OU.  A restart of the
> book drop service would correct it.  I hadn't reported it because I thought
> it may have something to do with our custom services.
>
> Today I found the smoking gun in the logs.  Drops restart every morning at
> 06:00.  They are using the same user, but different WS values.  The logs
> showed 4 drops all with the same authtoken. When retrieving the ws_ou by
> authtoken, you'd get the OU based on the first WS value.
>
> I'm not sure if this is something with the new auth code, and we can't
> reproduce it manually, but it seems that there's something about requesting
> multiple logins using the same user at the same moment that causes
> authtokens to be reused, even though the WS is different.
>
> We've now created new distinct users for each drop and I suspect that will
> prevent us from seeing this, but it seemed worth mentioning.