Re: [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:  mi...@equinoxinitiative.org
 | web:  http://equinoxinitiative.org


On Wed, Feb 8, 2017 at 1:40 PM, Bill Ott  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:  mi...@equinoxinitiative.org
>>   | web:  http://equinoxinitiative.org
>>
>>
>> On Wed, Feb 8, 2017 at 12:30 PM, Bill Ott  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.
>
>

Re: [OPEN-ILS-DEV] Duplicate authtokens

[Bill Ott]

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:  mi...@equinoxinitiative.org
  | web:  http://equinoxinitiative.org


On Wed, Feb 8, 2017 at 12:30 PM, Bill Ott  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.

Re: [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:  mi...@equinoxinitiative.org
 | web:  http://equinoxinitiative.org


On Wed, Feb 8, 2017 at 12:30 PM, Bill Ott  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.

[OPEN-ILS-DEV] Duplicate authtokens

[Bill Ott]

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.

[OPEN-ILS-DEV] Upcoming 2.12 release

[Kathy Lussier]

Hi all,

Thanks to everyone who applied the 2.12beta targets to their bugs and 
who talked with me over the past few days on the status of their code. 
We have many LP bugs now with the 2.12 target applied - 
http://bit.ly/2kSdVdG.


At this time, I'm putting out a general call to core committers and 
other testers to help with testing the branches. For now, we should 
focus on branches that are new features so that we can merge them in 
time for the beta freeze on Friday, February 10.


I have a lot of time carved out to test these branches, but the more 
people who are involved in testing, the greater the likelihood that all 
of these patches can be reviewed.


In particular, I could use help with reviewing the following patches:

https://bugs.launchpad.net/evergreen/+bug/1624366 - This is a new 
feature that would add integration for the Czech Added Content provider, 
obalkyknih.cz.


https://bugs.launchpad.net/evergreen/+bug/1649180 - Adds a new 
'translator' make target option


https://bugs.launchpad.net/evergreen/+bug/1553287 - Incorporating part 
information into biblio fingerprint - I need a signoff on this one so 
that I can merge it along with another, already-signed-off branch that 
also updates biblio fingerprint.


I have been reviewing the below two branches, but would welcome 
additional review from another developer on them:


https://bugs.launchpad.net/evergreen/+bug/1629108 - Metarecord 
constituents search result page should use standard search code. Note: 
this one already has a signoff from me


https://bugs.launchpad.net/evergreen/+bug/1573734 - Link to sibling 
metarecord bibs in record details - This one is almost ready to go, but 
Blake is seeking additional feedback on one piece of the project.


We already have people looking at the below two branches, but the 
changes are significant and probably should get broad review:


https://bugs.launchpad.net/evergreen/+bug/1596595 - Hold targeter 
features and refactoring


https://bugs.launchpad.net/evergreen/+bug/1646166 - Hatch 2.12 Omnibus - 
this one is a high priority for production use of the web client.


I also want to make note of a couple of requirements for the release:

I plan to merge https://bugs.launchpad.net/evergreen/+bug/1005040 
sometime this week. Because it requires OpenSRF 2.5, we will need to 
update our minimum OpenSRF requirement for the 2.12 release.


We also have a couple of branches targeted for 2.12 that will require a 
reingest.


Thanks in advance for all of your help!

Kathy


--
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
kluss...@masslnc.org
Twitter: http://www.twitter.com/kmlussier