[Feature] read cookie values in middleware

[witsch]

Hi! First off, thanks for Barbacane — we've been running it in production for a (still short) while now as a validating gateway in front of a PostgREST API, and it has been a pleasure to work with. Compiling the OpenAPI spec into the artefact and having the contract be the routing table turned out to be exactly the model we wanted.

As for this feature request, I've only seen your template after writing it down, but I'm happy to reorganize it if that helps.

The gap

Middleware currently has no way to read a single cookie. As far as we can tell:

• request-transformer interpolates $header.<name>, $query.<name>, $path.<name>, $client_ip and context:<key>, but nothing for cookies — and $header.cookie gives the whole header, with no way to pick one value out of it.
• cel can match on request.headers.cookie, but on_match.set_context only writes literal strings, so the matched value cannot be carried anywhere.

So anything of the shape "take a value out of Cookie and put it somewhere else" is currently out of reach.

Our use case, generically

Browser clients authenticate with an SSO cookie; the API behind the gateway expects a bearer token. Something has to translate:

Cookie: sso_token=<jwt>   →   Authorization: Bearer <jwt>

with the incoming Authorization header taking precedence when it is already set. That is a handful of lines in Nginx, and it is the single reason we still run an Nginx sidecar behind Barbacane rather than letting the gateway talk to the backend directly. We suspect cookie-to-header translation is common wherever a browser-facing API sits behind a gateway — session cookies, CSRF tokens, tenant hints.

Possible shapes

Either would solve it for us; the first looks smaller:

1. A $cookie.<name> variable in request-transformer, alongside the existing ones:

   - name: request-transformer
     config:
       headers:
         set:                                  # `set` = only when absent
           Authorization: "Bearer $cookie.sso_token"

   set already gives us the precedence rule for free, and an unresolvable variable already yields an empty string.

2. A small cookie-to-header middleware, if you would rather keep cookie parsing out of the transformer — mapping named cookies onto headers, with a flag for whether to overwrite.

A cookie map on the CEL request context would work too, though it only helps if set_context can pass a captured value along.

Happy to test a build against our setup if that is useful, and thanks either way! 😊

[ndreno]

Hi there, great to see you like it so far and you're running it in prod!!

We'll have a look as soon as we finish this iteration focused on the WAF feature (please check it if you have time you may like it a lot ;))

[ndreno]

hey @witsch can you give a try with the v0.10 please?

[witsch]

hey @witsch can you give a try with the v0.10 please?

Hey Nicolas, this is awesome, thank you! 😊 I'll happily try it, but I'm afraid I can't before next week. I'm on vacation this one (and don't have access anyway). It does look just like what we need and I'm looking forward to trying it out when I'm back… Sorry for making you wait! 🫣

[ndreno]

no rush, all good :-) enjoy your vacations

[ndreno]

hey mate, did you get the chance to update it? Since we've been added explicit headers declaration, so be carreful if your OAS is not reflecting them. Check the changelog for more info

[witsch]

Hey Nicolas, last week was pretty busy (after a small incident), but yes, we've now had a chance to test it. So your timing is great… 😊

We're running 0.12.2 now (after fixing the spec 😊) and $cookie.<name> does what we hoped: the documented Authorization: "Bearer $cookie.sso_token" picks our SSO cookie up and the token reaches the backend.

However, there's still one small problem and I'll paste the description Claude has written up for me:

---

We can't drop the nginx sidecar yet, and it comes down to one thing: nothing can skip a set whose value interpolates to empty.

Our nginx prefers a usable Bearer in Authorization, falls back to the SSO cookie, and otherwise sends no header at all. That last case is the problem — with

headers:
  set:                                  # set = only when absent
    Authorization: "Bearer $cookie.sso_token"

an absent cookie resolves to an empty string, so every anonymous request leaves the gateway carrying Authorization: Bearer . PostgREST answers 401 PGRST301 "Empty JWT is sent in Authorization header", so anonymous traffic — most of ours — would break. It is happy to treat null or other junk as anonymous; only the empty bearer is an error, which is why our nginx config is shaped the way it is.

Measured against 0.12.2, as the upstream sees it:

Authorization in	Cookie in	nginx	set
–	–	(none)	Bearer
Bearer tok	–	Bearer tok	Bearer tok
Bearer tok	sso_token=ck	Bearer tok	Bearer tok
–	sso_token=ck	Bearer ck	Bearer ck
–	sso_token=	(none)	Bearer
–	other=ck	(none)	Bearer
Bearer	sso_token=ck	Bearer ck	Bearer
null	sso_token=ck	Bearer ck	null

The interesting column is the last one: the three Bearer rows are the blocker, the two malformed-Authorization rows a nicety we could live without.

So what would unblock it is small: skip a set/add whose value interpolates to empty — as the default for set, or behind something like skip_if_empty: true if you'd rather not change existing behaviour. A general conditional would of course cover it too, but we don't need one.

We did look for a way around it first, without luck: cel can match on the cookie, but on_match.set_context takes literal strings, so it can't carry the captured value over to the transformer; and header operations run add → set → remove → rename, so remove-then-set is out as well.

---

I'd be happy to test a build against our setup — we have the whole matrix above as a test suite, so it's quick. And glad to open this as a separate issue if you'd prefer to keep this one closed… 😊

[witsch]

Hey Nicolas, the tab was still open and I noticed the mention so I let Claude give it a go… 😊 Here's its response:

---

Tried it — built request-transformer from the #245 branch and ran it on a 0.12.2 gateway. skip_if_empty does exactly what we needed.

The case that blocked us was an anonymous request: with an absent cookie the value interpolated to Bearer and PostgREST answered 401 PGRST301 "Empty JWT", so logged-out traffic broke. That is gone. With

- name: request-transformer
  config:
    skip_if_empty: true
    headers:
      set:
        Authorization: "Bearer $cookie.sso_token"

the matrix against our nginx, as the upstream sees it:

Authorization in	Cookie in	nginx	skip_if_empty
–	–	(none)	(none) ✅
–	sso_token=ck	Bearer ck	Bearer ck ✅
–	sso_token=	(none)	(none) ✅
–	other=ck	(none)	(none) ✅
Bearer tok	–	Bearer tok	Bearer tok ✅
Bearer tok	sso_token=ck	Bearer tok	Bearer tok ✅
Bearer	sso_token=ck	Bearer ck	Bearer
null	sso_token=ck	Bearer ck	null

Six of eight match exactly. The two that differ are the ones where a malformed Authorization arrives alongside a valid cookie: our nginx map prefers a usable Bearer and otherwise falls back to the cookie, so it recovers; set keeps whatever arrived. Of those only the Bearer row has teeth, since PostgREST treats null as anonymous but an empty bearer as an error.

That is not a blocker for us — those two are defensive cases in our test suite rather than traffic we have actually seen — and it is not something I would ask you to solve. Expressing "prefer a usable credential, else the cookie" needs a notion of validity, which is well outside a transformer. For the record, we did try remove + set + add now that the ordering is documented, and it produces exactly the same result, so plain set is the configuration.

One small thing while testing: I first put skip_if_empty under headers rather than at the top level, and it was accepted and silently ignored. The root of the config schema has additionalProperties: false, but the nested headers / querystring / body objects do not, so E1023 cannot catch a key in the wrong place — it just compiles and behaves as before. Tightening those three would turn a confusing runtime non-effect into a compile error.

Thanks again, and for the ordering clarification in the docs too — that answered a separate question we had. Happy to run anything else against our setup; the matrix above is a script now.

[ndreno]

Nice, thanks for the digging, I will indeed reinforce the json schema, I miss that one, my bad, maybe I need a json schema for my json schema 😅

Once I've done this tiny addition, I can cut a new release if that's fine for you?

[witsch]

Once I've done this tiny addition, I can cut a new release if that's fine for you?

Forget to send it before, but yes, that would be great! 😊