oidc-client
oidc-client copied to clipboard
Incompatibility with next.js redirects
Issue
If redirects are configured in a next config the sessions don't seem to make it into session storage, which results in a redirect back to login, which then redirects back to the app - this cycle happens indefinitely.
Steps to reproduce:
-
Add a new route file (e.g.,
test.js
) -
Configure a redirect in a next.js config file (e.g., in a
next.config.js
file in the root directory):
/** @type {import('next').NextConfig} */
const nextConfig = {
async redirects() {
return [
{
source: '/',
destination: '/test',
permanent: false,
},
]
},
}
module.exports = nextConfig
Versions
- react-oidc v6.5.7
- next v12.2.5
- react v18.2.0
Hi @madze , thank you very much for your issue. What does look like your oidc configuration?
Hi @guillaume-chervet - Sorry, I should have also mentioned that this was actually using the next.js demo within this repository - So it's the same config that is in there (I just upgraded the react packages):
const configuration = {
client_id: 'interactive.public.short',
redirect_uri: 'http://localhost:3001/#authentication/callback',
silent_redirect_uri: 'http://localhost:3001/#authentication/silent-callback', // Optional activate silent-signin that use cookies between OIDC server and client javascript to restore the session
scope: 'openid profile email api offline_access',
authority: 'https://demo.duendesoftware.com'
};
Thank you! Let me know if I can assist further!
Hi @madze , i haven not tested but i think if you update your config like bellow it will work:
const configuration = { client_id: 'interactive.public.short', redirect_uri: 'http://localhost:3001/test/#authentication/callback', silent_redirect_uri: 'http://localhost:3001/test/#authentication/silent-callback', // Optional activate silent-signin that use cookies between OIDC server and client javascript to restore the session scope: 'openid profile email api offline_access', authority: 'https://demo.duendesoftware.com' };
@guillaume-chervet - Thanks!! I just finally had a chance to take a look and though I haven't tested extensively I can verify that this at least works for basic redirects. Also, it seems that this may only be necessary for the case where a redirect is set up on the root path (e.g. redirecting /
to some other route).
Thank you!!
Thank you for the feedback @madze , that a good new :)
May we close the issue?
@guillaume-chervet - Yes, absolutely! Sorry, I should have added that in the last message.
Thank you very much @madze