Access Request Object in New App Directory Page Route

[muellerluke]

Describe the feature you'd like to request

With Next.js 13 a lot changed for the better. However, It looks like the server functions for fetching data don't have access to the request like getServerSideProps did in Next.js 12. It appears they only have access to url params, but not the entire request object which is odd and unfortunate. I think it would be beneficial to at least make it available somehow in the page file of a route in the app directory. Sites and platforms that are domain name driven would need it.

Describe the solution you'd like

The solution would look something like this:

//app/hello/page.js file
export default function Page({params, searchParams, request}) {
  //so that request can be passed into any data fetching function and can validated
  return <h1>Hello, Next.js!</h1>;
}

Describe alternatives you've considered

Basically, the same thing, just make people parse the url from the request object for the params themselves I guess?

//app/hello/page.js file
export default function Page({request}) {
  //so that request can be passed into any data fetching function and can validated
  return <h1>Hello, Next.js!</h1>;
}

[leerob]

What are you looking to read from the request object? IYCMI, there's functions like headers and cookies.

[muellerluke]

It would be nice to have the route available instead of having to hardcode anything that requires the route. Also, how are cookies supposed to be set now without access to the req and res? The cookies function is read only.

[muellerluke]

Not having access to the request object also makes it impossible to get user's location which is necessary in a lot of applications.

Also, it would be nice to have a variable that doesn't have to be passed through props that you could attach data to. For example, you could attach the user object to the request: req.user = {user object};

That way, user objects wouldn't have to be passed through multiple components or found multiple times in the server components that need the user object. Hopefully that makes sense.

[dejanvasic85]

Also, it would be nice to have a variable that doesn't have to be passed through props that you could attach data to. For example, you could attach the user object to the request: req.user = {user object};

Running in to this exact issue. We need to have the user object in:

• middleware
• layout
• pages

All on server side (because we may need to do some redirection). At the moment, to fetch the user we're doing an http call and that results in at least 3 network calls per next request. This is user data so we probably don't want to be caching it either.

Svelte have an equivalent of middleware in hooks where they allow for local data to be set which would be neat here:

[redbmk]

How do you get pathname and search params in a server action? Maybe this is an antipattern, but I find myself redirecting inside server actions and need to add or remove a search param without wiping out all the others. The only way I've found, since there's no access to the Request, is to include them in the form from a client component, which feels really hacky:

const pathname = usePathname();
const searchParams = useSearchParams();

return (
  <form action={search}>
    <input type="hidden" name="pathname" value={pathname} />
    <input type="hidden" name="searchParams" value={searchParams.toString()} />
    <input name="query" defaultValue={String(searchParams.get("query") ?? "")} />
    <button>Search</button>
  </form>
)

[mechadragon01]

+1 Would like full request object to do subdomain logic

[leerob]

I would recommend Middleware for this https://vercel.com/guides/nextjs-multi-tenant-application

[dsevans93]

@leerob , middleware incurs cost after 1M invocations. We hit that limit after 1 week.

[leomeneguzzi]

@dsevans93 the 1M invocations is related to the Vercel pricing? But if you self-host it, what is the limitation? I'm asking because I want to build a business with "subdomain/multi tenant logic", if you could explain in more detail I would really appreciate your help

[tbscode]

Middleware can't be the solution here, it should be possible to process requests on a page by page basis.
Just seems like another move towards making more profit on existing next.js deployments.

[k-zakhariy]

middleware is a bullshit, which is not suppose to work with Node environment, for example i can't use ioredis package on pages registered in middleware matcher

[SasheVuchkov]

Missing access to the response and request objects is a total deal-breaker...

[JacobWeisenburger]

@leerob
please send an example of how to do this. considering https://beta.nextjs.org/docs/middleware is marked as a TODO.

my use case is trying to mark a link as active on the server side. perhaps there is a NavLink component or something I couldn't find in the docs.

[leerob]

I would use a client component for that with the provided hooks we've given 👍

[leerob]

Here's an example: https://github.com/leerob/leerob.io

[JacobWeisenburger]

I would use a client component for that with the provided hooks we've given 👍

Can you explain your reasoning for why using a client component is better? I would prefer to limit the amount of js that I'm sending to the client. This is why I would prefer doing this server side.

[vks-brussell]

For me personally response object is more important than request object. Here is my dilemma :
Currently my next12 app used getServerSideProps to fetch dynamic content from my CMS, which would give ( write to the response object ) status codes of 200, 202, 307, 400, 403, 404, or 408 depending on what came back, and this was all done with my response object within the getServerSideProps ( on the server side so in this way I could deliver fast response to my clients, and accurate status codes for my SEO and other tools such as google search console, or give redirects if needed from the server rather than wait for the client to find out it should redirect. This approach also helps ensure the majority of all error handling is dealt with even before it hits the client side too).
With handling high volume of route requests the thought of migrating this logic to the middleware would absolutely slow down my application, as the middleware is executed on every route, as apposed to what I had in next12 where only the pages needing this logic had this logic.
@leerob , Should I move this logic into the middleware ( and potentially add $ to the server ) regardless as you have recommended or will next13 also adapted the ability to do these things on the server side in a more optimized manner as next12 could do? Currently I have part of my app in pages ( the part that requires this logic ), and the other part of my app uses appDir ( the more static content that doesn't use my CMS data ).
My current approach to solving this problem is waiting for an update to the appDir to have the ability to write to res. But if this is intentionally never going to happen I rather know now so I can slowly start adopting my middleware before next12 is too old to make that process an enjoyable dev experience.
Thanks for taking the time Leerob! It's much appreciated.

[OrfeasZ]

Our use case for having access to the request object is to be able to properly handle native form submissions from pages for users with noscript, broken javascript, or with pending hydration, so we would like to see a way to be able to access it from an app page component instead of relying on the existence of a separate API route and the assumption that clients always can run our javascript.

[chris-monahan]

FWIW while I totally agree that this shouldn't need a seperate API route to be created for a form (it's clunky and compares poorly with many other frameworks that don't need extra files and routes just to handle a form submission) it should be possible to handle a form submission via an API route without needing JavaScript by using an HTTP redirect back to the original form. I guess this is what I'm going to have to do.

[rienst]

In that approach, I miss a flash message system for reporting validation errors or success messages back to the user. How would you implement this?

[OrfeasZ]

@rienst a way would be to redirect the user from the api route to the previous page with some additional query parameters or by attaching additional data to the users session (assuming you are keeping track of one), but that's obviously not ideal and it complicates things like maintaining form inputs after an unsuccessful submissions.

[rienst]

Exactly, and you do not want sensitive form data passed around in query strings.

[OrfeasZ]

If you're keeping track of internal user session data you could keep it there only on the server side but then you have to deal with invalidation and expiry of stale data, and similar "issues" that just add unnecessary complexity.

[dconroy96]

Currently have a use case for the to access the request object on a server page.js component when configuring AWS Amplify withSSRContext method. Have tried a couple of different workarounds (manually recreating the request object / passing req object as itself in a req header) but can't get the right configuration.

Is there currently any known workaround or suggestion for dealing with this?

[murgatt]

@dconroy96 I am in the exact same situation, I think I finally found a workaround. withSSRContext only need the cookie property from headers. You can get headers with headers() function from next/headers. So you should be able to create a fake req objet to pass to withSSRContext. Something like that:

const req = {
    headers: {
      cookie: headers().get('cookie'),
    },
  };
const { Auth, API } = withSSRContext({ req });

Hope it will help you

[dconroy96]

@murgatt Sorry for delay but this worked! Thanks for the help!

My original error was trying to apply only the accessToken cookie rather than just using the entire cookie header.

[ekkusi]

Any updates on this, are these going to be implemented in the future?

My use case is that I have a graphql server running on a API route and this cannot be called with fetch within the server components. It would seem that the request object would be required to call the graphql handlers directly without a http request.

[Townsheriff]

I can't set a cookie from SSR.

[leerob]

We are aware - this will be solved with mutations.

[auaden]

Same. My use case is dealing with token expiry. The api server sends back an updated token (after fetching a resource in the server component) which then needs to be updated on the browser in the form of cookies.

[unoscar]

Having this same limitation. I am using next-auth and I need to req object to be available to use the getToken(req) method to make GraphQL queries to my db

[dragos-popescu]

I needed the same. The solution is mentioned here in the docs: https://beta.nextjs.org/docs/routing/route-handlers#extended-nextrequest-and-nextresponse-apis. So you can just import { type NextRequest } from 'next/server';
and then export async function POST(req: NextRequest)... . Hope this helps.

[Sid-Turner-Ellis]

@dragos-popescu I believe he is asking how to access it from a page rather than a route

[charanjit-singh]

Any solution?

[Sid-Turner-Ellis]

What are you trying to do?

You only have access to the request object in middleware and API routes

[shaunwarman]

Looking for the equivalent of say pages/_app.tsx

import App from 'next/app';

function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />;
}

MyApp.getInitialProps = async (appContext) => {
  const appProps = await App.getInitialProps(appContext);

  // Check if we are on the server-side
  if (app.ctx.req) {
    const { default: getHeaderFooter } = await import('../lib/header-footer');

   // get request / response objects here
    const { req, res } = app.ctx;

    props = await getHeaderFooter(req, res);
  }

  return { pageProps: props };
};

export default MyApp;

This is especially useful with custom server using express with middleware that may have a req.locale object.

Where lib/header-footer may be

// get header / footer from some service
export default async function getHeaderFooter(req, res) {
  setNavOptions(req, { locale: req.locale});
  const fragments = await fetchComponent(req, res, ['header', 'footer']);
  
  const headerHtml = fragments.header.bodyHtml;
  const footerHtml = fragments.footer.bodyHtml;
  return { navigation: { headHtml, headerHtml, footerHtml } };
}

[MahmoudBakr22]

@leerob so how can I add custom response header it can not be set in middleware cause this header depend on the data fetched in a server component

[sayeems]

I'm facing the same issue. @MahmoudBakr22 did you find any solution?

[zhiln]

any solution yet? 🙏
facing the same issue

[4hmaad]

I need to access the server-to-server (s2s) token stored in the req.session object. We generate the token using the middleware fn and pass it into req.session. One workaround is to create a route handler instead of directly calling the endpoint. Any suggestions?

fyi, we are using IronSession library for the session management.

[jogamod]

@4hmaad did you manage to find solution?

[tawsbob]

I also need to have access the request object if it is possible 😛

[nguyentung5]

Please have the req object and res object back for package compatibility.

[jomarl]

I understand that they want to abstract away stuff, but I'm completely baffled that the request object is not available. It will probably result in less adaption for existing applications, e.g. for real world applications there are budgets and costs involved.

Have Vercell said anything about how long they will support both the paradigms? We are worried that it's not sustainable in the long run to support two different paradigms in the same framework, and if the framework is actually getting even less flexible than it already is we are potentially in "deep shit" given the amount of resources and dollars already invested in our NextJS based application. We are hardly in production and the fear of having to invest in yet another framwork migration is already starting to manifest itself.

I guess this is typical for the JS community.

[uellenberg]

I'm not really sure how to implement things like CSRF and sessions without access to this.

• Sending CSRF tokens can be done on the middleware, but middleware doesn't support crypto (or connecting to DBs like Redis), so I can't really implement secure CSRF.

• Sessions require cookies, which I can set in middleware, but I can't access a store there (and I don't want to use JWT for bandwidth/security issues).

These feel like pretty basic features to me, but are pretty much impossible in the app directory. At least, without making sacrifices like less secure CSRF and JWT-based sessions.

[felixSchl]

How would you implement old school flash messages with these restrictions?

[leerob]

Hey folks, we've added some frequently asked questions to the App Router docs which could hopefully help answer a few questions in this discussion.

This is by design, learn more here: https://nextjs.org/docs/app#how-can-i-access-the-request-object-in-a-layout

[leerob]

I was not aware that you could access the url with params/searchParams in server components. If that’s the case, then everything should be available! I will check it out.

I talk about this in the FAQs linked above 😄

[raiyansarker]

@leerob Is there any way to access the req url from page file? and is next-url header reliable? I mean, I saw some discussions on next-url being undefined in production.

[tbscode]

I need the request body, see my comment here: #42732 (comment)

[johnlarson]

Hi! Thanks for all the DX-focused work you and everyone else does at Vercel. I'm always amazed at how easy and intuitive Next.js is to use, and I'm loving the app router. When used correctly, it somehow manages to make data-wrangling lower-complexity than the old fully-backend-rendered MVC frameworks and does so without losing the power of front-end rendering.

I think that question on the FAQ addresses something subtlely different from the feature requested in this issue. The FAQ addresses why the request object is not available specifically in layouts, but the requested feature is to make it available in pages. If there is a way to make the full request object available in pages without making it available in layouts, I think that would solve a majority of the use cases raised in this thread.

I don’t know what kind of work a feature like this would entail for the Next.js team, but I would like to point out that it doesn’t raise the same DX concerns as allowing request object access in layouts:

Layouts do not rerender. They can be cached and reused to avoid unnecessary computation when navigating between pages. By restricting layouts from accessing the raw request, Next.js can prevent the execution of potentially slow or expensive user code within the layout, which could negatively impact performance.

(from https://nextjs.org/docs/app#how-can-i-access-the-request-object-in-a-layout)

My understanding is that this doesn’t apply to pages in the same way that it applies to layouts. I would assume that pages with dynamic content wouldn’t follow the same caching and rendering rules as layouts, as the data displayed is expected to change from page view to page view in response to application data mutations, and the performance implications of slow pages are less severe and much easier track down and resolve than those of slow layouts.

This design also enforces consistent and predictable behavior for layouts across different pages, simplify development and debugging since developers can rely on layouts behaving the same way regardless of the specific page they are applied to.

(also from https://nextjs.org/docs/app#how-can-i-access-the-request-object-in-a-layout)

A page isn’t applied to multiple routes the way a layout is, so consistency between routes isn’t a concern for pages.

I’d also like to point out that there’s a precedent for providing data to pages not available to layouts, and it highlights the most obvious place in Next.js’s interface to make the request object available:

https://nextjs.org/docs/app/api-reference/file-conventions/page#props

Giving access to the request object in pages would solve a myriad of use cases, some of which have been shown in this thread to be deal-breakers for teams with unique requirements. It's just the right level of flexibility, as it doesn’t allow developers to shoot themselves in the foot in the same way that it would in layouts.

Is this worth revisiting?

[ecline123]

Explaining that not having access to the request object was intentional is not much consolation to all the people on this thread that are providing feedback on that decision. Further, to be complete the FAQ should mention that if you dare to use those helper methods for headers and cookies that you will no longer cache anything in the data cache because now your route is "dynamic". Why on earth would anyone want to cache any data across requests, right???

[elja]

In our case, a middleware(s) initializes different services or API clients and injects them into the request object. The idea is to take those instances whenever you need them in the app and work with them, but not having access to a request object on the server-side component ruins that approach. Currently, we have 2 different auth0 providers in the same app, and we want to work with them on other pages, so we need some kind of a global context that is passed through the whole stack. It's contradictory that you can modify req in middleware and then not be able to work with that in server components. I think we should even treat server components rendering as a final step of middleware stack. It's widely used thing in rack-backed ruby apps, python web framework apps, etc.

[rexfordessilfie]

Haven’t tried this out yet, but React cache or Next.js unstable_cache could get you to where you want to be here.

https://nextjs.org/docs/app/building-your-application/caching#react-cache-function

https://nextjs.org/docs/app/building-your-application/caching#unstable_cache

[elja]

Haven’t tried this out yet, but React cache or Next.js unstable_cache could get you to where you want to be here.

https://nextjs.org/docs/app/building-your-application/caching#react-cache-function

https://nextjs.org/docs/app/building-your-application/caching#unstable_cache

thanks for sharing, but this looks like a caching mechanism for front and backends.

[rexfordessilfie]

So, I hacked around and created some helpers for url() and request(). It relies on the information from the headers() helper to reconstruct a request() object. Its not technically the same request object as the middleware receives, but it should have the same information in it, including any headers that are set in the middleware itself.

@leerob, I initially tried to dynamically derive the url using import.meta.url and the page props per FAQ here, but it was tedious, and I abandoned that approach once I noticed the 'x-invoke-path' and 'x-invoke-query' internal headers. Not sure how stable such headers are considered to be, and perhaps if they should be highlighted in documentation (in spite of them being internal)? Also perhaps maybe their usage is not encouraged?

For me this implementation show-cases that there is path toward achieving most of the functionality with just headers() and cookies() which make up the bulk of a request object for pages.

At the same time, it would be great if Next.js could provide such a helper (read-only) similar to headers() for DX purposes! It would also ideally use AsyncLocalStorage approach and wouldn't have to be rebuilt every time like in this snippet. But again headers() and cookies() should probably be enough as request() below feels like sugar on top of those (per my implementation).

Code:

import { headers } from "next/headers";

type URLOptions = {
  protocol?: string;
};


export function url(options?: URLOptions) {
  const protocol = options?.protocol ?? "https";
  const host = headers().get("host");
  const path = headers().get("x-invoke-path");
  const searchParams = JSON.parse(
    decodeURIComponent(headers().get("x-invoke-query") || ""),
  );

  const url = new URL(`${protocol}://${host}${path}`);

  Object.entries(searchParams).forEach(([key, value]) => {
    if (Array.isArray(value)) {
      value.forEach((v) => url.searchParams.append(key, v));
      return;
    }
    url.searchParams.append(key, value as string);
  });

  // NB: since we can attach request headers in middleware, you can technically attach a `x-url` 
  // header to the request inside middleware and use that here instead of assembling url pieces together
  // from internal headers.
  return url;
}

export function request() {
  const request = new Request(url(), {
    method: "GET", // Pages always requested via GET
    headers: headers(),
    body: null, // GET requests do not have a body (ideally)
  });

  return request;
}

Also a pattern for attaching extra information to the request object for use in any server component. NB: this would require re-init each time:

export function appRequest() {
  const req = request();
  // ...attach stuff to the request as needed. e.g req.db, req.user etc.
  return req;
}

Additional Notes

Using AsyncLocalStorage form of request()/appRequest()

• I tried making an AsyncLocalStorage wrapper to apply at the top page level so I could initialize once and access in child server components, but it did not work. Probably child server components are executed in a different context than the page for optimization purposes.
• It would be great if Next.js provided a way to register custom AsyncLocalStorage runners (possibly from next.config.js) to have shared "context" across server components. The custom ALS could be triggered somewhere here, similar to existing requestAsyncLocalStorage.
  • This could provide the most mileage but may also affect dynamic rendering speed if very heavy computations are performed when initializing the AsyncLocalStorage store. To mitigate this, the store could also be set to a free object/map and then user is responsible for lazily setting properties whenever they want inside of middleware/server component etc.
  • This could have its own name, and special APIs for setting values that are accessible across server components.
• Maybe this is possible already, but I don't know enough to achieve it yet from outside the framework!

Edit: something exactly like this (may) already exist in the form of React’s cache utility!

I'm also happy to think about how particular use-cases might be solved (to the best of my knowledge) where a request object is desired.

[HenriqueLimas]

The reason AsyncLocalStorage doesn't work in this use case its because the RSC bundle is different then the execution layer, so variable references are different. The way that it can be worked is by moving the async local storage to an npm package and set that npm package as an external to RSC using the serverComponentsExternalPackages configuration. And you would need to set up a custom next server

[shaunwarman]

@HenriqueLimas this is interesting and I think super relevant to our problems with custom server. 2 in particular:

• Accessing global modules in require.cache across custom server & Next.js
• Accessing context/data inside Next.js, that gets attached in custom server

Along with looking into AsyncLocalStorage we're looking at globalThis as well in places. Not ideal, but the boundary between custom server and next.js server does bring some issues and gotchas still. Can you elaborate if you are doing the above using serverComponentsExternalPackages and what issues you had to work around?

[ericbiewener]

@HenriqueLimas's solution does indeed work! Great job finding the solution to making the package external. The way that RSCs bundle in their own instance of dependencies is a big gotcha.

@shaunwarman The problem with using globalThis is that you can't make it unique to the request.

[eugeniosegala]

I personally think that an application running on a server should be able to access the request object.

This is possible in other frameworks such as Laravel, Spring Boot and many others.

A simple use case would be:

You want to create a simple HTML form which will send a post request and display errors in-line, within the same page.

An argument against the above would be: "Why would you want to create HTML post forms?".

And my answer would be:

There are cases where you can't simply always rely on JavaScript running on a browser to perform certain operations, so depending on your use-case, you may want to embrace the "Progressive enhancement" pattern which will require you to use "old fashioned" HTML forms.

Is there a way to easily achieve the following:

sample-html-post-form.mov

I have tried using the "Route Handlers" but it seemed more complex compared to a normal HTML form?

[leerob]

Creating forms that display errors inline, and also support progressive enhancement, are possible with Next.js: https://nextjs.org/docs/app/building-your-application/data-fetching/forms-and-mutations

[eugeniosegala]

Hey @leerob, thank you for sharing additional documentation!

I will try this out and update this thread!

[eugeniosegala]

Hello @leerob, I tried your suggestion and I also followed one of the tutorials you published on YouTube - Thank you for that!

I have created a new application using npx create-next-app@latest -e next-forms.

I'm able to send data to the server when JavaScript is disabled/enabled but it looks like it's not possible to show in-line errors when JavaScript is disabled?

My understanding is that, eventual errors will be part of:

const [state, formAction] = useFormState(createTodo, initialState)

// state.message

However, state is always null when JavaScript is disabled.

Additionally, I don't seem to be able to see the response of the form requests from the network tab:

Perhaps I'm doing something wrong?

Demo:

next-server-actions.mov

[eugeniosegala]

Hello @leerob, I was wondering if you had a chance to look at the above? 🙏

[hassanzohdy]

@leerob Consider the following scenarios:

1- Fetching same data in the generateMetadata and the page component, i know that fetch is caching the same request but something like providing the request object to both functions will reduce unnecessary checks.
2- For generateMetadata, i want to dynamically add the canonical url based on the current request path, instead, i've to add it manually in each single page in the project.

[tbscode]

The way I use next.js I require access to the request object.
What I do:

1. Server a django app, all requests go to the django app.
2. Django perform users authentication and the requests a rendered page from nextjs WITH the user-data

I used to be able to extract the request data like this:

export const getServerSideProps = async ({ req }: { req: any }) => {
  if (req.method == "POST") {
    const res = await handleStreamedProps({ req });
    return { props: { data: JSON.parse(res), dataLog: { pulled: true } } };
  }
  return { props: { dataLog: { pulled: false } } };
};

That way I can fully SSR the page WITH user data. ( I can dynamically horizontally scale my next.js app deployments since they NEVER manage state they JUST render )

How can you just kill such an option?

This feels like intentional lock down.

[HenriqueLimas]

If you have a custom server you can try this approach #42732 (reply in thread)

[tbscode]

Hi, yes thanks saw that already!
I don't think it handles the request body at all all. ( see the body: null part ).

[tbscode]

I've also looked into middleware.js I don't think there exists any good way to pass data from a Middleware to a (app directory) page.
I do NOT consider the following as good ideas:

• setting the whole request body as a query param ( can be too big )
• setting the whole request body as a cookie header ( also can be too big ).

[tbscode]

Ah @HenriqueLimas you are talking about your comment on that answer.
I see yes a custom server could be the solution here, I'll look into it thanks!

[tbscode]

As the way I intend to use nextjs, sadly seems the become unsupported I've been looking around for alternatives.
I found https://vike.dev It allows me to access the request body, and has all features / compatibility I need e.g.: React, Redux, Tailwind, SSR, full static export, Routing. Also allows for pretty fast server customization!

It's https://vitejs.dev/ based & and works pretty well.

[jigs1996]

Any update here please

[msiric]

This can't be real

[BleddP]

Is there also no way to access the req object in client components?
I'm trying to implement something as simple as setting up Rollbar reporting in my app/global-error.tsx and page/error.tsx error handlers, but they require the req object:

 const rollbar = new Rollbar(process.env.ROLLBAR_SERVER_TOKEN)
 rollbar.error(err, req, (rollbarError) => {}

Is this really not possible anymore in the app dir?

I have the feeling I'm overlooking something, but it's frustrating that a simple Rollbar setup, which should take 15 mins, takes hours of spitting through the docs, stack overflow and Github issues..

[mikelieser]

This is wild. I'm playing with NextJS 14.1 App Router for the FIRST day and after 2 hours setting up routes and putting some logic in a page I came up to this issue reading there is no way to access the request object server side with properties like domain or url 🤯 It's super basic stuff in every framework.

My use case: A Blog system where every article does have a SINGLE primary url, to which I want to redirect if the request url differs, due to broken/changed slug, different protocol/domain/optional segments in url, etc. I just want to check request.url === article.url Now I need to construct the hopefully correct request url from params, searchParams and headers like host and x-forwarded-proto. Just give me an request object and the first day of NextJS wouldn't be bad.

Also not nice to read that Rollbar Setup will give me also headache, see #42732 (comment)

[dominic-schmid]

Agreed, I've also run into a need to get the request IP in a page and while middleware.ts could be a workaround on edge runtimes, it's crazy that I can't just access the request object through props or something!

SvelteKit handles this by providing the request object, cookies, etc. inside the load function, which I definitely prefer over importing cookies(), since that is much more error prone for developers.

While I'm at it, I really think the NextRequest object should contain the slug params just like the RSC children. For /profile/[id] I should be able to access an object containing

{
    pathname: '/profile/123456', // <- already exists
    route: '/profile/[id]',
    slug: '123456',
    // ... rest of Request object
}

Instead of having to parse the ID out of the request in a middleware or something.

[rexfordessilfie]

Hello @mikelieser. Did you figure out a solution to your problem?

I wanted to suggest Next.js redirects (or rewrites), but it may or may not be suitable for you. Do you have a concrete example to test and see?

[mikelieser]

@rexfordessilfie

This is my solution. I contruct the article url from headers and params in currentArticleUrl.

import { permanentRedirect, redirect } from "next/navigation";
import { headers } from "next/headers";
import { ReadonlyHeaders } from "next/dist/server/web/spec-extension/adapters/headers";

let baseDomain = `${process.env.PROTOCOL}://${process.env.DOMAIN}`;

function currentArticleUrl(params: any, headers: ReadonlyHeaders) {
  let protocol = headers.get("x-forwarded-proto");
  let host = headers.get("host");
  let articlePath = params.slug.join("/");
  return `${protocol}://${host}/artikel/${articlePath}`;
}

export default function Article({ params }: { params: { slug?: string[] } }) {
 
  // find artice in db
  let article = YOUR_CODE

  // redirect to correct url if not correct
  let currentUrl = currentArticleUrl(params, headers());
  if (currentUrl !== article.url) {
    console.log("url is different");
    console.log("currentUrl ", currentUrl);
    console.log("article.url", article.url);
    permanentRedirect(article.url);
  }

  return (
    <div>
      <h1>{article.title}</h1>
    </div>
  );
}

[harshilAmbliya]

when i use nextjs with node js then i got token in response of login api then how can protect my routes in middleware for user and admin role base access

[shanehoban]

This is mind boggling. I want to access the current request pathname in a server component, why would this not be implemented, or restricted purposefully?

A very common use case for this is to have a structure like this:

/app
  /app
     /page.tsx <-- these are protected as the user is required to be logged in
     /layout.tsx <-- protection for all /app pages can be done here
  /page.tsx <-- these are unprotected routes, a user doesn't need to be logged in etc.
  /layout.tsx

So in my /app/app/layout.tsx as a server component, I want to check that the user is logged in (which works fine) - however, if they are not logged in I want to redirect them to /login with a URL parameter containing redirectTo=THE_PATH_THEY_WERE_TRYING_TO_ACCESS_INITIALLY

Is there some supported or even just advised workaround for this? Thanks!

[XoL1507]

i need some one to dm me maybe can help our company can run fast like others i made.

[leerob]

@shanehoban that doesn't make any sense. Running compute will always be more expensive (regardless of where you deploy your Next.js site) so trying to cache more helps reduce costs.

[XoL1507]

sorry but really my trust is done. same people telling me always. just make things work. i'm really sorry. all of you on this..

[XoL1507]

what really exact want me to do? and can anyone how valued every time i run a software. are this different people even they both on my shelter?

[shanehoban]

That's exactly what I was saying @leerob.

I actually agree with the way it's set up to be honest.

Building SaaS/dynamic web apps etc. would mean none of the internal pages are cached anyway. So having the auth check in the protected route group layout is actually fine. It just takes a bit of workaround as it isn't out of the box. Which on first glance this seems strange is all.

[leerob]

Delba has provided a much more comprehensive response here, including what solutions are available: #43704 (comment)

[tareksalem]

useless library, something very simple like that you don't even offer to developers, how do you claim that you make developer life easier if you are not responding to people suggestions and feedback? I can see ton of valid use cases that require accessing the request object!!!!!!!!