Intastellar voltooit terugkeerflows alleen naar URL’s die je vooraf hebt geregistreerd (of URI’s die je client toestaat voor de login-URI die de React- / platte JS-flows gebruiken). Een typfout, verkeerd schema of een extra slash veroorzaakt redirect_uri_mismatch (of iets vergelijkbaars) — de fout ziet er technisch uit, maar de oorzaak is meestal “de URL staat niet in de lijst”.

Als je hostnaam wijzigt (domeinmigratie, nieuwe CDN), werk de Intastellar-client bij zodat redirect- / login-items overeenkomen met de nieuwe origin en paden. SDK’s leiden vaak een login-URI af van de huidige pagina (hostname, port, pathname) tenzij je die overschrijft — registreer wat je daadwerkelijk verstuurt.

Snelle controles als het “opeens kapot” is

1. Vergelijk schema: https:// vs http://.
2. Vergelijk host: www. vs kale domeinnaam.
3. Vergelijk pad: /callback vs /callback/.
4. Vergelijk poort in dev: 127.0.0.1 vs localhost.
5. Controleer of je staging-client vs productie-client hebt bijgewerkt.

Vuistregels

1. HTTPS in productie — http://localhost mag vaak voor ontwikkeling; productie hoort https:// te gebruiken.
2. Exacte match — https://app.example.com/callback en https://app.example.com/callback/ zijn verschillende paden; registreer degene die je in het authorize-verzoek gebruikt.
3. Geen wildcards in de meeste opzetten — registreer elk concreet callbackpad (of volg het gedocumenteerde patroon van je console als patroontemplates worden ondersteund).
4. Querystrings — vermijd dynamische querystrings in de geregistreerde URI tenzij registratie dat expliciet toestaat; geef de voorkeur aan een vast pad en geef interne context door via state.

Meerdere omgevingen

Registreer aparte redirect-URI’s (of aparte clients) voor:

• Lokaal ontwikkelen (http://127.0.0.1:5173/auth/callback, enz.)
• Staging
• Productie

Zo beperk je de impact als een niet-productiesecret uitlekt.

SPA-routers

Als je hash-routing gebruikt (/#/callback), controleer of redirects naar dat patroon zijn toegestaan; veel opzetten vereisen padgebaseerde URL’s (/auth/callback) voor OAuth-callbacks.

Op de callbackroute (na redirect)

1. Lees code en state uit de querystring.
2. Controleer state tegen wat je opsloeg toen je de flow startte.
3. Wissel de code in bij het token endpoint — Authorization code flow.
4. Redirect de gebruiker naar de uiteindelijke bestemming in de app (dashboard, return-URL in state, enz.).

Veelgestelde vragen

SDK-pop-upflow — hebben we nog redirect-URI’s nodig?

Je hebt nog steeds correcte clientregistratie en vaak een geregistreerd login- / continue-patroon nodig. Als iets faalt voordat de pop-up klaar is, vergelijk wat de SDK verstuurt met wat is geregistreerd — zie je integratienotities.

We hebben de URL in onze code gefixt maar het faalt nog

De lijst in de Intastellar-client moet ook wijzigen. Nieuwe code deployen werkt registratie niet automatisch bij.

Volgende

Sessies, cookies en tokens — de ingelogde gebruiker veilig vasthouden na een geslaagde callback.