Versionv1

Intastellar fuldfører kun returflows til URL’er du forhåndsregistrerede (eller URI’er din klient tillader for login URI brugt af React / ren JS-flows). En tastefejl, forkert skema eller ekstra skråstreg giver redirect_uri_mismatch (eller lignende) — fejlen ser teknisk ud, men årsagen er som regel «URL’en matcher ikke listen».

Hvis du skifter værtsnavn (domænemigrering, nyt CDN), skal du opdatere Intastellar-klienten så omdirigerings- / login-poster matcher det nye origin og stier. SDK’er udleder ofte en login URI fra den aktuelle side (hostname, port, pathname) medmindre du overskriver den — registrer det du faktisk sender.

Hurtige tjek når det «pludselig gik i stykker»

  1. Sammenlign skema: https:// vs http://.
  2. Sammenlign vært: www. vs nøgdomæne.
  3. Sammenlign sti: /callback vs /callback/.
  4. Sammenlign port i udvikling: 127.0.0.1 vs localhost.
  5. Bekræft at du opdaterede staging-klient vs produktions-klient.

Tommelfingerregler

  1. HTTPS i produktionhttp://localhost er ofte tilladt til udvikling; produktion bør bruge https://.
  2. Præcis matchhttps://app.example.com/callback og https://app.example.com/callback/ er forskellige stier; registrer den du bruger i authorize-forespørgslen.
  3. Ingen wildcards i de fleste opsætninger — registrer hver konkret callback-sti (eller følg dit konsols dokumenterede mønster hvis sti-skabeloner understøttes).
  4. Query-strenge — undgå dynamiske query-strenge i den registrerede URI medmindre registrering udtrykkeligt tillader det; foretræk en fast sti og send intern kontekst via state.

Flere miljøer

Registrer separate omdirigerings-URI’er (eller separate klienter) for:

  • Lokal udvikling (http://127.0.0.1:5173/auth/callback osv.)
  • Staging
  • Produktion

Det begrænser effekten hvis en ikke-produktions-hemmelighed lækker.

SPA-routere

Hvis du bruger hash-routing (/#/callback), tjek om omdirigeringer til det mønster er tilladt; mange opsætninger kræver sti-baserede URL’er (/auth/callback) til OAuth-callbacks.

På callback-ruten (efter omdirigering)

  1. Læs code og state fra query-strengen.
  2. Verificer state mod det du gemte da du startede flowet.
  3. Udveksl koden på token-endepunktet — Autorisationskodeflow.
  4. Omdiriger brugeren til den endelige destination i appen (dashboard, retur-URL gemt i state osv.).

Ofte stillede spørgsmål

SDK popup-flow — skal vi stadig have omdirigerings-URI’er?

Du skal stadig have korrekt klientregistrering og ofte et registreret login / continue-mønster. Hvis noget fejler før popup’en er færdig, sammenlign det SDK’en sender med det der er registreret — se jeres integrationsnoter.

Vi rettede URL’en i koden, men det fejler stadig

Listen i Intastellar-klienten skal også ændres. At udrulle ny kode opdaterer ikke registreringen automatisk.

Næste

Sessioner, cookies og tokens — gem den loggede bruger sikkert efter en vellykket callback.

Last updated