Passwordless test login

[davidwaroquiers]

Added an additional login procedure for dev/tests. This is purposedly simplistic, just a username, and to login, you just click on the user in the list. The goal is to be able to test various access features / groups etc ... without the need to have multiple OAuth logins.

Adapted from the previous PR here: Matgenix#5
In this previous PR, a password credentials existed. Given the actual purpose of this, i.e. just be able to have different authenticated users easily in a purely test/dev environments, the password credentials added unnecessary code.

Logic in datalab for access to items/anything is:
1/ Authentication (who am I)
2/ Tenant access (do i have access to to this datalab instance)
3/ resource-level access control (can I access this specific "object")

This PR allow to kind of "bypass" 1/ and 2/ (not really bypass, just make it super easy for testing/development).

[davidwaroquiers]

@jbouquiaux could you test and review (probably more the backend part) this ? Likely we can add something in the dev-docker documentation with the command to add a user with the docker compose (something like "docker compose exec api-dev uv run invoke dev.create-test-user --username gloubs --role user")
@DianaAliabieva could you test and review (probably more the frontend part) this ?

[codecov]

Codecov Report

❌ Patch coverage is 89.13043% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.56%. Comparing base (684dc70) to head (ebd3d58).

Files with missing lines	Patch %	Lines
pydatalab/src/pydatalab/routes/v0_1/auth.py	87.50%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2062      +/-   ##
==========================================
+ Coverage   81.47%   81.56%   +0.08%     
==========================================
  Files          88       88              
  Lines        8465     8509      +44     
==========================================
+ Hits         6897     6940      +43     
- Misses       1568     1569       +1     

Files with missing lines	Coverage Δ
pydatalab/src/pydatalab/config.py	82.09% <100.00%> (+0.11%)	⬆️
pydatalab/src/pydatalab/feature_flags.py	77.01% <100.00%> (+1.10%)	⬆️
pydatalab/src/pydatalab/routes/v0_1/auth.py	79.78% <87.50%> (+0.69%)	⬆️

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ml-evs]

Hi @davidwaroquiers, thanks for this. We definitely need something that solves this problem but I think I've come down against the idea of adding password-based login in this way.

I think my suggestion would be instead to hook into the email login approach and enable that by default on dev servers. We can then make invoke dev.serve provide an authenticated link with a token for testing the developers "normal" user by default, and an extra invoke task very similar to the one you added here that creates a test-user and prints a token link for the developer.

What do you think? Happy to implement this if you are okay with it, or go back to this idea if you still prefer a password.

[davidwaroquiers]

Hi @davidwaroquiers, thanks for this. We definitely need something that solves this problem but I think I've come down against the idea of adding password-based login in this way.

I think my suggestion would be instead to hook into the email login approach and enable that by default on dev servers. We can then make invoke dev.serve provide an authenticated link with a token for testing the developers "normal" user by default, and an extra invoke task very similar to the one you added here that creates a test-user and prints a token link for the developer.

What do you think? Happy to implement this if you are okay with it, or go back to this idea if you still prefer a password.

Hi @ml-evs

Thank you for the message. Just to mention that it is even not with a password it's "easier". Here is with a few screenshots:

1/ Login page:

2/ List of clickable passwordless users with some info (their role, the group(s) they belong to):

And you just click on the user you want to be logged in. That eases tests with different users with different roles, belonging to different groups, in the future it could also help test group admins, project admins etc ...).

It is quite perpendicular to almost everything in datalab. It only touches four small points:

• The configuration flag exposed in the /info response (ENABLE_UNSAFE_TESTING_PASSWORDLESS_LOGIN -- could be renamed as it is very long but at least it's clear :D)
• The invoke dev.create-test-user task (only active when the above flag is True)
• Two endpoints on the existing AUTH blueprint group: "GET /login/testing-passwordless/users" to get the list of test users, and "POST /login/testing-passwordless" to start the normal Flask login session for the selected (clicked) user
• The user picker with the buttons shown above
  (note that one thing I did not like is that there was a new testing_passwordless IdentityType... I removed it in the last commit, using a workaround with the email IdentityType)

After a user is selected, everything follows the normal datalab "flow path" (using the Flask login session for access etc ...).

What do you think ?

[ml-evs]

Ah sorry, I think I just searched for "password" and thought I was responding to #1898 🙃 I guess my question then becomes whether adding this to the UI itself is that useful, and if it really needs an API route? I'd prefer a task that lists these login users in the terminal and offers login links for each. Do you find the extra UI component that much more useful than having e.g., a few private browser windows logged in as different accounts?

[davidwaroquiers]

Ah sorry, I think I just searched for "password" and thought I was responding to #1898 🙃 I guess my question then becomes whether adding this to the UI itself is that useful, and if it really needs an API route? I'd prefer a task that lists these login users in the terminal and offers login links for each. Do you find the extra UI component that much more useful than having e.g., a few private browser windows logged in as different accounts?

Not that much more useful indeed. I think the idea of having one invoke task that gives the list of passwordless users and their "properties" (roles, groups, ...) and the link is all good. I'll remove the UI part. As for the API route, we at least need the one to login no ?