logout does not clear .olauth; password stored in plaintext by default

[Waynting]

Four things around stored credentials, found while reading config.ts and
cli.ts. The first is a behaviour bug; the rest are hardening and docs.

1. olcli logout leaves .olauth in place

logout calls clearConfig(), which clears the conf store and nothing
else. getSessionCookie() resolves in this order:

1. OVERLEAF_SESSION
2. .olauth in the current directory
3. the global config

So a user who authenticated with --save-local runs logout, sees
Credentials cleared in green, and is still authenticated in that directory
— via the source that takes precedence over the one that was actually
cleared. The message is what makes this worse than the leftover file: it
states an outcome that did not happen.

Fix could be as small as deleting .olauth in cwd when present, or
reporting what was and was not cleared.

2. The account password is persisted in plaintext by default

setPasswordCredentials() writes loginEmail and loginPassword to the
same plaintext JSON as everything else. --no-save-password exists, but the
default is to save.

A session cookie in plaintext is normal — gh stores tokens the same way.
A password is a different asset: it is reusable outside olcli, it survives
cookie rotation, and it cannot be revoked without changing it. Given that
password login exists mainly for self-hosted instances without reCAPTCHA,
persisting it by default buys convenience in exactly the deployments most
likely to be shared or multi-user.

Worth considering: default to not saving, and let the cookie obtained from
the login carry the session — persistClientSession() already stores it.

3. --password lands in shell history

olcli auth --email … --password … is the only documented password path, and
it puts the password in ~/.zsh_history verbatim. A prompt-based entry (no
value on the command line) would cost little and is what most CLIs do.

4. The documented config path is wrong on macOS

README says:

3. Global config: `~/.config/olcli-nodejs/config.json`

conf resolves to ~/Library/Preferences/olcli-nodejs/config.json on macOS.
Since getConfigPath() already exists and auth prints it, the README could
point at that instead of hardcoding a path that is right on one platform.

While there: nothing currently tells a user that --save-local writes
.olauth into whatever directory they happen to be in — usually their LaTeX
project. This repo gitignores .olauth; the user's own repo will not.

---

None of this is remotely exploitable — it is all local storage and local
output. Happy to send a PR for any subset. #1 seems worth doing regardless
of what you think of the rest.

[aloth]

Confirmed all four, and thanks for reading the source rather than just the behaviour.

1. logout leaving .olauth behind. Reproduced. clearConfig() is config.clear() and nothing else, and getSessionCookie() reads .olauth at position 2, ahead of the global config it just cleared. You put the finger on why it is worse than a stray file: the message states an outcome that did not happen.

2. Plaintext password by default. Confirmed - setPasswordCredentials() writes loginEmail and loginPassword into the same JSON, and --no-save-password is opt-out. Your distinction between a cookie and a password is the right one.

One thing that may save you work: persistClientSession() already exists and is already called on the password-login path, in cli.ts right before setPasswordCredentials(). So the session-carrying half of your proposal is in place; what changes is whether the password is written afterwards.

3. --password in shell history. Agreed. Worth deciding whether the flag stays for scripted use alongside a prompt, or goes.

4. Config path. Fixed in 0.11.0 - the docs no longer hardcode a path and point at olcli check instead. Your .olauth note is in the README too. That one was a documentation line with no design decision in it, so I took it rather than leaving it in your pile.

1, 2 and 3 are yours if you want them. They are one coherent piece of work around credential handling and splitting them would put two people in the same code at the same time, which is why I did not pick off #1 while you were waiting.

No rush on any of it - none of this is exploitable, as you say.