Cookies are always base64 and JSON encoded

[hugo]

At present, the cookie utilities always encode (and expect to decode) a base64, JSON value, using the encodeCookieValue/decodeCookieValue functions. This is fine when the cookie is only being read in Remix loaders, actions, etc. If you wish to interact with the outside world it becomes a problem for a couple of reasons:

1. You cannot read a cookie created elsewhere using the parse method of a Remix cookie. For example, if you are on a subdomain and want to read a cookie set at the domain root.
2. Any reader of your cookie has to decode the value. For example, if you are setting a non-HttpOnly cookie to be read in JavaScript client side, or by some other system (say, a load balancer).

It would be helpful if I could read/write both cookies created by Remix, and "raw" cookies using the same interface. The underlying cookie interface takes an encode/decode function in the options of the serialize/parse methods. This would help follow the advice from the docs to put all your cookies in a app/cookie.js file.

My first thought is that Remix could, by default, not do anything extra to the cookie and add an extra helper createJsonCookie which prebakes the btoa(JSON.stringify(x))/JSON.parse(atob(x)) encode/decode functions. (And maybe changes the options to Omit<CookieSerializeOptions, 'encode'>/Omit< CookieParseOptions, 'decode'>.) This would also prevent the (potentially) surprising behaviour if a user were to specify encode/decode themselves where the value passed to these functions would already have been modified.

[martinemmert]

Hey there 👋

I am currently implementing server-side authentication with Supabase and have run into this issue.

Challange

• Users receive an account confirmation link via mail after creating a new account
• The link sends the user to the backend of Supabase to activate their account
• Supabase redirects to my website with two cookies that can use to establish a user session

Using the default CreateCookieFunction of remix did not return anything since it assumes what @hugo already mentioned.

// decodeCookieValue
async function decodeCookieValue(unsign, value, secrets) {
  if (secrets.length > 0) {
    for (let secret of secrets) {
      let unsignedValue = await unsign(value, secret);

      if (unsignedValue !== false) {
        return decodeData(unsignedValue);
      }
    }

    return null;
  }

  return decodeData(value);
}

Current solution

I implemented my own createCookie function to bypass this behavior and use it for "foreign" cookies.

// create-foreign-cookie.server.ts
import type { CookieParseOptions, CookieSerializeOptions } from "cookie";
import { parse, serialize } from "cookie";
import type { CreateCookieFunction } from "@remix-run/server-runtime";

export type { CookieParseOptions, CookieSerializeOptions };

/**
 * Creates a logical container for managing a browser cookie from the server.
 *
 * @see https://remix.run/api/remix#createcookie
 */
function createCookieFactory(): CreateCookieFunction {
  return (name, cookieOptions = {}) => {
    const { secrets, ...options } = {
      secrets: [],
      path: "/",
      ...cookieOptions,
    };

    return {
      get name() {
        return name;
      },
      get isSigned() {
        return secrets.length > 0;
      },
      get expires() {
        // Max-Age takes precedence over Expires
        return typeof options.maxAge !== "undefined"
          ? new Date(Date.now() + options.maxAge * 1000)
          : options.expires;
      },
      async parse(cookieHeader, parseOptions) {
        if (!cookieHeader) return null;
        let cookies = parse(cookieHeader, { ...options, ...parseOptions });
        return name in cookies ? (cookies[name] === "" ? "" : cookies[name]) : null;
      },
      async serialize(value, serializeOptions) {
        return serialize(name, value, {
          ...options,
          ...serializeOptions,
        });
      },
    };
  };
}

const createForeignCookie = createCookieFactory();

export default createForeignCookie;

// cookies.server.ts
import createForeignCookie from "~/lib/create-foreign-cookie.server";

export const sbRefreshTokenCookie = createForeignCookie("sb-refresh-token");

[machour]

Converting this to a Proposal discussion, as per our Development Process.

[nphmuller]

This just bit me. I was trying to read a cookie set by another application in Remix and .parse just returned {}. After diving into the code I noticed that the cookie implementation only support json values.

It would have saved me a lot of trouble if this was documented here: https://remix.run/docs/en/main/utils/cookies

[ikarus-pritish]

I agree with @nphmuller. I also got stuck on this issue recently. It will be great if this can be documented @machour

[machour]

Feel free to make a pull request on main to amend the documentation 🙏

[nboliver-ventureweb]

It looks like cookie.serialize has a second parameter that isn't documented, where you can encode the cookie however you want.
For example:

export async function action({ request }: ActionFunctionArgs) {
  const bodyParams = await request.formData();
  const redirectUrl = bodyParams.get('redirectUrl');
  const entries = Object.fromEntries(bodyParams);
  delete entries.redirectUrl;
  const values = Object.values(entries);

  return redirect(typeof redirectUrl === 'string' ? redirectUrl : '/', {
    headers: {
      'Set-Cookie': await consentCookie.serialize(values, {
        encode: c => atob(c),
      }),
    },
  });
}

cookie.parse has a matching decode, but that doesn't seem to work properly - it just returns an empty object, as @nphmuller noted.
For example:

const savedCookieConsent = await consentCookie.parse(request.headers.get('Cookie'), {
  decode: c => {
    // Logs expected string value
    console.log(c);
    return c;
  },
});

 console.log(savedCookieConsent); // {}

[vinczebalazs]

Warning: If you override encode you also loose the signing of the cookie, unless you implement it in the returned function.

[dasblitz]

Also ran into this. We're setting a language cookie like: language=en. For quite some time our site will be a mix of pages that use remix and pages that are still on a php stack. Both stacks need to be able to read the language cookie.

[suhaotian]

You can just:

const headers = new Headers();
headers.append('Set-Cookie', 'language=en');

return json({text: 'some data'}, {
   headers
})

[dasblitz]

@suhaotian ah of course, sometimes I forget it's just a regular http response 😅 Still it would be nice if the Remix utils for cookies could be used for this as well :)

[leodutra]

Sometimes, it's just a bit more complex than this. I have the same case with max age and path. encode and decode should be completely overrideable.

[burgaard]

I ran into this earlier this week. We've been using the Remix created cookies with the front-end code without any issues, so it took me a while to suspect cookie.parse was the culprit when I always got empty objects back when trying to read cookies set by a different server.

I think it's unseasonable to assume all cookies should be base64 encoded JSON strings. Either way, it would have been helpful if the documentation had clearly spelled out this implementation choice.

[Coimbr]

---

[leodutra]

Is there any Remix solution to this so far, besides using the commented utility (createCookieFactory)?