On 10/12/2015 05:38 PM, Robin Sheat wrote:
Bob Ewart schreef op ma 12-10-2015 om 16:05 [-0400]:
The Windows 7 workstation at the library is connected to the server on a local area network. My test system is running directly on the server. No proxies are involved. We've tried both Firefox and Chromium with no difference. OK, so it's probably not something being dumb about cookies then :)
This said, it might pay to trace the network requests in the browse to ensure that there isn't a request that is zapping the cookie.
As you can see from the logs, there are a couple of xsub entries in the new database run that are not in my run before the volunteer sees the main page. xsub comes from some date conversion code. The sooner we move to better logging and get file prefixes on things, the better :)
The "01:26 AUTH_SESSION: ()\t - " bit looks particularly suspicious, especially as there are some "Use of uninitialised value" warns right before it that aren't in your other log. I'd probably start looking around there.
The permissions are different in the two cases. I'm not sure why, but my database was originally created way back around 3.00 and errors may have crept in in the updates. What happens if you make the permissions match? Probably making the one that doesn't work match the one that does...
Auth.pm line 770 is trying to display the cardnumber, firstname, surname and branch which it got from $session->param(...). That occurs when checkauth is called. I did make the permissions, userflags and user_permissions tables match. No change. The apache access_logs showed my system had an extra entry to fetch the patron image. I turned the patronimages preference back to /"Don't allow" images to be uploaded and shown for patrons on the staff client/. Then everything worked as it should! When it was turned on, the volunteer should have been able to see my image. It did not display. -- Bob Ewart