[OPEN-ILS-DEV] Duplicate authtokens

[Mike Rylander]

Ah! I assumed that your bookdrops were using SIP2.  There you go,
nonce to the rescue!

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 1:40 PM, Bill Ott <bott at grpl.org> wrote:
> Unfortunately, at the time I caught this in the logs, we were only logging
> warn, so I don't see the init call.  The method we were using to call init
> was not using nonce.
>
> I've located a nice example in SIP.pm and will make a code change to use it
> in our init call going forward!
>
>
>
>
> On 02/08/2017 01:15 PM, Mike Rylander wrote:
>>
>> 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.
>
>