0

I have APIs deployed in 2 separate namespaces, admin.abc.com (original) and api.admin.abc.com (new). Upon completing login, a jwt cookie is set by the admin.abc.com site for .admin.abc.com. The cookie is for the Session, Secure and HttpOnly and it does not have any SameSite restrictions set. This cookie works well for all API calls to admin.abc.com.

Due to some new changes requiring some services to deployed separately, there are now services also deployed in the namespace api.admin.abc.com. I have a status page that gives me information about the services, memory, etc. and it works fine for the original namespace. But when I add in a status call to the second namespace, no cookies are passed along and the call fails authentication. However, if I open the URL in another tab in my browser, the cookies are passed to the backend and the call succeeds.

I've looked into setting my own cookies in the header during the request after retrieving the jwt's value. This fails for 2 reasons: 1) I don't believe I can access the jwt's value as the cookie is HttpOnly, and 2) I can't set a cookie in the HttpHeader options. I get a "Refused to Set Unsafe Header" error in the console if I try. If I turn on 'withAuthorization:true', it does set it (but still prints the error) and then actually gets a CORS error.

If I manually disable the HttpOnly flag on the cookie using EditThisCookie extension, the calls work successfully. I don't really think it's an option for me with my company's security, but it technically works.

I know some suggest sending the jwt as an Authorization: Bearer token, which I would do, but because the cookie is HttpOnly, I can't retrieve the value and programmatically set it. Additionally there is another site-wide cookie I'd like to send over at times that I can't really switch to some custom header.

Thoughts on what I can do? Is it not possible? My only other option is that all requests to the new namespace have to be routed through an API built in the old namespace.

DFW
  • 805
  • 1
  • 8
  • 18
  • 1
    "admin.abc.com" and "api.admin.abc.com" are **not** the same domain. – Pointy Apr 28 '22 at 23:30
  • They are on the same domain, just are different subdomains, aren't they? Either way, the cookie is set at a broader domain level and applies to both. – DFW Apr 29 '22 at 15:40
  • Are you explicitly setting the domain to "admin.abc.com" in the set-cookie header from the main site? If not, the cookie will be a "host only" cookie, and it won't go to the subdomain. If you can't do that because of that "unsafe" problem, then I don't have a clue as to a solution. – Pointy Apr 29 '22 at 16:16
  • Also [see this other answer to a similar question](https://stackoverflow.com/a/23086139/182668) – Pointy Apr 29 '22 at 16:18
  • In the Java backend code that sets the cookie on the response, I see that it's set to "admin.abc.com". Similarly, when I look a the cookie in the DevTools -> Application -> cookies, I see that domain set. So I think it is, but my guess is now that the browser considers it a different subdomain and doesn't pass along the cookie. However, when pasting "api.admin.abc.com" in the browser, it's the same domain and it passes it along. – DFW Apr 29 '22 at 20:32
  • I would suggest using the browser "Network" developer tool to look at what your server is actually sending the client when setting the cookie. – Pointy Apr 30 '22 at 03:11

0 Answers0