a1d6bcb8e5
If you visit /login/ instead of /login the cookie will be set at /login instead of / which means the cookie can't be read at the root. It will redirect to the login page which *can* read the cookie at /login and redirect back resulting in an infinite loop. The previous solution relied on setting the cookie at / (any invalid value works) which then overrode the login page cookie since parseCookies only kept a single value. So the login page would see the same cookie the root was seeing and not redirect back. However, that behavior depends on the cookies being in the right order which I'm not sure is guaranteed. This new method tests all available cookies and always sets the cookie so the root path will be able to read it in case the login page is seeing a cookie the root can't. It also goes a step further and explicitly sets the path on the cookie which fixes the case where there is a permanent misconfiguration redirecting /login to /login/. Otherwise the cookie would continually be set on /login only and you'd have another loop. It also means you only need to delete one cookie to log out. Lastly add some properties to make the cookies a bit more secure. |
||
|---|---|---|
| .. | ||
| channel.ts | ||
| cli.ts | ||
| connection.ts | ||
| insights.ts | ||
| ipc.ts | ||
| marketplace.ts | ||
| nls.ts | ||
| protocol.ts | ||
| server.ts | ||
| update.ts | ||
| uriTransformer.js | ||
| util.ts | ||