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.
auth.strategy: token with a working token. All the @api scenarios are green. Every @ui scenario starts at the login page.
I assumed the token would be placed into the browser context too — that is what "place it as a header, cookie or local-storage entry" reads like to me. Is there something else I have to set for the browser side?
Accepted answer
Nothing you can set. The token strategy writes no browser storage state — its login hook resolves to nothing, same shape as the sso stub. Your API scenarios are green for an unrelated reason: the API client picks up api.auth from the environment independently of the auth strategy, so it never needed the strategy to work.
There is an open issue. Until it lands, treat the two layers as separately configured:
sdods auth capture -p <slug> -e staging --user standardfor the UI session (form login, or --interactive if a provider is involved), and keep the token in api.auth for the API layer. Both can be true at once; they are just not wired to each other.
Same conclusion here. We ended up with strategy: form on the project, because that is the strategy that actually produces a browser session, and the bearer token declared only under api.auth. Reads slightly oddly in the yaml — the project claims form auth while half the suite uses a token — so leave a comment next to it, or the next person will "tidy" it back.
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.