Theory

The session-token contract

So far Pica has been anonymous: anyone can see the menu (GET /menu). But an order belongs to a specific person. We need accounts — and a way to prove to the server "this is the same user."

The solution is the session-token contract. It's simple, and worth memorizing, because lessons 8b (Google) and 9 (orders) repeat the same shape:

1. Client sends email + password    →  POST /login (or /register)
2. Server verifies, returns a TOKEN →  { "token": "eyJhbGciOi..." }
3. Client STORES the token
4. (lesson 9) client SENDS the token with every protected request

That token is a JWT (JSON Web Token): a signed string encoding who the user is and when the token expires (exp). The server signs it with its own secret, so the client can't forge one.

Two principles that matter already:

  • The password is never stored on the phone. You send it once; you get back only a token. Lose the phone and there's no password on it.
  • The token must be stored SECURELY. It is your session. Plain SharedPreferences is cleartext — readable (root, backups). So we use an encrypted store.

In this lesson we implement steps 1–3 (obtain and securely store the token). Step 4 — sending the token on requests — is lesson 9. In 8b, Google sign-in yields the same token — the contract doesn't change, only the way you obtain it.