[Koha-bugs] [Bug 12954] New: Questionable logic regarding session handling in C4::Auth::checkauth()

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12954

            Bug ID: 12954
           Summary: Questionable logic regarding session handling in
                    C4::Auth::checkauth()
 Change sponsored?: ---
           Product: Koha
           Version: master
          Hardware: All
                OS: All
            Status: NEW
          Severity: major
          Priority: P5 - low
         Component: Architecture, internals, and plumbing
          Assignee: gmcharlt at gmail.com
          Reporter: abl at biblos.pk.edu.pl
        QA Contact: testopia at bugs.koha-community.org

In case of the unsuccessfull log-in attempt (non-existing user ID, bad
password, or both), session params are currently (since Bug 10952 got pushed)
being set like that in checkauth():

- lasttime & ip params are set,
- number, id, cardnumber, firstname etc. are not set,
- sessiontype is NOT set to 'anon'

So the user session is essentially left in semi-authorised, semi-anonymous
state. If then such an user goes directly to any page which does require
authorisation/authentification, checkout() would treat this user as
authentificated one, and would return prematurely without redirection to the
login screen. This also typically (?) leads to get_template_and_user() being
bypassed: it does return to the script from which it was called from (but with
empty $borrowernumber return value).
In case of the (e.g.) opac/opac-user.pl script, observable effect of this bug
is an DBI error:

opac-user.pl: DBD::mysql::st execute failed: You have an error in your SQL
syntax; check the manual that corresponds to your MySQL server version for the
right syntax to use near '' at line 1 at /home/koha/devkohaclone/C4/Letters.pm
line 200

(because C4::Letters::getalert() doesn't like to be called with empty
$borrowernumber).

To replicate:

1/ try to log in with some nonexisting user id or wrong password in OPAC
2/ go directly to the opac/opac-user.pl page (e.g., enter it in the browser
address bar, or just click on the "Log in" link); clicking on "Log in" button,
when "Login" field is empty would also probably trigger this error
3/ observe DBI error displayed on the screen
4/ you are now in the "deadloop" of sorts (opac/opac-user.pl refuses to display
the login screen, no matter how many times you try to reload it); to break the
deadloop, one needs to:
- remove session cookie from the browser (or cause the session to expire in
some other way - closing browser window would be probably enough for that)
- remove offending session on the server (from mysql sessions table, ..)
- log in with proper credentials using some other page (like opac/opac-main.pl
right-side panel), which does not involve opac/opac-user.pl being called
without "userid" CGI parameter.

Another way to replicate:

1/ try to log in with some nonexisting user id or wrong password in OPAC
2/ go to the staff interface
3/ observe that login screen displayed is different (not the "normal" one, but
one with some additional buttons for loging-out etc. + "You do not have
permision to access this page" message; see Bug 12951 attachment 31689 for
reference).

-- 
You are receiving this mail because:
You are watching all bug changes.