You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These are some thoughts from today's Fractal call on topics for a CLI authentication refactor:
The pain-points:
It's tricky when switching between users with the caching (2 on-disk files: .fractal.env file & the token file in the cache => create a new .fractal.env file, but the existing token is still used)
We still require a .fractal.env file for the server IP, right? Thus, there isn't a way to do things without that env file for the time being
Storing passwords on disk in .fractal.env files is not a good way forward. Great for testing obviously, but we should move away from it
Not super intuitive for onboarding people that don't run their own setup scripts: When does the .fractal.env file get created? Why can't I use the command-line client from a different folder?
Goals:
No passwords on disk
Still easy to use and easy for testing
Some ideas:
The fractal-demos scripts could ask interactively for username, password & IP/port (maybe with a default that we run the "production" server on) and use those on all fractal client commands afterwards.
What's a good way to not have to type -u username -p password for every fractal client command? Some token or hashed storage, but when the user provides -u username -p password those get overwritten? In that case, only the first command in a demo script would need a -u -p, the rest would still use a (more securely) cached login.
The text was updated successfully, but these errors were encountered:
These are some thoughts from today's Fractal call on topics for a CLI authentication refactor:
The pain-points:
Goals:
Some ideas:
The text was updated successfully, but these errors were encountered: