Question: Auth

(related: #1418. Separate issue b/c this is just me asking if my approach makes sense, and this got a bit too long-form for our internal chat)

So I’m starting to write docs for LH on authenticated pages. I know little about auth stuff. I see some stuff on JWT. And cookies. and then there’s Basic auth. and feeling a bit lost, so let my run this by y’all.

• So for basic auth, you just need to set an Authorization: Basic ... header (--extra-headers=./path/to/secret/headers.json).
• For token/JWT stuff, same thing but Authorization: Bearer ...
• For cookie based auth, --extra-headers "{\"Cookie\":\"test=true\"}" is needed. There are some issues with this, see https://github.com/GoogleChrome/lighthouse/pull/9170 . The current proper way to set cookies (without overwriting what already exists) is via pupeteer / CDP - #9170 would make this much simpler.

I want to make a local server that does a few different methods of auth to test stuff out. Here’s a simple basic auth server in python: https://gist.github.com/dragermrb/108158f5a284b5fba806 . I’ll probably make a cookie / token based one too.

1. Does this sound right - am I missing anything?
2. An alternative to setting headers / cookies via LH CLI flags is to use a custom Chrome profile, and set it up however you want, then instruct LH to use that. I don’t know if that actually covers anything more than the header flags would - does it?

[paulirish]

It’s true that user account/login state can be defined in lots of different ways. localStorage, cookies, indexedDB, etc.

Stepping back, I don’t see users actually asking for this. In fact, looking at #1418, it’s us who are suggesting setting cookies/headers as a means to do this.

Meanwhile, when an example of using puppeteer to login was posted, it quickly got the most 👍 reactions in the thread.

Similarly, the WPT scripting language is mostly used to fill in login forms.

My suspicion is that folks who currently have integration tests on their login-based webapp are logging into them with forms rather than prefilling *storage state or setting request headers. I also think this is far more user-friendly.

IMO the ask here is to document using pptr to login and handing off to lighthouse. This comment laid the groundwork, but it could afford to be generalized.

We should also mention the two backup solutions of… A) extra-headers and B) chrome profile reuse.

[paulirish]

fixed by #9628

https://github.com/GoogleChrome/lighthouse/blob/master/docs/authenticated-pages.md https://github.com/GoogleChrome/lighthouse/blob/master/docs/recipes/auth/README.md