Navigating to custom sign in page using `signIn()` replaces history. Is there a way to configure that or is this a bug?

[mikecabana]

Question 💬

When invoking the front end signIn() method, I get redirected to my custom sign in page. If I then hit the back button, it goes back to a blank page with about:blank in the URL.

Is there a way to configure history or back behaviour when invoking the front end singIn() method or is this a bug?

I'm following the pages documentation v3.

How to reproduce ☕️

[...nextauth].ts

...
pages: {
    signIn: '/auth/signin',
},
...

Nav component

...
<button onClick={() => signIn()}>
    Log in
</button>
...

My sign in page is basically a combo of email and providers (not email).

/pages/auth/signin.tsx

import { FunctionComponent } from 'react';
import { GetServerSideProps } from 'next';
import {
    signIn,
    getSession,
    getProviders,
    getCsrfToken,
    ClientSafeProvider,
} from 'next-auth/client';

interface SigninProps {
    providers: ClientSafeProvider[];
    csrfToken: string;
}

const Signin: FunctionComponent<SigninProps> = ({ providers, csrfToken }) => {
    return (<>...</>);
};

export default Signin;

export const getServerSideProps: GetServerSideProps = async (ctx) => {
    const {req, res} = ctx;
    const session = await getSession();

    if (session && res && session.access_token){
        res.writeHead(302, {
            location: '/'
        });
        res.end();
        return;
    }

    const providers = await getProviders();

    let csrfToken: string = null;
    if (Object.values(providers).find((p) => p.type === 'email')) {
        csrfToken = await getCsrfToken(ctx);
    }

    const providersWithoutEmail = Object.values(providers).filter(
        (p) => p.type !== 'email'
    );

    return {
        props: {
            providers: providersWithoutEmail,
            csrfToken,
        },
    };
};

Contributing 🙌🏽

No, I am afraid I cannot help regarding this

[ndom91]

Yeah so currently we're using window.location.replace which does not add the navigation to your history, causing the behavior your described.

next-auth/src/react/index.tsx

Lines 220 to 230 in 0989acc

	})
	const data = await res.json()
	if (redirect || !isSupportingReturn) {
	const url = data.url ?? callbackUrl
	window.location.replace(url)
	// If url contains a hash, the browser does not reload the page. We reload manually
	if (url.includes("#")) window.location.reload()
	return
	}

@balazsorban44 is there a security reason for this possibly?

Or would it make sense to change it to window.location.href = .. ?

See first paragraph here: https://developer.mozilla.org/en-US/docs/Web/API/Location/href

[balazsorban44]

I can try to trace this back, but generally I think it would be alright. I know there has been issues in the past that discussed using Next.js's router.push as well. It might be worth it to find that and see if there is an old reasoning for the current behavior.

[nguyenthetoan]

hello @balazsorban44 , have you found the reason yet?
For now my current workaround is to use next/link for the login navigation

<Link href="/auth/login">Login</Link>

Please also notice the NEXTAUTH_URL env variable, it should be the same origin

[preludeofme]

I was trying to use signIn() as well in my app, but found that not only did it replace the history but it also resets any context you have if you're using hooks (and I am assuming redux and other state libraries). As @balazsorban44 said, if you use router.push from next it fixes the issue. History and state are persisted.

as a workaround i'm using router.push('/signin') to navigate to the custom signin page I made, or if you're using a link using <Link href="/signin">Login </Link> works too.

[saeedseyfi]

I found this behavior of next-auth very strange as well. User should be able to use navigate back if they changed their mind and don't want to signin anymore.

I know there has been issues in the past that discussed using Next.js's router.push as well

@balazsorban44 if router.push didn't work as expected, what if you use window.push?
I'd really appreciate if you let us know what was the problem with router.push, or a link to the discussion.

[balazsorban44]

The client has been created to work with different libraries, but that has never become a thing. Currently only React/Next.js is supported, but that changes. See #2294

[saeedseyfi]

Yes, I understand, it's a great initiative to have it framework agnostic and I really appreciate it.

But my main concern here is to use push(assign href) instead of replace. It still will be framework agnostic and will keep the navigation history.

The fact that /api/auth/signin page doesn't have any cancel or back button, will make the need of browser's back button bolder.

[balazsorban44]

OK, I might have misunderstood the request here. I thought this was about signIn("some-id"), but you are actually talking about signIn(), without any parameters.

I will assume that by push you are referring to history.pushState. That won't actually transition the site, and if we wanted it to work in Next.js, we had to use the router from next/router.

The implementation was supposed to be framework-agnostic. In #2294 it will be easier to support different libraries/etc, my problem is that to be able to use next/router, the next-auth/react won't be a sufficient name as it cannot handle any client-side React implementation anymore.

The easiest fix for this is using window.location.href = as described here: #2676 (comment)

I'll open a PR soon :) You can test the changes in this experimental release: #2980 (comment)

Unfortunately, this means that as described in #2676 (comment) the state will be lost, but I don't have a better idea at the moment that wouldn't require splitting the react client up even more (I don't like the thought of next-auth/react/next)

I don't think this is a major issue since in most cases, I am certain people will use the signIn("some-id") form which redirects to an external URL, and the state is lost anyway.

If you have a custom sign-in page you want to show to the user first, a <Link href="/your/signin/page">Sign in page</Link> seems to be a better fit anyway, as an actual a tag is preferred over window.location APIs.

[mikecabana]

Closing since the solution will appear in an upcoming release.

[nickdandakis]

We're running into the inverse problem here where we want the history replaced instead of pushed.

Is there any appetite for an additional parameter to signIn to indicate a replace instead of a push? Maybe something like redirectReplace? I can work on a PR if so, @balazsorban44

—

For more context about our use-case. We've created some dedicated pages for /login etc and have links that point to them. Navigating back once on the auth provider takes the user to the /login page which just redirects them back to the auth provider. Using a replace would fix that