Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.
Trying to work out how much of our suite time is logging in. We have thirty-odd UI scenarios tagged @user:standard, plus somebody recording a flow most mornings. Do those all log in independently, or is there a single cached thing they share?
Accepted answer
To put numbers on it: one login per pool user per environment, not one per scenario.
projects/demo-shop/.auth/staging/standard-0.json
projects/demo-shop/.auth/staging/standard-1.jsonA scenario tagged @user:standard leases a user, the fixture checks whether that user's file is fresh, logs in once in a throwaway context if it is not, and starts the browser context from the state. Thirty scenarios sharing one leased user share one login. The index in the filename is the position within the role.
Prime it yourself if you would rather pay up front and see the cost:
sdods auth capture -p demo-shop -e staging -u standard --all
sdods auth list -p demo-shop -e stagingOne thing to be aware of rather than to work around: there are two code paths producing these files today — sdods auth capture, which works from dataset rows, and the library captureAuth() that sdods record --user calls. They write the same files to the same place, so nothing is broken, but they are two implementations of one idea. Consolidation is scheduled and it has not happened, so if you go reading the source do not expect one path. It is written down under known limitations.
Shared. One file per pool user per environment, and both the runner and the recorder read the same file — that is why sdods record --user standard opens signed in without you doing anything.
Adding the boring operational half: .auth/ is gitignored and should stay that way. Those files are live sessions — anyone who gets one is signed in as that user until it expires.
If you want a teammate to be able to record without hunting for credentials, the answer is to give them the pool dataset and let capture do its thing, not to hand them a state file. Passwords in the dataset reference environment variables, never literals.
Auth strategies and storage state has the table of which strategy produces state how.
Wrap commands and output in triple backticks and they will render as a code block.
Checking whether you’re signed in…
Have a different question? Ask it.