Bug 6694 - Anonymous sessions not kept when casAuthentication is on
Summary: Anonymous sessions not kept when casAuthentication is on
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: 3.6
Hardware: All All
: P3 normal (vote)
Assignee: Julian Maurice
QA Contact: Marcel de Rooy
URL:
Keywords:
Depends on: 5630
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-10 09:40 UTC by Julian Maurice
Modified: 2012-10-25 23:09 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Fixes for checkauth and check_api_auth (2.06 KB, patch)
2011-08-10 09:46 UTC, Julian Maurice
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 6694: Problem with casAuthentication syspref (2.12 KB, patch)
2011-12-09 13:10 UTC, Alex Arnaud
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Julian Maurice 2011-08-10 09:40:27 UTC
In OPAC, if I am an anonymous user and the system preference casAuthentication is set, each time I reach a new page, the CGISESSID cookie gets a new value, causing the previous session to be destroyed and a new one to be created.
This bug comes from an error in checkauth (C4/Auth.pm), where a missing test cause this strange behavior.
Also found a similar issue in check_api_auth, which cause C4::Service->init to fail if the syspref is set.
For example, I was unable to change a syspref value when casAuthentication was set.
Patch will follow.
Comment 1 Julian Maurice 2011-08-10 09:46:43 UTC Comment hidden (obsolete)
Comment 2 Sophie MEYNIEUX 2011-11-04 11:42:02 UTC
I have tested with casAuthentication syspref activated:
In OPAC, no visible symptoms, but if I look at CGISESSID cookie, its value changes each time I display a new page.
The patch does not change this behavior.

In staff when I try to modify a syspref value I got an error.
The patch fixes this bug.
Comment 3 Alex Arnaud 2011-12-09 13:09:10 UTC
For me all works well.

I have tested with casAuthentication syspref activated too.
CGISESSID cookie no more changes values while going to another page.

And sysprefs are no more blocked. signing off
Comment 4 Alex Arnaud 2011-12-09 13:10:00 UTC
Created attachment 6694 [details] [review]
[SIGNED-OFF] Bug 6694: Problem with casAuthentication syspref

A missing test in checkauth caused anonymous session to be destroyed and
re-created at every call when this syspref was set.
Almost the same issue is also fixed in check_api_auth, which caused
C4::Service->init to fail.

Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Comment 5 Marcel de Rooy 2012-01-10 15:05:14 UTC
QA Question: I did not dive into the cas specs (yet..) but does anyone of you know some external users of cas willing to test/sign this (small) patch too?
Comment 6 Paul Poulain 2012-01-16 17:39:50 UTC
(In reply to comment #5)
> QA Question: I did not dive into the cas specs (yet..) but does anyone of you
> know some external users of cas willing to test/sign this (small) patch too?

Marcel, we have this in production at our libraries using CAS. You should QA only for code quality & that there is no change when CAS=OFF

It's a simple patch, i'm for passed QA, but as it's a BibLibre written & signed I won't do it & let you do.
Comment 7 Marcel de Rooy 2012-01-18 13:01:50 UTC
QA Comment:
Code looks good. But couldn't test it. So I mark it as Passed QA relying on the signoff. For the record, I also note that writer and signer are from the same company, but that should not be a problem for a patch of a few lines.
Comment 8 Tom Hanstra 2012-02-29 14:50:01 UTC
For the record and for future reference, I would be willing to test such CAS related patches if I can get an understanding of how to obtain the changed code and how to properly test so that it helps with the QA signoff.  We use CAS and I should have a development environment available for testing.
Comment 9 Paul Poulain 2012-03-01 10:34:32 UTC
(In reply to comment #8)
> For the record and for future reference, I would be willing to test such CAS
> related patches if I can get an understanding of how to obtain the changed code
> and how to properly test so that it helps with the QA signoff.  We use CAS and
> I should have a development environment available for testing.

Tom, is your setup of Koha using git or debian package/released tarball ?
If you're not using git, that will be hard (impossible ?) to test yourself.

If you're using git, you can head to: http://wiki.koha-community.org/wiki/Git_bz_configuration

once git bz is installed, just do

git bz apply 6694, the patch attached to this bug will be added, and you can test it.


note that you may find some interesting informations also on http://wiki.koha-community.org/wiki/Sign_off_on_patches
Comment 10 Tom Hanstra 2012-03-01 18:14:53 UTC
At this point, I've only been installing using the packages.  We are actually running RHEL5 rather than Debian, but I'm still using the packaged version.

I may try to set up a server using the git version as I get more familiar with and further into our support of Koha.  But that could be a while.  

So, if there are ways for me to test with a package and a code update or two, I'm willing.  But if that is going to be prohibitive, then it might be a while before I can be of assistance.

Tom
Comment 11 Julian Maurice 2012-03-08 08:23:59 UTC
patch is in master and 3.6.x branches, marking as resolved.