Setting cookie domain

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

Hi Brian,

We have managed to get our AD to play along and reproduce this issue and as a result now have a fix we can implement.

To help us plan the release/rollout for this issue, if we made this fix available from 2020.3 and onward, would you be willing to upgrade to the latest generally-available release to get this fix? Alternatively, we can release a new version of 2020.2 with this fix, but it will require a little more time to release as there have been some recent changes in this area of the code base.

Regards,
Shaun

Shaun,

Upgrading to to next release will work fine for us.

Thanks,
Brian

Hi Brian,

Just letting you know that we have released the cookie domain and CORS header fixes as part of version 2020.3.2. If you are able to upgrade to this version, then it should resolve the issues you have been experiencing. Please let us know if that isn’t the case though.

Regards,
Shaun

We just upgraded to 2020.3.2 and now Octopus is sending the CORS headers in response to the /integrated-challenge endpoint. We do still have an issue, because the value for Access-Control-Allow-Origin is not correct.

We currently have the CORS whitelist configured as the wildcard. This should return a header like the following (assuming the request is coming from that host)
Access-Control-Allow-Origin: http://octopus.internaldomain.corp

But the integrated challenge endpoint is returning this header:
Access-Control-Allow-Origin: *

Other endpoints, like /api are returning the correct header.

Hi Brian,

Apologies for the slow reply on this. I am looking at this for you today and it looks like we did indeed miss some of the behaviors from server for this particular endpoint. I will get this fixed up as soon as possible. I should mention that the release may still be a little while off yet, so may require me provide an updated version of the extension ready for you while we wait for the release to go out the door. I will let you know as soon as I have that ready for you.

Regards,
Shaun

Hi Brian,

We have once again made some changes on our which should bring the endpoint in-line with the existing api endpoints. You can access the updated extension here.

It would be greatly appreciated if you could once again give this a try during a maintenance window by taking a backup of your BuiltInExtensions folder, stopping your Octopus service, replacing the extension dll and restarting your Octopus service.

The changes will make sure we honor the Origin header and will respond with a Access-Control-Allow-Origin based on this header value when you have set a wildcard whitelist, which is the same as what the Octopus server does for the other api endpoints. Please let us know if that fixes the issue for you.

Regards,
Shaun

Hi Shaun,

Sorry for the delayed testing. We just tried out the updated extension and it seemed to fix the issue. The CORS headers were what I expected.

Thanks,
-Brian

1 Like

Hi Brian,

Thanks for getting back to us, we appreciate it. Glad to hear that resolved the problem for you. We will get the fix into 2013.3+ for you and will let you know as soon as it’s available.

Regards,
Shaun

Is there an issue in GitHub tracking this? I’m wondering if the fix has been shipped yet.

Thanks,
-Brian

Hi Brian,

Apologies, I was meaning to follow up on this. The issue was released as part of 2020.3.2 and here is the this issue which was associated to it.

Regards,
Shaun Marx

Hi Shaun,

That couldn’t have been fixed as a part of 2020.3.2 unless it was retroactive. I reported the issue after upgrading to that version as you can see above:

-Brian

Hi Brian,

Apologies, it would seem the milestone was incorrectly assigned to the issue. I have adjusted it accordingly. The issue has definitely been fixed in latest releases, so would suggest 2020.3.6 or 2020.4.0 at this point.

Regards,
Shaun

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.