I am using Rest API version “3.3.8” in my project, and in the response, after the log in call, i see a cookie.
NOTE: i am not using the API-KEY because i would like my app to manage the log in.
After the login, i try to call another api and i get a response “not authorized”.
Thanks for getting in touch. If you include the cookie from the login API request in the headers for the subsequent requests then you should be able to access the other API endpoints. Octopus Server will return an Unauthorised response if it doesn’t find the cookie in the request headers. In this case the body of the response will also contain an error along the lines of “You must be logged in to request this resource or provide a valid API key.”, would you be able to confirm whether that is in the response you are getting back?
I run a test using Postman and it looks to be working correctly when the cookie is provided. The issue you’re facing sounds like it will most likely come down to how your app is making the API calls. Is the app browser based? If the app is C# based, are you using Octopus.Client?
1th using octopus client and app in c#: here all work correctly.
2th using javascript: here the issue is only with browsers, if i use postman it works to me too. So i guess it is a cross domain issue and chrome does not attach cookies in the request for security reason.
I haven’t personally accessed the API in this way, we recommend using API keys, but it should work. Two things come to mind,
What result do you get if you change withCredentials to true in the second call?
One of the other members of our team has recently had issues with Chrome not storing the Cookies correctly. Do you have any issues if you access the Octopus Deploy UI from the same machine?
I’ve been able to create a reproduction of your issue, it came back to the withCredentials in the test I did. Just to check, are you using jQuery > 1.5.1? If so, I got it to work by replacing beforeSend with
xhrFields: { withCredentials: true }
once I did that I could see that the cookie was being stored and was being sent on the subsequent requests.
Something else I came across along the way, in case it impacts you at some point, you can get an error saying the CORS headers don’t allow the request if you hit the API on HTTP and the Octopus Deploy server is using SSL with forceSSL set to true. This is related to HTTP redirection rules around POST requests.