[Koha-bugs] [Bug 7174] Authentication rewriting

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Wed Jul 22 13:25:29 CEST 2015


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

--- Comment #14 from Olli-Antti Kivilahti <olli-antti.kivilahti at jns.fi> ---
Created attachment 41124
  -->
http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=41124&action=edit
Bug 7174 - Authentication Rewrite

Depends heavily on Buugg 14540, which introduces many tests to spot regression
caused by this feature.

Introduces a new modular authentication system based on Exception signaling
and reusable authentication components/challenges.
This system is cross-framework -compatible, currently supporting Mojolicious
and CGI, but adding support for any other framework is straightforward.

Central idea is to provide a single authentication function to deal with all
types of authentication scenarios, REST API, Cookie, Password, LDAP...
Also it is important to make a system that is easy to extend and can deal with
many future authentication scenarios.

Currently only CGI password, LDAP and cookie login is tested. Legacy behaviour
is used to deal with other types of authentication.

Deprecates a lot of subroutines in C4::Auth.

See the attached schematic in Bugzilla for a more architectural overview.

The basic principle is:
1. We get an authentication request from any Web/GUI-framework, for ex CGI.
2. Request is normalized by extracting all necessary authentication data
   elements to a separate data structure.
3. Based on the found authentication data elements, system decides which
   authentication route to take.
4. Route implements all challenges needed to authenticate the request.
   Route returns the authenticated Koha::Borrower or an Exception if login
   failed.
5. The user environment/session is set/deleted based on the Route result.
6. a Koha::Borrower and the CGISESSID-cookie is returned to the calling
   framework in the format the framework needs.
7. Framework needs to catch possible exceptions and deal with them.
   Eg. login failed, no permission, under maintenance.
8. Authentication succeeds and session is set, or failure is reported to user.

-----------------------------------
-::- TEST PLAN:                -::-
-----------------------------------

Use PageObject tests from Buugg 14540 and Buugg 14536 to test against
regression.

::MANUAL TESTS::
OPAC:
1. Go to opac-main.pl
1.1. Try to access a restricted page like /cgi-bin/koha/opac-account.pl
2. Login with password.
3. Navigate to any OPAC page requiring login.
4. Observe that the login is still valid and correct username is displayed on
   top right of the browser window.
5. Logout
5.1. Try to access a restricted page.
6. Login again.
7. Browse a bit.
8. Logout.

Anonymous search history (OPAC):
1. Make a search
2. Make another search
3. Login
4. Make yet another search
5. Go to my search history.
6. Observe that the last three searches are shown in your search history.
7. Logout

STAFF CLIENT (Intra):
0. Try to access a restricted page, like /cgi-bin/koha/mainpage.pl
1. Login
2. Navigate a bit to confirm that the login remains active.
3. Logout.
4. Login again.
5. Navigate to a restricted page.
6. Logout.
6.1. Try to access a restricted page.

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


More information about the Koha-bugs mailing list