Resolving Next.js Deployment Issues: A Practical Guide to Authentication and Redirection Problems

date
Jun 9, 2024
slug
3
status
Published
tags
Next.js
Vercel
Authentication
summary
type
Post
I encountered two problems after deploying my next.js project to Vercel. Here is a record of how I fixed these two issues. You can refer to this if you encounter similar problems.
  1. Google verification cannot be used, the prompt information is as follows. But I can run it normally on my local development branch.
      2. notion image

      Solution:

      1. Modify the NEXTAUTH_URL in vercel, changing the original localhost:3000 to the actual website address.
          2. notion image
      1. Enter console.cloud.google.com:
          • Select your project.
          • Navigate to the "Credentials" page.
          • Find the entry related to your OAuth 2.0 client ID.
          • In "Authorized redirect URIs", make sure to add the redirect URI of the application you deployed on Vercel. For example, if your application's domain on Vercel is https://your-app.vercel.app, then you need to add a URI like https://your-app.vercel.app/auth/callback (the specific path depends on your application configuration).
          notion image
  1. Unable to redirect to personal page after verification
      2. After solving this problem, although one can pass the verification, it is not possible to redirect to the user information page as expected. Upon investigation, the problem might lie in my use of router.push to perform page redirection.

      Possible Reasons

      1. Browser history management:
          • Using router.push will add a new entry in the history record. This means that users can press the "back" button to return to the previous page (in your case, it might be the login page).
          • If router.push is executed immediately after a successful login, the user might be redirected back to the login page, because router.push will add a new history record entry on the current page, causing the browser to mistakenly think that the user has returned to the login page.
      1. Component state and rendering:
          • In some cases, using router.push may cause component states or lifecycle hooks (such as useEffect) to be triggered multiple times, which may lead to some unexpected behavior.
          • router.replace avoids the possibility of multiple triggers by replacing the current URL, ensuring a smoother redirection.
      1. Redirection logic and asynchronous handling:
          • If there is asynchronous processing (such as API calls, authentication status checks, etc.) in the redirection logic, using router.push might trigger before the completion of asynchronous operations, leading to unexpected behavior.
          • Using router.replace ensures that the URL is correctly replaced after the completion of asynchronous operations.

      Explanation of Sample Code

      Original Code:
      Modified code:
Moreover, in the login scenario, using router.replace is more appropriate than router.push. Login is generally an irreversible operation, that is, after the user successfully logs in, they should not be able to return to the login page through the browser's back button. This is for considerations of security and user experience.
When using router.push to jump to other pages after login, users can still return to the login page through the browser's back button, which may lead to some security risks and confusion. In contrast, router.replace does not add new records to the browser's history, but directly replaces the current URL.
This means that after the user successfully logs in, clicking the browser's back button will not be able to return to the login page, but will go back to the page before login or directly exit the application. Therefore, using router.replace in the login scenario can prevent users from returning to the login page through the browser's back button, thereby improving the security and user experience of the application.
 

© Ralph Li 2021 - 2025