Jenkins is failing with
koha_1 | STRACE: /usr/share/perl5/Try/Tiny.pm:123 in Selenium::Remote::Driver::catch {...}
koha_1 | /usr/share/perl5/Selenium/Remote/Driver.pm:361 in Try::Tiny::try
koha_1 | (eval 582):1 in Selenium::Remote::Driver::__ANON__
koha_1 | (eval 584):2 in Selenium::Remote::Driver::__ANON__
koha_1 | (eval 556):17 in Selenium::Remote::Driver::_execute_command
koha_1 | /usr/share/perl5/Selenium/Remote/WebElement.pm:125 in Selenium::Remote::WebElement::_execute_command
koha_1 | t/db_dependent/selenium/authentication_2fa.t:276 in Selenium::Remote::WebElement::send_keys
koha_1 | /usr/share/perl/5.32/Test/Builder.pm:334 in main::__ANON__
koha_1 | /usr/share/perl/5.32/Test/Builder.pm:334 in (eval)
koha_1 | /usr/share/perl/5.32/Test/More.pm:809 in Test::Builder::subtest
koha_1 | t/db_dependent/selenium/authentication_2fa.t:294 in Test::More::subtest
koha_1 |
selenium_1 | 1702911648831 Marionette INFO Stopped listening on port 41385
selenium_1 | JavaScript error: resource:///modules/Interactions.jsm, line 230: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIUserIdleService.removeIdleObserver]
selenium_1 | 15:00:49.452 INFO [ActiveSessions$1.onStop] - Removing session c3461b22-7a80-4b56-b177-653a53cc2651 (org.openqa.selenium.firefox.GeckoDriverService)
koha_1 | # Looks like you planned 7 tests but ran 3.
koha_1 |
koha_1 | # Failed test 'Enforce 2FA setup on first login'
koha_1 | # at t/db_dependent/selenium/authentication_2fa.t line 294.
koha_1 | Error while executing command: element not interactable: Element <input id="pin_code" name="pin_code" type="text"> is not reachable by keyboard at /usr/share/perl5/Selenium/Remote/Driver.pm line 411.
The error is: "Element <input id="pin_code" name="pin_code" type="text"> is not reachable by keyboard"
A guess is that the input is either 1. outside of the viewport, or 2. not
displayed yet.
1. We are hidding #registration-form then show it when we retrieved the
info (after POST /api/v1/auth/two-factor/registration)
2. Couldn't there be a race condition?
In auth.tt
284 success: function (data) {
292 $("#registration-form").show();
And in the selenium test:
$s->wait_for_ajax; # There is an ajax request to populate the qr_code and the secret
Not sure this wait_for_ajax is waiting for the end of success, I don't
think so.
This patch is supposed to fix both theories.
Test plan:
0. Do not apply the patch
1. Edit auth.tt and sleep 1 second before showing the form:
290 const sleep = ms => new Promise(r => setTimeout(r, ms));
291 await sleep(1000);
292 $("#registration-form").show();
You will also need to replace the following line (284):
success: function (data) {
with
success: async function (data) {
2. prove t/db_dependent/selenium/authentication_2fa.t
=> "is not reachable by keyboard" error!
3. Apply the patch, keep the sleep
4. prove t/db_dependent/selenium/authentication_2fa.t
=> Tests are passing
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Edit (tcohen): Tidied a bit to clear complaints
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
(cherry picked from commit 3270d32191)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This was for debugging purpose.
Test plan:
Run the tests and confirm that the screenshot is not generated when the
patch is applied
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If we are waiting for ajax (there is a sleep 1s) and the alert pops up
at the same time, Selenium is raising "unexpected alert open"
We should not wait for the ajax request, but better wait for the
alert actually.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
There is a missing wait_for_ajax call at after we click but wait_for_ajax
is waiting for the return of success, and the alert is there.
22:01:57 koha_1 | STRACE: /usr/share/perl5/Try/Tiny.pm:123 in Selenium::Remote::Driver::catch {...}
22:01:57 koha_1 | /usr/share/perl5/Selenium/Remote/Driver.pm:361 in Try::Tiny::try
22:01:57 koha_1 | (eval 541):1 in Selenium::Remote::Driver::__ANON__
22:01:57 koha_1 | (eval 543):2 in Selenium::Remote::Driver::__ANON__
22:01:57 koha_1 | /usr/share/perl5/Selenium/Remote/Driver.pm:654 in Selenium::Remote::Driver::_execute_command
22:01:57 koha_1 | t/db_dependent/selenium/authentication_2fa.t:282 in Selenium::Remote::Driver::get_alert_text
22:01:57 koha_1 | /usr/share/perl/5.32/Test/Builder.pm:334 in main::__ANON__
22:01:57 koha_1 | /usr/share/perl/5.32/Test/Builder.pm:334 in (eval)
22:01:57 koha_1 | /usr/share/perl/5.32/Test/More.pm:809 in Test::Builder::subtest
22:01:57 koha_1 | t/db_dependent/selenium/authentication_2fa.t:291 in Test::More::subtest
22:01:57 koha_1 |
22:01:57 koha_1 | # Looks like you planned 7 tests but ran 4.
22:01:57 koha_1 |
22:01:57 koha_1 | # Failed test 'Enforce 2FA setup on first login'
22:01:57 koha_1 | # at t/db_dependent/selenium/authentication_2fa.t line 291.
22:01:57 koha_1 | Error while executing command: no such alert at /usr/share/perl5/Selenium/Remote/Driver.pm line 411.
22:01:57 koha_1 | at /usr/share/perl5/Selenium/Remote/Driver.pm line 356.
22:01:57 koha_1 | # Looks like your test exited with 255 just after 4.
22:01:57 koha_1 | [20:59:37] t/db_dependent/selenium/authentication_2fa.t
Test plan:
Confirm that the test pass (execute it in a loop, hundreds of times)
Confirm that the behaviour of 2FA "enforced" (see bug 30588) is still
working as expected.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We need to replace 0 with 'disabled', and 1 with 'enabled'
Sponsored-by: Rijksmuseum, Netherlands
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This is a deadlock I think. Any ideas how we could continue to test that
in any conditions?
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Sponsored-by: Rijksmuseum, Netherlands
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Bug 28786 let librarians enable a Two-factor authentication but force them to use
an application to generate the TOTP token.
This new enhancement add the ability to send an email containing the token to the
patron once it's authenticaed
The new notice template has the code '2FA_OTP_TOKEN'
Test plan:
- Setup the two-factor authentication (you need the config entry and the
syspref ON)
- Enable it for your logged in patron
- Logout
- Login and notice the new link "Send the code by email"
- Click on it and confirm that you received an email with the code
- Use the code to be fully logged in
QA question: Is 400 the correct error code to tell the email has not
been sent?
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Sponsored-by: Rijksmuseum, Netherlands
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Change of text from "pin" to "PIN" in the 2FA setup interface.
This slight changes clarifies that "PIN" is an acronym,
and increases user comprehension
To test:
1) Log in as an Administrator
2) Enable TwoFactorAuthentication
3) Log in to a user with superlibrarian permissions.
4) On the user profile page, click the "More" dropdown button,
click "Manage Two-Factor
5) Check that "pin" is displayed in lowercase, in both instances.
6) Apply patch.
7) Refresh the page and observe that "pin" has changed to "PIN"
8) Sign off.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
Run t/db_dependent/selenium/authentication_2fa.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patchset introduces the Two-factor authentication (2FA) idea in
Koha.
It is far for complete, and only implement one way of doing it, but at
least it's a first step.
The idea here is to offer the librarian user the ability to
enable/disable 2FA when logging in to Koha.
It will use time-based, one-time passwords (TOTP) as the second factor,
an application to handle that will be required.
https://en.wikipedia.org/wiki/Time-based_One-Time_Password
More developements are possible on top of this:
* Send a notice (sms or email) with the code
* Force 2FA for librarians
* Implementation for OPAC
* WebAuthn, FIDO2, etc. - https://fidoalliance.org/category/intro-fido/
Test plan:
0.
a. % apt install -y libauth-googleauth-perl && updatedatabase && restart_all
b. To test this you will need an app to generate the TOTP token, you can
use FreeOTP that is open source and easy to use.
1. Turn on TwoFactorAuthentication
2. Go to your account, click 'More' > 'Manage Two-Factor authentication'
3. Click Enable, scan the QR code with the app, insert the pin code and
register
4. Your account now requires 2FA to login!
5. Notice that you can browse until you logout
6. Logout
7. Enter the credential and the pincode provided by the app
8. Logout
9. Enter the credential, no pincode
10. Confirm that you are stuck on the second auth form (ie. you cannot
access other Koha pages)
11. Click logout => First login form
12. Enter the credential and the pincode provided by the app
Sponsored-by: Orex Digital
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Jonathan Druart
Michal Urban