search

atinux / nuxt-auth-utils

Add Authentication to Nuxt applications with secured & sealed cookies sessions.
MIT License
981 stars 91 forks source link

Support exclude specific routes from fetching session on prerendered pages #114

Closed Yizack closed 3 months ago

Yizack commented 4 months ago

Hello! I was wondering if it is possible to implement a feature that excludes specific routes from session fetching on the client side when prerendering those pages.

Current behavior

When prerendering pages, every time a person accesses or reloads ANY page of my Nuxt app using this module, a GET request to /api/_auth/session will be made to fetch the session on mounted.

Feature request

My case would be:

  1. Let's say I have a web app with prerendered page routes such as /about, /terms, /privacy, etc.
  2. A /login page that externally redirects to SSR-enabled routes inside /app once authenticated.

I'd want the session to be fetched only for the /login page and page routes inside /app.

For the prerendered pages outside the application side, I'd like not to fetch the session while accessing them because it would be useless and waste requests count always calling /api/_auth/session every page access because it won't make use of that fetched data since the login auth will externally redirect to /app and will be SSR fetched there.

The approach I'm thinking of is adding a runtime config that accepts an array of specific paths that would work only for prerendered pages. This would be used to disable fetching. Then in the file below return early from the mounted hook if the route path is included in the array, preventing session fetching.

https://github.com/Atinux/nuxt-auth-utils/blob/c8b02d0b84a53ab4dd41f1808d9365d1c52c8366/src/runtime/app/plugins/session.client.ts#L1-L9

Let me know what you think! 😊 or if there is already an alternative to achieve this.

amandesai01 commented 4 months ago

TLDR; Do you have a lot of pages which do not need authentication? I would suggest that only in that case you invest efforts. If it is just about simple homepage, terms page, etc. I would suggest to not waste your valuable development time on this.

The idea behind this is session is fetched when app is first loaded onto browser.

So, while your request is correct, I would still argue if it is feasible to add the complexity. Because a lot of the code expects session to be there. If user visits a whitelisted page and then navigates to authenticated page, session will be required.

Everything summed up, I would not recommend doing that. Our application also has the same case as yours and we decided to just accept it to be part of process and take that small hit (gaining a lot of simplicity and less potential bugs)

Yizack commented 4 months ago

If user visits a whitelisted page and then navigates to authenticated page, session will be required.

I understand but in my case my app doesn't have any router navigation to an authenticated page outside the app routes.

Everything summed up, I would not recommend doing that. Our application also has the same case as yours and we decided to just accept it to be part of process and take that small hit (gaining a lot of simplicity and less potential bugs)

Perfect! I understand, thank you for the response and for your time reading my request ❤️ the issue can be close as not planned 👍

atinux commented 3 months ago

Closing it but wanted to thank you both on brainstorming and giving more hints to other users reading this.

I agree with @amandesai01 as fetching the session anyway once loading the page avoid any complex logic to be added and this API call is not blocking anything too.