COOKIE_ syntax doesn't work with cookie names containing hyphens

  1. My goal: Use the COOKIE_ substitution syntax to automatically pass a browser cookie value into the Authorization header of a REST API request. The cookie name is mycookie-staging and needs to be sent as Authorization: Basic <cookie_value>.
  2. Issue: The COOKIE_mycookie-staging syntax is not being substituted with the actual cookie value. When I use Authorization: Basic COOKIE_mycookie-staging in the Headers section, the request fails with a 401 Unauthorized error. However, when I manually paste the cookie value instead of using COOKIE_, the request succeeds.
  3. What works:
    • Cookie without hyphen: mycookie → COOKIE_mycookie

    • Manual value: Authorization: Basic xxx

    • Same curl request with the cookie works perfectly

    1. What doesn't work:
    • COOKIE_mycookie-staging

    • COOKIE_mycookie_staging

  4. Retool version & hosting setup: Self-hosted v3.300.4-stable on K8s

Hi @Nikita_Khalezin,

That is very interesting that Cookie without the hyphen does work. Seems like this may be a bug that I can report to our engineering team.

Does cookie without a hyphen work for your use case or do you need to find a work around?

Hi @Jack_T,

In our case, we use different cookie names per environment:

  • production → mycookie

  • staging → mycookie-staging

Because of this, everything works fine in production (since COOKIE_mycookie is correctly substituted).

However, in staging, the substitution does not work with COOKIE_mycookie-staging, so the Authorization header is not populated correctly.

As a workaround, we currently have to manually copy the value from mycookie-staging into a mycookie cookie in the browser. Only after that does COOKIE-based auth work in Retool.

So yes, we found a workaround, but it is quite inconvenient and error-prone. It would be great if support for hyphenated cookie names in the COOKIE_ substitution syntax could be fixed.

Thank you for elaborating @Nikita_Khalezin,

I can definitely make a ticket for our engineers to take a look at this.

I will let you know if we have any ideas for work arounds in the short term as well :+1: