Auth: Cookies

[Tanja-4732]

This project really needs to support storing and automatically re-sending cookies, just like a browser would.

I'll work on an PR for this:

I'll work on cookies in my fork since you seem to be working on auto-save.

I hope to have some progress by the end of the week; will (hopefully) open a draft-PR until then

Originally posted by @Tanja-4732 in #385 (reply in thread)

Tasks

• Basic Cookie Support
• CLI Support
• Delete a cookie in UI
• Edit a cookie in UI
• Add a cookie in UI
• Add a new domain/url in UI

[nu111]

I am trying to move away from Insomnia or Postman, I would like to try Bruno, but I can't without cookies. I'd love to see this feature!

[solsticesurfer]

+1 on cookie support. It's the only thing preventing my team from dumping Postman and moving over to Bruno. Far too many systems rely on a session cookie as part of their authentication flow.

[chriswinter90]

+1 for many at our company. We use sessions on some of our node apps and the session id changes every time because the cookie is not saved causing a new session each time so no user info is persisted.

[Tanja-4732]

Yes yes 😊 I'll try to get started on this till about Monday,
though I'm not very familiar with the codebase yet

[joe-gre]

I'm trying to get cookie based auth working, but I don't think its sending the cookie header. Here is what I have in the Headers tab, which works in Postman but not Bruno:

I tried setting the session cookie to valid string literal session ids too, both encoded and not encoded. Same issue.

Also FYI this is what I have in the post script to decode the cookie response and set it as a context var. This part is working well.

const header = res.getHeader("set-cookie")?.[0];
if (!header) return;

const session = header.substring(
  header.indexOf("=") + 1,
  header.indexOf(";")
);
bru.setVar("session", decodeURIComponent(session));
console.log(`session: ${bru.getVar("session")}`)

[joe-gre]

I see that it is sending the cookie header actually. But its not sending it as a signed cookie like it is in Postman. Unfortunately this is a blocker for our team's adoption of Bruno. I've been waiting for an API client that saves collections to file systems. I hope this feature gets added so we can migrate.

[joe-gre]

I'm trying to get cookie based auth working, but I don't think its sending the cookie header. Here is what I have in the Headers tab, which works in Postman but not Bruno:

I tried setting the session cookie to valid string literal session ids too, both encoded and not encoded. Same issue.

Also FYI this is what I have in the post script to decode the cookie response and set it as a context var. This part is working well.

const header = res.getHeader("set-cookie")?.[0];
if (!header) return;

const session = header.substring(
  header.indexOf("=") + 1,
  header.indexOf(";")
);
bru.setVar("session", decodeURIComponent(session));
console.log(`session: ${bru.getVar("session")}`)

I got this working by changing the auth type to "No Auth". Now authentication works!

[Tanja-4732]

So far, I've added a button for a cookie tab, which is yet to be implemented:

[Tanja-4732]

I've been waiting for an API client that saves collections to file systems

Same, but we seemingly all need cookie support for this to be of basically any use.

I think I may have some form of this available within the next week, provided I find the time.

See #969 for details

[Tanja-4732]

More good news:

We now have a basic cookie tab;
But the under-the-hood features/implementation is not yet here

[Tanja-4732]

Basic cookie store works now

However, I've yet to implement sending them along automatically.

---

Notice, how the login now correctly sets the session_token collection-wide in the example below:
(but #969 still needs to be merged first)

[Tanja-4732]

Update:

It works 🎉

My fork on branch feature/cookies now has out-of-the-box cookie support 🎉

[Tanja-4732]

Someone please review #969

[joe-gre]

Thanks cookie authentication is working well!

[Tanja-4732]

Well, while my fork https://github.com/Tanja-4732/bruno/tree/feature/cookies worked very well for my usecases,
there are isssues:

Mostly related to the fact that I did cookies per-collection, whereas @helloanoop wanted them app-wide, and I forgot to consider host names, as I only developed against one API server.

See this discussed in #969 (comment)

---

All in all, my PR #969 seems very dead rn, but at least my work may have showed that cookie support is important enough to be implemented sooner than planned originally 🤷‍♀️

So @joe-gre, your

Thanks cookie authentication is working well!

may actually reference e1a96e0 rather than my #969

---

Thanks again for all the 🎉s, ❤️s, and the 👍s, I really appreciate them 😊

[DrGrognon]

Hello , Thanks a lot for the work and this really promising Bruno 🐕

If found something annoying with cookie that i think may be of interest for implementer
A feature that would be helpfull with cookie support, would be ability to disbale cookie jar at a request or collection level.

My really annoying use case: When doing CSRF mitigation by the use of double submit cookie ( good explanation here ) , if cookie are auto set and cannot be disabled, this make CSRF handling mandatory.

If one can just disable the cookies, no more cookie no more CSRF, no more problem 😄

FYI functionnality look like that in postman:

I think i can work around for now, but this is the cherry on the cake that could allow me to convince my team to throw Postman to garbage and go with the dog 🍒

[helloanoop]

@DrGrognon You can conditionally disable cookies in v1.3.0

[DrGrognon]

@helloanoop I just tried it, and it do the job perfectly 😃 !
I'm really pleased to see such good momentum and spirit around Bruno,
Thanks a lot and keep going 🐶 ❤️

[r-polunin]

Thank you for your cookie feature support, as it is really mandatory for my company.
Unfortunately current implementation does not cover my case:

If we have a chain of requests, i.e: request -> 302 re-direct -> 302 re-direct -> page.
Cookies from the first re-direct response are not propagated further.

In my case I have a POST request with auth params as a first step where correct cookies with authorized JSESSIONID are set, but they are lost after following re-direction with 302 code and overwritten by newly set JSESSIONID without auth from the target page.

curl handles such request properly with --cookie-jar, postman handles it OOB, would be great if Bruno could support such case too.

[lltr]

Was looking at the docs trying to copy a cookie from the browser over to Bruno to test but couldn't figure out a way to and realized that there isn't a way to do it. Hopefully this will be added soon enough so I no longer need to use Postman as it is essential to my current workflow.

[r-polunin]

I had a free weekend to dive a little deeper:
@lltr I've added a capability to set cookies manually in the fork: https://github.com/r-polunin/bruno/tree/cookies-for-redirects
You can try to use this one, while we wait for official version of the feature :D
(It doesn't show Secure, HttpOnly etc. property yet and I don't promise stable behaviour, but it worked for me, possibly it will cover your cases too)

@helloanoop, regarding my previous comment:

If we have a chain of requests, i.e: request -> 302 re-direct -> 302 re-direct -> page.
Cookies from the first re-direct response are not propagated further.

This happens because of the way how axios works:
axios/axios#3862
I've raised a pull request to merge a workaround for this one:
#1463
Could you please comment on the changes?

[zFlxw]

Hi. First of all, thanks for your contribution, cookies are pretty much the only feature I really need and that prevented me from switching to Bruno. I got a bit confused, so I may ask if anyone can tell me what the current status of the cookie implementation is? I assume it has not officially been merged, but how profound is the current implementation?

[kizilcali81]

Hi. Thank you all for this awesome feature. This was really important for us. @helloanoop Is there any chance that we see the cookie support also in Bruno CLI any time soon? It is a bit annoying that we can not run our tests in the CLI the same way as we do with the collection runner.

[Goufoux]

Hello, thanks for the feature, like kizilcali81, i asking if the feature should be avaiable in the cli too ?

[brad]

As a workaround I'm turning off the automatic cookie handling in preferences as mentioned here and then I run req.setHeader("Cookie", '{{cookie}}') in the pre request script

[Infinitay]

Is it possible to do something similar to Insomnia where you can set the authorization header to Cookie <cookie_key> directly into the headers field without scripting? I've tried things like like Cookie {{<cookie_key>}} Cookie {{headers.cookie.key}} Cookie {{cookie.key}} Cookie {{req.cookie.key}} Cookie {{request.cookie.key}} and I even tried replacing the Cookie auth type to Bearer and nothing worked.

[FallenHero66]

where you can set the authorization header to Cookie <cookie_key> directly into the headers field without scripting

I'm not sure if I understood your request correctly, but I assume you'd like the following header in your request:
Authorization: Cookie <cookie_key>

If that's correct, here's how to achieve this:

1. Choose Auth "No Auth"
2. Add Header with name "Authorization" and value "Cookie {{cookie}}"
3. save your cookie value into the environment variable named "cookie"

To my knowledge, what's not possible without scripting at the moment is feeding a cookie value directly into a variable, though.

[so-jelly]

i need to add cookies for a top level domain. it seems this is not happening.

1. login.example.com -> get cookie for example.com
2. site.example.com -> does not apply example.com cookies

[VesperQuartz]

It doesnt work