fix(checkout): return to identification when the session token is rejected - #1314
Merged
Merged
Conversation
…ected `EcCheckout.login()` set `customerEmail` (and so `isUserIdentified`) as soon as the passport cookie had an `auth.id`, before `fetchCustomer` confirmed the session. `checkLogin()` does not validate the token, so an expired token led to 401 on `/customers/:id`, `ecomPassport.logout()`, and a checkout stuck on the AccountForm with e-mail only, as if the customer were new: returning customers re-registered and orders created duplicated customers. Now the buyer is identified only once the account is loaded, via the `customer.main_email` watcher, and `Checkout.login()` resets the account state when the fetch fails with the session dropped, so the LoginBlock stays and picks the `login` event when the token is renewed. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Member
Author
Resultado do teste no previewPreview: https://ecom2barradoce--pr134-fix-checkout-recover-tv82ga7c.web.app (storefront-app com #1314 + vbeta-app com ecomplus/cloud-commerce#842)
Script: Playwright headless, sem criar pedido. Fica em |
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
leomp12
approved these changes
Sep 21, 2026
leomp12
left a comment
leomp12
left a comment
Member
There was a problem hiding this comment.
Revisei o fluxo padrão do checkout, principalmente de cliente novo: e-mail não cadastrado cai no 403 do /identify.json, sem login emitido, então nunca passa por EcCheckout.login() nem pelo fetchCustomer — caminho idêntico ao master. Guest/LP, segunda compra na mesma sessão e o fetchLogin do Confirmation também não são afetados. Com o cookie vencido o comprador agora fica no LoginBlock e segue normal.
Empurrei 0655325 enxugando os dois comentários novos pro porquê (sem mudança de código).
leomp12
added a commit
to ecomplus/cloud-commerce
that referenced
this pull request
Sep 22, 2026
… rejected Update `@ecomplus/storefront-app` to 2.0.0-beta.229, which resets the account step when `GET /customers/:id` fails with a stale token (ecomplus/storefront#1314), the app-side complement of the stale passport cookie cleanup. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HYm5krXU4pnuPzynSUMQUg
leomp12
added a commit
to ecomplus/cloud-commerce
that referenced
this pull request
Sep 22, 2026
) * fix(storefront): Stop sending an expired login to the checkout app Returning customers whose stored token had expired were dropped on the "complete your registration" form as if they were new, and orders created duplicated customers. The legacy app.js trusts any `auth.id` on the `ecomPassportClient` cookie (no expiry check), requests `/customers/:id` with the dead token, gets 401 and logs out without leaving the form. vbeta-app now drops that cookie when the Cloud Commerce session is not authenticated and the cookie was written by it (level 3), keeping legacy e-mail + document identifications untouched. app.js then starts unidentified and receives the `login` event when the token is renewed, either before it loads (#785 wait) or later through `setSession`. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(storefront): Checkout returns to identification when the login is rejected Update `@ecomplus/storefront-app` to 2.0.0-beta.229, which resets the account step when `GET /customers/:id` fails with a stale token (ecomplus/storefront#1314), the app-side complement of the stale passport cookie cleanup. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HYm5krXU4pnuPzynSUMQUg * chore(storefront): Trim comment on stale passport cookie cleanup Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HYm5krXU4pnuPzynSUMQUg --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> Co-authored-by: Leonardo Matos <leomp120894@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problema
Cliente já cadastrado abre
/app/#/checkoutcom o cookieecomPassportClientguardando um token vencido.checkLogin()só checaauth.id, oLoginBlockemiteloginna montagem, eEcCheckout.login()já marcava o comprador como identificado (customerEmail→isUserIdentified) antes dofetchCustomer. OGET /customers/:iddá 401, oaccount.jsfazlogout(), e nada volta o estado: o checkout fica noAccountFormsó com o e-mail, como se fosse cliente novo. Relato recorrente da Barradoce/Tia Sônia desde 05/2026, com clientes duplicados nos pedidos.Os fixes anteriores (#1290 e #1298) atacaram a corrida do token, mas nenhum tratava o resultado do 401.
Mudança
EcCheckout.login()só emitelogin; a identificação passa a acontecer pelo watcher decustomer.main_emailquando o cadastro é carregado.Checkout.login()chamaresetAccountquando o fetch falha e o passport já deslogou, então oLoginBlockcontinua na tela e captura o eventologinquando o token é renovado pelo storefront.Teste
Reproduzido em produção com Playwright (token vencido + cookie antigo + sem usuário Firebase → 2x 401 e AccountForm). Com esta build servida num preview da Barradoce, o mesmo cenário termina na tela de e-mail. Complementa
ecomplus/cloud-commerce(vbeta-app deixa de entregar cookie vencido ao app.js).🤖 Generated with Claude Code