Being able to set session token on parent domain

[SJrX]

We have a setup where we load requests on one domain (e.g., web.domain.com), and then make Cross Origin requests to another domain (e.g., ajax.domain.com). In our development environments the domains point to the same host, but unfortunately the plugin doesn't set the cookie on everything but the most specific domain. In our case, the simpliest thing to do would be to have an option to set it at the level just below the public suffix. (i.e. *.domain.com).

[mac-cain13]

I see that it could be handy, how would you see this working in the interface?

[SJrX]

So I'm not sure at what level a chrome plugin works. Do you just operate within the context of a domain, or is it per page / tab. I'm also somewhat biased to my particular use case, and so might be blind to some of the reprocutions of this. Assuming it is per page / tab then maybe something like this would work:

"By default Xdebug helper will only enable functionality on the domain that is requested. If you are making Cross Origin requests Xdebug will not be triggered. You can override this behavior below setting a pattern [or a regex] for a domain to override the behavior of"

Domain Pattern [ or Regex ](e.g., *.domain.com) | Setting
.domain.com | Only that domain
*.bar.foo.com | First Level Domain
*.zebra.inc | All domains ()

In the first case, enabling XDebug Helper on test.domain.com would cause XDebug to only set the token on test.domain.com.

In the second case, enabling XDebug Helper on test.bar.foo.com would enable it on *.foo.com.

In the third case, enabling XDebug helper on test.zebra.inc would cause it to be sent to google.com.

I think this might be sufficient for most cases. I am on the fence about supplying regular expressions or patterns. Before I learnt regular expressions I hated everything that required them, now I heart them. This also assumes there are no security risks of potentially leaking that key out to the nasty world wide web, which I don't see anything, but haven't really thought about. It also is less workable if it isn't implicitly restricted by only applying to requests made from a particular page (either a direct load, or an XHR). Finally I don't know if Chrome would block you from munging with All Domains (*)

[bubach]

+1
I have sites that i usually access with like localhost:3000 while the api might be local.realdomain.com

If it's possible, I actually think the cookie should be sent on all outgoing requests when turned on. No matter if you switch tabs, have API calls to other domains and so on. Just on and off, not tied to any URL at all.