Howdy, we are frequently seeing login / cookie issues with our Octopus Deploy web app.
Numerous users within our organization report seeing the message “You must be logged in to perform this action. Please provide a valid API key or log in again.”
This appears to be due to session/cookie issues, because if you clear your cookies or use a Chrome Ignito window, then the login starts working again. How can we prevent this from happening? I presume it is a bug in the Octopus web app.
HI,
Just to confirm, what version of OD are you using and is it with Windows Auth? Is it consistently after some period of time every day or more random than that?
We have heard of similar sounding problems in the past and manually deleting the cookies seems to have got things working again (Hit F12 to bring up dev tools, then go to Resources > Cookies and clear all for the OD server).
We have done some work around cookies in octopus deploy 3.0 to avoid these sorts of issues so hopefully this disappears in the future.
Give the above a go and let me know if it helps with the access problems.
Thanks,
Rob
Hi, I’m at the same company and the issue feels pretty random. I agree it seems to be cookie based. Clearing cookies typically resolves the issue. This is highly annoying to users and has damaged a number of users confidence in the product. We are password based. We had this issue with earlier versions (2.6) and still have it with 3.2.8. Is there information I can provide to help troubleshoot this issue? I have seen this issue with Chrome, but not Firefox. Suggestions on where to look or what to provide to you to help resolve this issue?
Hi Pat,
Since we have had a fairly major overhaul of the product between 2.6 and 3.x, then if its still an issue I would lean towards something in your environment/network config. I’m not aware of this happening in any other organisation.
Could you provide some more details so we can try to reproduce the problem? Is there a time period that if left, this occurs over? What is the server responding with when the auth failure occurs?
Thanks for the extra info, once we can ascertain how/when it occurs we can try to reproduce it then provide a fix.
Cheers,
Rob
Howdy! This issue is still occurring, however, it has been must less frequent than when we were running Octopus 2.x.
I still receive the dreaded message “You must be logged in to perform this action. Please provide a valid API key or log in again.” , even though I am using a valid user/password.
The first time this occurred for me after we upgraded to Octopus 3.x, I had switched to a new computer. I think a contributing factor was that I was signed into the Chrome browser, which had brought some of my cookies and/or session data over from the previous PC.
However, just today, on the same PC where Octopus Deploy web UI logins had been working fine for weeks, I’m now getting the invalid API key message when attempting to login. Windows 7, latest Google Chrome browser. Happy to get on a live call / screen sharing session with support to show them what’s going on, if needed.
Hi
I would be happy to screen share to see what could be going on. Simply book a session here at a time that best suits you. Just to confirm, based on your last post you say you get it as soon as you log in? What sort of architecture do you have with your Octopus Deploy server? Are there multiple instances sitting behind a load balancer? Its not a widespread issue that I am aware of so perhaps we may have more luck getting to the bottom of this when we talk directly.
Cheers
Robert
I booked a session for next Wednesday. The error occurs when I attempt to
login. It does not allow the login to occur. Our architecture includes a
single Octopus Deploy 3.x server running on a Windows 2012 R2 instance in
AWS.
Thank you!
Wes
Hi again Wes,
Having a talk about this issue with some of the team and another idea came up which solved another user’s problem. Could you please double check the time & timezone of your client machine (where you’re browsing) and even the server itself and just make sure that its set correctly. If the client and server don’t agree on the time, the cookie that is returned may potentially appear to already be expired to the browser causing it to not be sent up in the request.
This might also explain why you experienced the behaviour when changing machines and with the clock syncing by itself it may also explain why the problem is intermittent.
Otherwise ill still talk to you on Thursday to see what else we can find.
Cheers,
Rob
My local system clock is on MT. The Octopus Deploy server is UTC. They
appear to be just 16 milliseconds apart. My local system is synced with
time.windows.com. The Octopus Deploy server is synced with our internal NTP
host.
Hi Wes,
Here are the meeting details:
Please join my meeting.
https://global.gotomeeting.com/join/261597101
Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone.
Australia: +61 2 9087 3604
United States: +1 (786) 358-5410
Access Code: 261-597-101
Audio PIN: Shown after joining the meeting
Meeting ID: 261-597-101
GoToMeeting®
Online Meetings Made Easy®
Speak soon,
Rob
Hi Wes,
Just thought I’d send a quick update. After pulling down 3.2.8 I think I am able to get it to reproduce! I think its got something to do with how Nancy is extracting cookies and this one contains JSON so it may have something to do with that. Its odd that with the later versions this did not seem to be reproducible. I will continue to look into it but just wanted to let you know that it may still be a bug on our side so you don’t waste too much time trying to work out if the cookie is doing something to the network traffic.
Thanks for your time this morning.
Cheers,
Rob
Awesome thanks! I’m happy to upgrade to a newer Octopus Deploy server
version if the problem is resolved in a later version.
Thank you!
Wes Novack
Systems Engineer | PLURALSIGHT
www.pluralsight.com http://www.pluralsight.com/
Wes,
Just another update. Ive raised this issue with the team and we have created a ticket in Github to get it fixed. I managed to get it failing in our latest build so we will probably be actioning some time today and getting out in our next release in the next few days. Keep an eye on the ticket to check its progress. Ill also shoot you a message once its out in a build.
In the meantime clearing this cookie should let you continue with your work.
Thanks again,
Rob
Hi Wes,
So after some further investigation it appears as though while the HttpListener is having troubles parsing the cookie, causing the auth token to get lost/corrupted, this is not unexpected given the specifications for HTTP Cookies. According to RFC 6265 and RFC 2109 the server should be interpreting a , character as a cookie separator. Essentially the psSubscription cookie should be properly encoded and leaving it as raw JSON in the way it is, is going against the HTTP specs of valid cookie values.
I would suggest you bring this up with the team who are responsible for setting this cookie and once its properly encoded the OD server should continue to parse the cookie information correctly.
Further information as been provided in the GitHub ticket.
Thanks again for taking the time to have the call, I’m sorry there isn’t any changes we can make on our side to get this functioning correctly without the previously discussed temporary work arounds.
Let me know if you have any further questions around this issue.
Cheers.
Rob
I’m currently running Octopus 3.4.10 and having this issue. It definitely seems to be a cookie issue as other users have stated, because clearing cookies temporarily solves the issue. However, once the session times out and the user is taken back to the login page, the issue starts to occur again.
