feat(example): Add Nosecone example with custom router

[davidmytton]

Created to help with #2639 so making this an official example.

[trunk-io]

✨ Submitted to Merge by David Mytton (@davidmytton). It will be added to the merge queue once all branch protection rules pass and there are no merge conflicts with the target branch. See more details here.

[socket-security]

New dependencies detected. Learn more about Socket for GitHub ↗︎

Package	New capabilities	Transitives	Size	Publisher
npm/@eslint/[email protected]	filesystem, unsafe Transitive: environment	+3	919 kB	eslintbot
npm/@types/[email protected]	None	0	2.22 MB	types
npm/@types/[email protected]	None	0	790 kB	types
npm/[email protected]	Transitive: environment, eval, filesystem	+79	8.36 MB	timer, timneutkens, vercel-release-bot
npm/[email protected]	environment, filesystem, network, shell, unsafe	+10	1.27 GB	vercel-release-bot
npm/[email protected]	None	0	55.2 kB	blakeembrey
npm/[email protected]	environment, filesystem	+5	8.6 MB	adamwathan, malfaitrobin, reinink

View full report↗︎

[socket-security]

🚨 Potential security issues detected. Learn more about Socket for GitHub ↗︎

To accept the risk, merge this PR and you will not be notified again.

Alert	Package	Note	Source	CI
Unstable ownership	npm/[email protected]	Author: ljharb	examples/nosecone-nextjs-router/package-lock.json examples/nosecone-nextjs-router/package.json	🚫

View full report↗︎

Next steps

What is unstable ownership?

A new collaborator has begun publishing package versions. Package stability and security risk may be elevated.

Try to reduce the number of authors you depend on to reduce the risk to malicious actors gaining access to your supply chain. Packages should remove inactive collaborators with publishing rights from packages on npm.

Take a deeper look at the dependency

Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev.

Remove the package

If you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency.

Mark a package as acceptable risk

To ignore an alert, reply with a comment starting with @SocketSecurity ignore followed by a space separated list of ecosystem/package-name@version specifiers. e.g. @SocketSecurity ignore npm/[email protected] or ignore all packages with @SocketSecurity ignore-all

• @SocketSecurity ignore npm/[email protected]

[davidmytton]

@blaine-arcjet could you review my fix in #2639 (comment) please? Seems like we should handle redirects and auth errors by just returning the response, but that might leave the security headers unset.

[blaine-arcjet]

Is there a reason we can't add the headers to returned response before returning it from the middleware?

It looks like the implementation for NextResponse.redirect() isn't complex:

static redirect(url, init) {
        const status = typeof init === "number" ? init : (init == null ? void 0 : init.status) ?? 307;
        if (!REDIRECTS.has(status)) {
            throw new RangeError('Failed to execute "redirect" on "response": Invalid status code');
        }
        const initObj = typeof init === "object" ? init : {};
        const headers = new Headers(initObj == null ? void 0 : initObj.headers);
        headers.set("Location", (0, _utils.validateURL)(url));
        return new NextResponse(null, {
            ...initObj,
            headers,
            status
        });
}

So we could return a Response instantly that sets the status code & Location header.

Also, to make this resilient, we probably want to handle NextResponse.rewrite(), which looks like it sets a different header than NextResponse.next():

static rewrite(destination, init) {
        const headers = new Headers(init == null ? void 0 : init.headers);
        headers.set("x-middleware-rewrite", (0, _utils.validateURL)(destination));
        handleMiddlewareField(init, headers);
        return new NextResponse(null, {
            ...init,
            headers
        });
}

[davidmytton]

Ideally we'd add the headers to all responses. So this is really about extending how we handle the redirect and rewrites to make sure they're captured correctly.

[davidmytton]

@blaine-arcjet could you add this to the code when you get a chance please? You'll do a better job than me at this!