Flusso FE ottimizzato

Obiettivo

Il flusso classico (flusso.html + /mockup) resta invariato. Il FE ottimizzato usa azioni dedicate: QNLogin, QNVerifyOtp, QNRegister, QNUpdateProfile. Rispondono con next_step (stessi numeri del flusso classico) oppure access_token.

debug[] solo se config.php → debug: true
Cookie __utp impostato dal backend quando viene emesso il token

Diagramma flusso login mockupfe

Pagine /mockupfe · API QN* · numeri = next_step

flowchart TD Start(["index.html
email o telefono"]) --> QNL["QNLogin"] QNL -->|next_step 14
flow phone| OTP["otp.html
OTP SMS #14"] QNL -->|next_step 33
flow email_verify| OTPE["otp-email.html
OTP email #33"] OTP --> QNV1["QNVerifyOtp"] QNV1 -->|next_step 90| OK(["success / newsletters
token + __utp"]) QNV1 -->|next_step 20
nuovo utente + phone_proof| REG["register.html
QNRegister phase=email_otp #22"] REG --> OTPE2["otp-email.html
OTP email #23"] OTPE2 --> QNV2["QNVerifyOtp #24
+ register_proof #24b"] QNV2 -->|next_step 25| PROF["profile.html #25
anagrafica + consensi"] PROF -->|register_proof| REG2["QNRegister #21
consensi+register+DOI+token"] REG2 -->|next_step 90| OK OTPE --> QNV3["QNVerifyOtp #34"] QNV3 -->|OTP ko| OTPE QNV3 -->|OTP ok → #30/#31/#50| QNV3b{"branch"} QNV3b -->|#50 sì → #65| OK QNV3b -->|next_step 37 + email_proof| PH["phone.html
QNAddPhone #37"] QNV3b -->|next_step 61 + uid| PH2["phone.html
QNAddPhone #61"] PH -->|phone_taken| ERR(["Errore
telefono già usato"]) PH -->|next_step 62| OTPP["otp-phone.html
OTP SMS #39"] OTPP --> QNV4["QNVerifyOtp"] QNV4 -->|next_step 41 + register_proof| PROF2["profile.html #41
consensi + anagrafica"] PROF2 -->|QNRegister #35+#36| OK PH2 -->|next_step 62| OTPP2["otp-phone.html #62"] OTPP2 --> QNV5["QNVerifyOtp"] QNV5 -->|next_step 63| PROF3["profile.html #63 = #25
prefill anagrafica → QNUpdateProfile"] PROF3 --> OK classDef page fill:#e0f2f1,stroke:#00695c,color:#004d40; classDef api fill:#fff3e0,stroke:#e65100,color:#bf360c; classDef ok fill:#c8e6c9,stroke:#2e7d32,color:#1b5e20; classDef err fill:#ffcdd2,stroke:#c62828,color:#b71c1c; class Start,OTP,OTPE,REG,OTPE2,PH,PH2,OTPP,OTPP2,PROF,PROF2,PROF3 page; class QNL,QNV1,QNV2,QNV3,QNV3b,QNV4,QNV5,REG2 api; class OK ok; class ERR err;

Overview chiamate FE (sintesi)

flowchart LR subgraph FE["/mockupfe"] F1[Login] --> F2["QNLogin"] F2 -->|#14| F3[OTP SMS] F2 -->|#33| F3e[OTP email] F3 --> F4["QNVerifyOtp phone"] F4 -->|#90| FOK[OK + token] F4 -->|#20| F5["QNRegister phase=email_otp #22"] F5 --> F6[OTP email #23] F6 --> F4b["QNVerifyOtp #24"] F4b -->|#25| F7[Profilo] F7 -->|#21| F5b["QNRegister → #90"] F5b --> FOK F3e --> F4e["QNVerifyOtp #34 + #30/#31/#50"] F4e -->|#65/#90| FOK F4e -->|#37| FPH[Telefono register] F4e -->|#61| F61["QNAddPhone #61"] F61 --> F62["QNVerifyOtp #62"] F62 --> F7b["QNUpdateProfile → #90"] F7b --> FOK end

1) QNLogin

POST ?action=QNLogin · { "identifier": "email|telefono" }

Orchestra fino a 14 (telefono, OTP SMS #13) o 33 (email, OTP #32).

next_step	flow	Schermata
14	`phone`	`otp.html`
33	`email_verify`	`otp-email.html`

2) QNVerifyOtp

POST ?action=QNVerifyOtp

Se OTP ok e non serve registrazione → search + token → next_step: 90 + access_token. Lato server, dopo il token viene eseguito User Collector ingest (non è una chiamata FE).

{
  "otp_code": "1234",
  "flow": "phone",
  "phone": "3331234567",
  "email": "user@mail.it",
  "uid": "",
  "stay_logged_in": true
}

flow	Esito
`phone`	#90 token oppure #20 register
`email_with_phone`	#90 token
`email_verify`	#34: OTP ko → #33; OTP ok → #30/#31/#50 → #37 / #61 / #65
`phone_register`	#25 profilo (+ register_proof) → poi #21
`email_register_phone`	#41 profilo (+ register_proof) → poi #35
`email_add_phone`	#63 profilo → QNUpdateProfile

3) QNRegister

POST ?action=QNRegister — fasi con proof firmati (no sessione).

Phone: #22→#25→#21 → #90. Email: #34→#37–39→#41→#35 (stessa chiamata: consensi + DOI #36 + update #40+#42) → #90.

{
  "phase": "email_otp",
  "email": "new@mail.it",
  "phone": "3331234567",
  "phone_proof": "...",
  "consents": { "terms_conditions": true },
  "flow": "phone_register"
}

{
  "phase": "register",
  "email": "new@mail.it",
  "phone": "3331234567",
  "register_proof": "...",
  "first_name": "Luca",
  "last_name": "Rossi",
  "birth_date": "1990-01-15",
  "city": "Milano",
  "flow": "phone_register"
}

phase=email_otp → 23 + pending_proof
phase=register → register_proof + profilo + consensi (#25/#41) → register + DOI + update → 90

4) QNUpdateProfile

POST ?action=QNUpdateProfile — unisce update_profile + access_token.

{
  "uid": "PNI...",
  "first_name": "Luca",
  "last_name": "Rossi",
  "birth_date": "1990-01-15",
  "city": "Milano",
  "otp_phone": "3331234567",
  "email": "user@mail.it",
  "stay_logged_in": true
}

{
  "success": true,
  "data": {
    "next_step": 90,
    "done": true,
    "uid": "PNI...",
    "access_token": "...",
    "screen": "success"
  }
}

5) QNAddPhone

POST ?action=QNAddPhone — step 61–62 (dopo login password o registrazione email).

Prima di inviare l’OTP verifica che otp_phone non sia già usato. Se esiste → errore phone_taken.

{
  "phone": "3331234567",
  "uid": "PNI...",
  "email": "user@mail.it",
  "flow": "email_add_phone"
}

flow: email_add_phone — percorso password (#60→#61)
flow: email_register_phone — percorso registrazione da email
Ok → next_step: 62 + OTP SMS

Unicità telefono

QNAddPhone — check prima dell’OTP
QNVerifyOtp (email_add_phone / email_register_phone) — ri-check dopo OTP
QNUpdateProfile e update_profile — check obbligatorio prima di salvare otp_phone
Errore: "Telefono già registrato su un altro account" · data.reason = phone_taken

Mappa mockupfe

Pagina	API	Note
`index.html`	QNLogin	#14 / #33 / #60
`otp.html`	QNVerifyOtp	#90 o #20
`otp-email.html`	QNVerifyOtp	#24 → #25 profilo · oppure #34 → #37 telefono
`register.html`	QNRegister phase=email_otp	#22 OTP email (serve phone_proof)
`register-email.html`	—	redirect a phone (consensi in #35)
`password.html`	login	#60 → phone
`phone.html`	QNAddPhone	#37/#61 + pending_proof se email_register
`otp-phone.html`	QNVerifyOtp	#39 → #41 · oppure #62 → #63
`profile.html`	QNRegister o QNUpdateProfile	con register_proof → #21/#35; altrimenti update
`newsletters.html`	newsletter_*	dopo auth
`success.html`	user_access_list	risorse accessibili con Bearer token
`recommendations.html`	recommendations	contenuti suggeriti Cxense (url + toptrend opz.)