Setting a header output?

[Lilja]

I'm trying to follow some sort of security "consensus" of not manually setting authentication stuff in the client using javascript, like storing a token from the api response into localStorage and then during a page reload to get and set it in the state of your app.

In a REST context, I'm envisioning a /login endpoint which verifies a JWT-token that is sent from the client as a cookie. In the client, the cookie is never added programmatically to the http-call, as it's a httponly cookie which gets automatically send through the browser and can't be retrieved using javascript.
The way of tRPC is a bit troublesome because there's no way of setting headers. I suppose I could create a Set-Cookie: <cookieName>=<jwtToken> but I don't understand a way to set this in somewhere in a resolve function which would ultimately populate in the browser.

[KATT]

Check the websockets example if you want to see an example with cookie based auth, the cookie can then be picked up in createContext on the server and resolved to a user that is passed through to each resolver.

Cookies are the only way if you want server-side rendering.

If you're making an SPA or a RN-app you can use auth headers which can be picked up from local storage or whatever.

[KATT]

With next you'd do it in the config of the withTRPC()-hook

See the headers option here where you can do a callback that reads from local storage et al.

https://trpc.io/docs/nextjs#withtrpc-options

[KATT]

Here's another reference if you're not using withTRPC() https://trpc.io/docs/react#4-add-trpc-providers

[Lilja]

I looked through your examples but I thinking I'm being misunderstood here.

Imagine this:

const appRouter = trpc.router<Context>().query('/login', {
  input: z.string(),
  async resolve(req) {
    if (!req.ctx["token"]) {
        const headers = {
            "Set-Cookie": `token=${jwtSign(user)}`
        }
        // Where do my headers go?
    } else {
        const user = jwtVerify(req.cookies["token"])
        return `Greetings, ${user.name}`;
  },
});

I guess the problem here is that the output here that is not is supposed to be delivered to the client in the forms of something the user can interact with. Any type changes to the output will have pretty drastic changes downstream.

What if it was possible to import a function from trpc:

import * as trpc from '@trpc/server';
async resolve(req) {
    const user = {"foo": "bar"}
    return trpc.includeHeaders(user, { "X-Super-Cool-Header": "Hola!" })
}
// The return type is still {"foo": "bar"}

and then includeHeaders is a generic function(<T>) which object.assigns the headers but still returns the first argument

I guess you can't really interact with these headers on the client, but maybe that's okay. In my case Set-Cookie is understood by the browser and is set automatically.

[KATT]

You could do something like this:

// in your `createContext` - return a headers obj for resolvers to mutate
export const createContext = async ({
  req,
  res,
}: trpcNext.CreateNextContextOptions) => {
  return {
     headers: {}  as Dict<string>
  };
};

// in your resolver, mutate ctx
async resolve({ctx}) {
    ctx.headers['X-Super-Cool-Header'] = 'Hola!'
}


// in `responeMeta` -- include headers from ctx
export default trpcNext.createNextApiHandler({
  // [..]
  responseMeta({ ctx, paths, type, errors }) {
    return {
      headers: ctx.headers,
    };
  },
});