fix(cli): honour the self-signed setting when signing in with a password

[ChiragAgg5k]

What does this PR do?

Self-hosted email/password sign-in failed against an instance with a self-signed certificate. login checked the endpoint with the current session's selfSigned preference, so appwrite client --self-signed true followed by appwrite login --endpoint https://self-hosted/v1 passed the /health/version check, but loginWithPassword built its client without SetSelfSigned, so POST /account/sessions/email then failed with x509: certificate signed by unknown authority. The session it created was also written without selfSigned, so every later command would have hit the same TLS error even if sign-in had worked.

Changes in templates/cli/internal/cmd/login.go:

• The sign-in client now uses the resolved self-signed setting. The MFA challenge and the /account lookup reuse that client, so they get it too.
• The new session stores selfSigned: true when the setting is on, so consoleClient and token refresh pick it up afterwards.
• login takes --self-signed true|false, in the same string form as client --self-signed. A self-signed instance can now be signed in to in one command. When the flag is set it overrides the stored preference. It is rejected with --switch and against Cloud, the same way --password, --mfa and --code are.

Test Plan

New tests in templates/cli/internal/cmd/login_test.go run against httptest.NewTLSServer:

• TestLoginSignsInWithTheStoredSelfSignedPreference failed on main with Post "https://127.0.0.1:.../account/sessions/email": tls: failed to verify certificate: x509: certificate signed by unknown authority after the endpoint check had passed. It passes with this change.
• With the session write removed, TestLoginSignsInWithTheStoredSelfSignedPreference and TestLoginSelfSignedFlagWorksWithoutAPriorClientCall both fail, which shows that the persistence assertion catches a missing write.
• Further tests cover the flag without a prior client call, --self-signed false overriding a stored true, MFA over a self-signed certificate, invalid values, and rejection with Cloud and with --switch.

Steps run locally:

• php example.php cli, then in examples/cli: go mod tidy, gofmt -l . (clean), go build ./..., go vet ./... and go test -race ./... all pass. The only failure was the known watcher flake, TestWatcherIgnoresUnchangedSavesWhileTreeIsBusy, which passed on re-run.
• composer lint-twig, composer refactor:check and max-line-length.sh pass.

Related PRs and Issues

None. The issue was found by reading the code and is reproduced by the regression test above.

Closes #2082

[hansi-codes]

🟢 Tier S · Ready to merge

The empty-value override is now detected and rejected, and I found no remaining issues in the new changes.

This pull request adds login --self-signed and applies the resolved certificate preference to password sign-in, MFA, and the persisted session. Regression tests cover self-signed sign-in, overrides, MFA, and invalid flag combinations.

Latest changes: The latest commit distinguishes an omitted --self-signed flag from an explicitly empty value, rejects the latter, and adds a regression test for it.

Verdict	New comments	Fixed	Still open
✅ Approved	0	1	0

📂 Walkthrough · 2

File	Change
templates/cli/internal/cmd/login.go	Adds explicit flag-presence tracking so empty self-signed overrides are rejected.
templates/cli/internal/cmd/login_test.go	Updates tests for the optional flag value and verifies an explicitly empty value is rejected.

✅ Fixed since the last review · 1

• Reject an explicitly empty self-signed value · templates/cli/internal/cmd/login.go:104

---

_{Reviewed the commits since aacce1b · Details · Comment @hansi-codes review to re-run, or mention @hansi-codes with a question.}

[hansi-codes]

🔵 Tier A · See the inline comments. Summary

[hansi-codes]

🟢 Tier S · Looks good to merge. Summary