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