Tests:
- Login
- Login using passkeys works on testing container and stable container.
- Login page show 'Log in with passkey' button as expected along with key
icon.
- On GNOME's Web browser, the login page does not show an error on load.
Clicking on 'Log in with passkey' shows the error: 'Logging in with passkey
failed: Browser does not support passkeys.'
- On Chromium browser, with invalid TLS certficiate, the login page does not
show an error on load. Clicking on 'Log in with passkey' shows the error:
'Logging in with passkey failed: NotAllowedError: WebAuthn is not supported
on sites with TLS certificate errors.'
- Raising an error in the passkey_login_begin() method shows the error message
when login page is loaded. Raising an error in the passkey_login_complete
method shows the error message after passkey is unlocked. In both cases, 500
is HTTP status code.
- With primary hardware key register passkey each for 'tester' and 'tester2'
accounts.
- With secondary hardware key register passkey for 'tester' account.
- In login page, loading the page shows the console message 'Signing in with a
passkey. Condition: true'.
- In login page, when username field is clicked, 'passkey' is shown in the
autofill popup options. Selecting it prompts for hardware PIN and touch.
User is logged in.
- In login page, when 'Log in with passkey' is clicked, console message is
show 'Log in initiated with button, conditional mediation aborted.'.
Hardware PIN and touch is prompted. User is logged in.
- During autofill login, canceling the hardware key PIN shows no error alert.
Autofill passkey login is not available.
- During autofill login, canceling the hardware touch prompt shows no error
alert. Autofill passkey login is not available.
- During button login, canceling the hardware key PIN shows '...user denied
permission' error alert. Autofill passkey login is not available.
- During button login, canceling the hardware touch prompt shows no '...user
denied permission' error alert. Autofill passkey login is not available.
- When multiple attempts fail, multiple error alerts are shown.
- During login, with primary key account selection dialog is shown. Selecting
'tester' logs into 'tester' account. Selecting 'tester2' logs into 'tester2'
account.
- During login, with secondary key, account selection dialog is not shown.
User is logged into the 'tester' account.
- Password based login continues to work as usual on Firefox, Chromium, and
GNOME's web.
- Logout, then visit /freedombox/sys/. This redirects to login page. After
login with passkey the browser is redirected to /freedombox/sys page.
- After passkey login, 'Last Used' for that key is updated. The value is not
updated for remaining keys of the account.
- After successful login, database is updated with the latest signature
counter.
- After successful login, for a user account with Spanish set as language, the
UI language changes to Spanish.
- If a key has been removed from list of passkeys and that passkey is
attempted for login, 'Passkey used is not known' error alert is shown.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Tests:
- Setup: add domain name mystable.example. Add an entry in /etc/hosts on the
test machine. In Firefox, in about:config, set
'security.webauthn.allow_with_certificate_override' to 'true'.
- Registration
- Passkey successful registration:
- After passkey registration, created time is time at which key is created.
- After passkey registration, domain is the domain with which the interface
is accessed at the time of addition of passkey.
- After passkey registration, Added and Last Used columns show the current
time in UTC. Signature counter and extensions and aaguid values in the DB
are as expected.
- First key's name is 'Key 1'. After that it is 'Key 2' and so on. If a key
is renamed as 'Key 4', then next key will be named 'Key 5'.
- Registering passkeys using testing container stable container works.
- Links:
- 'Manage passkeys' link is show in the user menu in navbar in both desktop
mode and mobile mode. Clicking on it redirects the browser to current
user's passkey management page.
- User's edit page shows 'Use passkeys for better security'. Clicking on the
link redirects the browser to passkey management page for the user who's
account is being edited.
- Listing:
- All passkeys are show properly. Name, domain, added, last used, and
operations show correctly.
- When using a browser without Javascript script shows an error alert.
- If not passkeys are present "No passkeys added to user account." message
is shown.
- Editing the passkey shows correct page. Title, heading, form labels, form
value, and buttons are as expected. After editing, passkey is updated
properly.
- Deleting the passkey shows a model dialog with correct details. After
confirmation, passkey is removed and page is refreshed.
- Error handling:
- On GNOME's Web, clicking the 'Add Passkey' shows the error 'Browser does
not support passkeys'.
- On Chromium, clicking the 'Add passkey' shows the error 'NotAllowedError:
WebAuthn is not supported on sites with TLS certificate errors.'
- Raising an error in passkey_add_begin() results in correct error message
shown with 'Add passkey' button is clicked. Status code is 500.
- Raising an error in passkey_add_complete() results in correct error
message shown after unlocking the hardware token. Status code is 500.
- Canceling the PIN dialog results in '...user denied permission' error
alert.
- Canceling the touch dialog results in '...user denied permission' error
alert.
- Multiple failed attempts result in multiple alerts being shown at the same
time.
- Editing another user's passkeys:
- Listing passkeys show correct list of passkeys for the user account being
managed.
- Adding passkeys adds correctly to the user account being managed.
- Editing passkey correctly edits passkey of the user account being managed.
Redirect happens to the correct page after.
- Deleting passkey correctly edits passkey of the user account being
managed. Redirect happens to the correct page after.
- If a non-admin user tries to access passkeys list/edit/delete URL of
another user, 403 Forbidden error is raised
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Tests:
- 'make install' removes enabled sso module
- Already logged in users stay logged in after update
- Apps need to re-authenticate of update (but this is transparent)
- Login and logout work as expected
- Failed login attempts lead to CAPTCHA form
- CAPTCHA form can't be skipped
- Answering CAPTCHA form will lead back to login page
- Users functional tests work
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
On user deletion, user's home folder is also deleted. Admins have an
option to avoid deleting user's home by inactivating the user instead.
This commit also removes user deletion buttons from the user's list
page and adds this option to the user edit page. The user's edit form
asks for a confirmation if the user deletion is requested. This change
also means that the confirmation password is now required to delete a user.
Also:
- Add a simple username validation to the privileged actions.
- Functional tests: Create a fixture to login as an admin before every test.
- Functional tests: Add a test to check that SSH passwordless login works
after user is renamed to validate correct SSH related path permissions.
- Privileged tests: Add `test_` prefix to the generated random string which
makes easier to check and cleanup created home folders.
- Minor quote fixes.
Tests performed in stable and testing containers:
- Run all the users module tests twice, no failures in tests.
- When user is the last admin, both "Active" and "Delete user"
checkboxes are disabled.
Closes#2451.
[sunil]
- Refactor the JS code:
- Ensure that DOM elements are lookup after DOM content is loaded.
- Styling changes. Reduce the number of globals, name the global names
somewhat more unique.
- Click the button instead of submitting the form to disable the button.
- Template changes:
- Add a body for the confirmation dialog to talk about disabling the user and
deleting the home directory.
- Change the label of the confirm button to make it more
explicit (recommendation from many UX guides).
- Styling.
- Functional tests:
- Fix visibility checking of an element to use the correct splinter API.
- Simplify clicking the edit user link.
- Minor update to form checkbox help text.
Signed-off-by: Veiko Aasa <veiko17@disroot.org>
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
- Add explicit dependency on django-ipware >=3. django-axes >= 6 adds
only and optional dependency on django-ipware. Adding explicit dependency make
the behavior safer.
- Depend on django-axes >= 5 where the authentication backend and other features
are available. The new code won't work with older versions. The new approach
uses and authentication backend to deny access to the login form on lockout and
a middleware to redirect user to locked out form when limit of attempts have
been reached.
- Drop old code used for compatibility with django-axes 3.x.
- Suppress verbose and debug messages as django-axes is too chatty.
- Re-implment the CAPTCHA form entirely. In the old style, we have a login form
with CAPTCHA field. That would not work with the new django-axes authentication
middle. On submission of the form, auth.authenticate() will be called. This
call invokes various authentication backends include django-axes authentication
backend. This backend's behavior is to reject all authentication attempts when
the IP is listed in locked table. The new approach is to provide a simple
CAPTCHA form with just the CAPTCHA field. If the form is successfully
validated (correct CAPTCHA is provided), then the lock on the IP address is
reset. The user is then free to perform 3 more attempts to login.
- Update firstboot form to send the request parameter when using
auth.authenticate() method. This needed by Django axes' authentication method
which will be triggered.
Tests:
- Run tests on Debian Bookworm and Debian testing.
- Axes verbose messages and debug messages are not printed on the console when
running FreedomBox in debug mode.
- Only three invalid attempts are allowed at the login page. After the final
incorrect attempt, user is redirected to CAPTCHA page. Visiting the login page
using the URL works but entering the correct credentials still takes the user to
CAPTCHA page.
- CAPTCHA form appears as expected. Clicking the CAPTCHA images downloads the
audio file corresponding to the image. Incorrect CAPTCHA shows an error. Correct
CAPTCHA takes the user to login form where they are able to login with correct
credentials. Entering incorrect credentials 3 times will take the user again to
CAPTCHA page.
- Creating user account during firstboot works.
- Blocked IP address the IP of the client such as 10.42.0.1 and not the local IP
address 127.0.0.1 according the django-axes log messages. While one client IP
address is blocked, another IP is able to login to the same user account that
was attempted by the blocked client.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Closes: #2178.
- Don't bother with the redirection to the next page using the ?next= URL
parameter. Always redirect to the home (index) page.
- Show a message that logout was successful.
- Ensure that SSO cookie is removed.
Tests:
- Logout and notice that redirection has been performed to the home page.
- "Logged out successfully." message is shown.
- When logged as a user with a language set, logging out preserves the language
of the user who was just logged out.
- Login. Click logout while having browser developer tool open. Notice that
Logout request has SSO cookie. The response does not have the cookie set. The
next request is to the home page and it does not have SSO cookie in the request.
- Login to tt-rss app that needs SSO to work. Logout from FreedomBox interface
using another page. Refresh the tt-rss page and notice that user was logged out
and redirect to FreedomBox login page.
- Logout. Again, manually visit the URL
https://10.42.0.203/plinth/accounts/logout/. The page is still required to home
page and success is still shown even though the user is already logged out.
- Repeat the logout test as non-admin user.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Fixes: #2170.
Starting with Django 2.2.25, re_path behavior has changed. When the regular
expression ends with a '$', a full match is performed with the regular
expression. This breaks the behavior of how we are currently matching the locked
URLs for CAPTCHA based login forms.
Tests:
- All tests are done on Debian stable with Django 2.2.25 and on Debian unstable
with Django 3.2.10.
- Go to home page, click on login link. Enter wrong password three times.
CAPTCHA page is show with URL ending with /locked. Type the correct password and
login will be successful.
- Install tt-rss. Logout. Go to /tt-rss/, redirection will happen to login page.
Enter wrong password three times. CAPTCHA page is show with URL ending with
/locked. Type the correct password and login will be successful.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- In Django 2.2 django.conf.urls.url() is an alias to django.urls.re_path().
- In Django 4.0, url() function will be removed. On Django 3.2, it throws a
warning that this function will be removed in future.
Tests:
- Run unit tests with Django 3.2 and Django 2.2.
- With Django 3.2 there are no warnings when running unit tests and when running
FreedomBox Service.
- Visit a few affected apps with both Django versions.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- clearing ip address correctly is not implemented yet
- currently clearing all ip addresses
Signed-off-by: Joseph Nuthalpati <njoseph@thoughtworks.com>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
User will be shown captcha in the second attempt to login if login
fails in the first attempt.
Signed-off-by: Joseph Nuthalpati <njoseph@thoughtworks.com>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Install mod_auth_pubtkt and generate public/private key-pair.
- Redirect user to login page if no cookie is presented.
- Add check for authenticated user for login page.
- Temporarily switched to DSA because of a bug in mod_auth_pubtkt
which causes it to accept only DSA and not RSA. Also had to use SHA1
instead of SHA256.
- Enabled SSO for Syncthing, Repro and TT-RSS.
- Using tokens to authorize by user groups.
- Generate keys during first boot.
- Rename AdminMiddleware to AdminRequiredMiddleware to be consistent
with stronghold/Django terminology
- Simplify .gitignore pattern
- Format single line docstrings as per PEP8.
- Add missing docstrings.
- Restrict lines to 79 characters.
- allows editing users (currently the groups and username)
- allows any logged-in user to change the passwords of any other users
- improved url highlighting of subsubmenu
