Setting cookie domain

We recently upgraded from version 2019.9.8 to 2020.2.14. We have a custom page that uses the API and authenticates using the “integrated-challenge” endpoint. In order for it to work properly, we had set the domain of the cookie so that the API could access the cookies to send the proper CRSF tokens.

The following issue had allowed us to do that.

Has this feature been removed?

Hi @bbeard,

Thanks for getting in touch! As far as I’m aware this feature has not been removed. I have just had a look on my VM running the same version as you and can confirm the feature is present.

Are you unable to locate the feature currently, or experiencing some issue with it?

If you have any questions at all here, please don’t hesitate to let me know.

Best regards,
Daniel

You are correct – the setting is there, but it doesn’t appear to actually work. The “Set-Cookie” header does not include the domain we have configured here.

Somewhat related, the response from the “integrated-challenge” endpoint (which sets the cookie) doesn’t include the “Access-Control-Allow-Origin” header anymore – even though we have the “CORS Whitelist” configured as “*”.

Hi @bbeard,

I’m just spinning up a repro environment to test this now - I’ll circle back shortly with my findings. We did recently make some changes in this area to account for the Chrome 83 Download issues, so there may have been a regression here.

I’ll test this and get back to you ASAP!

1 Like

Justin,

Were you able to test this issue?

Thanks,

-Brian

Hi @bbeard!

I was able to test part of it, with the cookie domain setting working correctly with the Octopus web portal. This gave the normal “blocked cookies” message because it couldn’t find a matching cookie domain.

I’m still digging into the integrated-challenge endpoint element, but I suspect this may have been a regression due to our AD authentication changes when we re-engineered Octopus for net core, back in 2020.1. I’ll be in touch with more details as they come to hand.

Hi Justin,

Hm. So the Cookie Domain setting worked properly for you? Do you have any ideas why it might not be working for us?

We have some old PowerShell code which is also using the “integrated-challenge” endpoint. It has had some issues as of our last update (2020.1.18). Hitting that endpoint throws a 500 server error yet it still seems to get the cookies required for subsequent API calls. We are working to implement a workaround but I ran into this post and it seemed very related.

@Rob_Pleau

That might be related to the Access-Control-Allow-Origin header not being sent (which we are running into as well). Do you have a CORS Whitelist setup?

Hi @Justin_Walsh

I did a bit more testing, and found that the issue is specific to the /integrated-challenge endpoint.

If I login using the form (/api/users/login endpoint), the cookie is set properly using the value from the Cookie Domain setting. If I log in using the “Sign in with a domain account” button, it doesn’t set the domain on the cookie.

Can you try to reproduce the issue using this other login method?

Hi @bbeard

We don’t have any policy set on the Octopus Server for CORS. I believe given that and what I’ve read in the documentation we’re setup to whitelist all domains.

In addition the Octopus Server and the client(s) making this request are in the same domain. So I think it wouldn’t matter? Sorry, I am admittedly not a web server expert when it comes to CORS :smile:

What is somewhat odd for us is using Windows PowerShell 5.1 with Invoke-WebRequest we are getting a 500 error, but even with the error the session returned has 3 cookies in it, one of them being the CSRF token.

Hi Brian,

We were able to see some strange things happening with the AD integrated auth and custom cookie domains today (even without CORS in the picture). It appears we set the cookie of the site initiating the request, not the custom cookie domain setting, so we need to do some more digging next week to figure out what’s going on here.

We reviewed the code today, and can’t see any regressions from that previous issue you mentioned, so there’s something strange going on that we need to debug further.

This is listed as a priority for the engineers and we’ll continue investigations next week. Once we have a better handle on what’s going on, we’ll raise the appropriate issue and report back.

Thanks for your patience.

Cheers
Mark

1 Like

Hi Brian,

We have investigated this some more and it seems like there are a few things that we missed while migrating things over to .NET Core some time ago. As you have noticed, we have missed some properties such as the cookie domain among others in our AD extension.

We have also noticed that the extension hosts a separate endpoint, which means that some of the settings such as those from CORS aren’t automatically being applied here. Fixing the CORS issue will most likely require some more time to fix, however we think we do have a fix for the cookie domain not being set. We couldn’t fully test this as our domain setup wasn’t entirely playing nicely, so would really appreciate your help in verifying the fix by updating your version of the extension with a custom version and following these steps:

  • Backup your Octopus BuiltInExtensions folder, this should usually be located next to the server executable located at C:\Program Files\Octopus Deploy\Octopus\BuiltInExtensions
  • Stop the server and replace the Octopus.Server.Extensibility.Authentication.DirectoryServices.dll with the version from the download linked above.
  • Start the Octopus Server

Once you have updated the extension, could you please verify that you are able to login using integrated security and the cookie domain is set appropriately?

Looking forward to hearing back from you,

Regards,
Shaun

Shaun,

We will download the fix and test it out. Thanks!

This fix did not work. The Set-Cookie header didn’t include the domain:
...; expires=Tue, 04 Aug 2020 21:30:28 GMT; path=/; httponly

I wonder if it’s this bit of code in IntegratedAuthenticationHandler.cs:

if (Requests.IsLocalUrl(str, trustedRedirectUrls)) { context.get_Response().Redirect(str); foreach (OctoCookie cookie in authCookies) context.get_Response().get_Cookies().Append(cookie.get_Name(), cookie.get_Value(), this.ConvertOctoCookieToCookieOptions(cookie, false)); return Task.CompletedTask; }

RedirectAfterLoginTo is set in the GET request.

Thanks Brian,

Could you please confirm an example of what the RedirectAfterLoginTo is set to in your case? (it doesn’t need to be the real value, as long as it’s a representative example so we can run through that method to confirm)

And if possible, an example of your custom domain setting please?

We originally thought it would not fall into that code path if your custom domain was not a local url, but we may have made a bad assumption there.

Mark

Mark,

We basically use the same request that happens when you use the “Sign in with a domain account” button (encoded, of course):
integrated-challenge?state={"RedirectAfterLoginTo":"/api"}

Our domains follow the pattern below, for the Octopus server:
octopus.internaldomain.corp

The custom domain for the cookie just drops the “octopus” bit:
internaldomain.corp

Thanks for confirming that Brian,

We’ve modified that code-path to include the domain and have another custom dll you can download here.

Please give this a try during your next maintenance window. The same process as Shaun mentioned earlier: backup your BuiltInExtensions, stop your Octopus service, replace the extension dll, restart your Octopus service (and if there’s any problems, stop your server, replace with the original dll and restart).

Let me know how you go.

Thanks
Mark

This fix worked for us. Will it be included in the next release?

As mentioned in a previous reply, there is still an issue with CORS on the /integrated-challenge endpoint. The Access-Control-Allow-Origin is not being included in the header of the response.

Glad to hear that worked Brian and thanks for your patience.

This will be back-ported to the 2020.2 release branch and will be available in the next release (then merged forward to subsequent release branches). We’ll work towards making that happen this week.

In regards to CORS, we’re also investigating that now, to make sure this is honoured by the extensibility endpoints.

We’ve created an issue here that you can track to be notified when a fix is released. We’re actively working on this now, so I’d expect a fix by the end of this week (worst case early next week if something unexpected is discovered).

Cheers
Mark