Improves with-cookie-auth example #10062
Conversation
…all pages and in header
… access in getInitialProps
Stats from current PRDefault Server ModeGeneral
Client Bundles (main, webpack, commons)
Client Bundles (main, webpack, commons) Modern
Legacy Client Bundles (polyfills)
Client Pages
Client Pages Modern
Client Build Manifests
Rendered Page Sizes
Serverless ModeGeneral
Client Bundles (main, webpack, commons)
Client Bundles (main, webpack, commons) Modern
Legacy Client Bundles (polyfills)
Client Pages
Client Pages Modern
Client Build Manifests
Serverless bundles
Commit: 5e14936 |
Stats from current PRDefault Server ModeGeneral
Client Bundles (main, webpack, commons)
Client Bundles (main, webpack, commons) Modern
Legacy Client Bundles (polyfills)
Client Pages
Client Pages Modern
Client Build Manifests
Rendered Page Sizes
Serverless ModeGeneral
Client Bundles (main, webpack, commons)
Client Bundles (main, webpack, commons) Modern
Legacy Client Bundles (polyfills)
Client Pages
Client Pages Modern
Client Build Manifests
Serverless bundles
Commit: 758b14b |
|
"Access user data (token in this case) on the header or other Layout components its a real necessity." - That's true, but what you need is the data, not the token. A custom @VictorAssis Thank you for taking the time of creating a PR. For the reasons above I'm going to close it. The example should remove the token from the client code, so it would only be available for API calls, and won't be accessible through the client js. Meaning that the current example is not very secure, and this doesn't help. |
|
"That's true, but what you need is the data, not the token." - This is also true. I did not implement the login by saving other user data in cookies because I thought it might get too complex for the example, but I can change it here. "A custom _app will affect all pages in the app, you may not need auth info for all pages, therefore we don't recommend doing this, and specially if _app has getInitialProps, which will turn all pages into serverless functions." - I understand that, but if a site has a user info in the header and use the layout in all pages, i think that dont exist way to avoid this. Im right? Thinking of what you said, if I return the Layout component to the pages, use the HOC only in pages with Layout component and save other user data in token, do I solve these problems? Sorry for insist @lfades , i'm having a great experience with Next Js and i want to contribute. |
|
@VictorAssis No problem, Is nice to see that you're interested in fixing the example, here's what you can do:
|
|
@lfades I'm having some questions on how to remove the token from client. When you refer to having the token on the server, do you mean api endpoints or getInitialProps? I imagine these two scenarios: 1. Access cookies only in api When the api receive a request in login endpoint, then she save the token in the cookies and return a flag of success to the client. The profile endpoint directly access the token to get the data. The withAuth needs to consult the profile endpoint always (to get user info for header) or consult once and save the data in localstorage. To logout its necessary to create another endpoint who clean the cookie from api. The authorization header would not be necessary in this case. 2. Api doesn't change Here I am having trouble figuring out a way to not access the token on the client. Today, the login function in auth.js is responsible for saving the cookie and it runs on the client side. This is a problem? If not, withAuth's getInitialProps will check if it is on the client or server side for API call data or directly from the cookie. In this way, will also save user information in the cookie. And to logout, will we remove the cookie on the client (as it works today) or will we create an exit page that will remove cookies on the server? Thanks for help! |
|
@VictorAssis You are right, API routes would be needed for login/logout, and only the API routes will have access to the cookie, which should never be sent to the client, you may want to read the converstaion here: #9913 |
Access user data (token in this case) on the header or other Layout components its a real necessity.
To make this more easily, I created a HOC called withAuth that get the user from the cookie and enable that in pageProps and in the context of the pages.
To exemplify the use of HOC, I added in login page a message warning the user that he is already logged in and in the header I show the token and the logout button only if the user is logged.