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.
Created attachment 4921 [details] [review]
Fixes for checkauth and check_api_auth
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.
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
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 <firstname.lastname@example.org>
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?
(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.
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.
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.
(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
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.
patch is in master and 3.6.x branches, marking as resolved.