Caching Historical Data
Answered
Devon Rex posted this in #help-forum
Devon RexOP
Hello there,
I have some historical data pages that only a user with specific roles can visit. I'm using Okta to get the user's entitlements.
I would like to statically render these pages while still being able to get the user's roles and permissions on the fly in order to decide whether they can access the page or not.
Is there an easy way to opt in static rendering, while still dynamically fetching the user.
I have some historical data pages that only a user with specific roles can visit. I'm using Okta to get the user's entitlements.
I would like to statically render these pages while still being able to get the user's roles and permissions on the fly in order to decide whether they can access the page or not.
Is there an easy way to opt in static rendering, while still dynamically fetching the user.
Answered by B33fb0n3
I would cache the historical data and check if the user has access everytime the user visits the page. Like that I can load the data via the cache if there is any cache and prevent security vulnabilites, because I check the auth everytime
9 Replies
@Devon Rex Hello there,
I have some historical data pages that only a user with specific roles can visit. I'm using Okta to get the user's entitlements.
I would like to statically render these pages while still being able to get the user's roles and permissions on the fly in order to decide whether they can access the page or not.
Is there an easy way to opt in static rendering, while still dynamically fetching the user.
yes, you can add
to your page.
- On first visit: page will be build dynamically on request time. The created HTML, JS, CSS will be cached
- On second and more visits: The cached HTML, JS, CSS will be delivered to the client instantly
You can revalidate the cache to create a new version of the page.
By the way: that's a bad practice. Why? Imagine someone know the url, then he can directly visit this url and have access, without needing to be logged in. Because when serving the HTML, JS and CSS there is no auth check.
export const dynamic = 'force-static' to your page.
- On first visit: page will be build dynamically on request time. The created HTML, JS, CSS will be cached
- On second and more visits: The cached HTML, JS, CSS will be delivered to the client instantly
You can revalidate the cache to create a new version of the page.
By the way: that's a bad practice. Why? Imagine someone know the url, then he can directly visit this url and have access, without needing to be logged in. Because when serving the HTML, JS and CSS there is no auth check.
Devon RexOP
@B33fb0n3 thank you for your quick answer
Basically, the idea is that there would be a dropdown where users can select a page and get redirected to this page.
A user will first go through an Okta authentication flow. So I'm wondering whether this scenario makes it possible to have the pages statically rendered, or using Okta client SDK will ultimately make the page dynamic since Okta most likely access the header.
Basically, the idea is that there would be a dropdown where users can select a page and get redirected to this page.
A user will first go through an Okta authentication flow. So I'm wondering whether this scenario makes it possible to have the pages statically rendered, or using Okta client SDK will ultimately make the page dynamic since Okta most likely access the header.
@Devon Rex <@301376057326567425> thank you for your quick answer
Basically, the idea is that there would be a dropdown where users can select a page and get redirected to this page.
A user will first go through an Okta authentication flow. So I'm wondering whether this scenario makes it possible to have the pages statically rendered, or using Okta client SDK will ultimately make the page dynamic since Okta most likely access the header.
whenever there is auth, you should really watch out for stale data and vulnabilites. So if I would be you, I would keep it dynamically to prevent security vulnabilites.
Devon RexOP
@B33fb0n3 Makes sense.
In the context of Next.js and considering the data on these pages will never change (historical data). What would you say is the best approach?
In the context of Next.js and considering the data on these pages will never change (historical data). What would you say is the best approach?
@Devon Rex <@301376057326567425> Makes sense.
In the context of Next.js and considering the data on these pages will never change (historical data). What would you say is the best approach?
I would cache the historical data and check if the user has access everytime the user visits the page. Like that I can load the data via the cache if there is any cache and prevent security vulnabilites, because I check the auth everytime
Answer
@B33fb0n3 I would cache the historical data and check if the user has access everytime the user visits the page. Like that I can load the data via the cache if there is any cache and prevent security vulnabilites, because I check the auth everytime
Devon RexOP
Ok so caching at the data level and not page/route level, correct?
@Devon Rex Ok so caching at the data level and not page/route level, correct?
yes, keep the page dynamic to check the auth everytime (or check the auth via middleware) and have static historical data
@B33fb0n3 yes, keep the page dynamic to check the auth everytime (or check the auth via middleware) and have static historical data
Devon RexOP
Sweet, appreciate the help!
happy to help