Setting the cookie domain when using the proxy option

[peregrinator]

This may be a documentation issue but I haven't been able to find the right way to do this.

For one of our systems we use a shared authentication mechanism via cookies. When not signed in the user is directed to the application with the authentication responsibility. On successful authentication a cookie is set on the shared root domain (each app exists on a subdomain). For example the authentication app would live at authentication.example.com and would set cookies with a domain of .example.com such that all subdomains could access it.

When using browsersync via the proxy an additional cookie is being set on the subdomain (authentication.example.com in this scenario). This causes issues in a number of cases - how would we go about telling browsersync to either use a different domain (or to not set cookies - not sure what browsersync is using cookies for in this case)?

Thanks!

[peterscottbrownstein]

+1

[peregrinator]

Any recommendations on a workaround for this? We've stopped using browser sync as this is a blocker for us right now.

[peterscottbrownstein]

I am not sure if this will help at all, but what fixed our issue was to use middleware to change what browsersync was using as a proxy server. I ended using "http-proxy" that was recommended in this thread: https://github.com/BrowserSync/browser-sync/issues/471#issuecomment-75646705

Once I did that 'http-proxy' was now in charge of proxying browsersync, and it solved our issue. As some background, our issue was that the built-in proxy for browsersync was not passing the authentication cookie's domain properly. So normally, I am proxying local-dev.examplesite.com through browser-sync.examplesite.com. When I use local-dev.examplesite.com to log in, the authentication cookie domain is set to .examplesite.com, which is vital when communicating with our api (local-api.examplesite.com). However when I ran browsersync, and it opend up through browser-sync.examplesite.com it would set the cookie's domain to browser-sync.examplesite.com, which caused issues with our api. Once I switched to the 'http-proxy', it seemed as if it properly passed through the cookie with the correct domain of .examplesite.com.

Hope it helps, or at least puts you on a path to an idea that may help.

[peterscottbrownstein]

Turns out I just needed to do a little more searching and find a different solution to my problem. Instead of using middleware, I found the ability to set "stripDomain" to false for the proxy that is built into browser-sync (it appears to be using foxy).

So instead of setting the proxy option to

proxy: "local-dev.examplesite.com"

I was able to set it to:

proxy: {
   target: "local-dev.examplesite.com",
   cookies: { stripeDomain: false }
}

Once I did this, and removed the middleware that was using http-proxy, my cookies were passing through the correct domain.

Sorry...this probably doesn't help you, but I wanted to at least close the loop on the problem I was having.

[peregrinator]

Peter your problem sounds very similar to ours in fact. I'll give your stripDomain setting a try as soon as I have a chance. Thanks for sharing!

[peterscottbrownstein]

Sure no problem, I hope it works out for you. If not you could always look into foxy and see if there are more options, or potentially go the middleware approach for even more control. Good luck!

[scraton]

This worked for me. Although there's a typo in the code posted which made me initially think it didn't work. Should be:

proxy: {
   target: "local-dev.examplesite.com",
   cookies: { stripDomain: false }
}

Thanks for doing your part and following up with your solution @peterscottbrownstein! Really appreciate it! :)