Problems logging in or staying logged in to Continua CI

Continua CI Discussion
1

Hi Guys,
First, Hope you are doing well in these troubled times, being safe at home with your close ones.
We are working from home as well and trying to keep as safe as possible.
I’d like to ask for you guys to comment on this when you get a chance:

This specific issue is something that has been happening to us from time to time, even before we started to work from home actually.

We’re running Continua CI Server 1.9.1.626
For some time now (with previous versions as well) we sometimes experiences issues logging into the Web UI:

Unauthorized Access
No authorized Continua account was found for your windows account. If you should have access to Continua, see your administrator

image
image834×230 18.3 KB

I’ve had this issue myself and the only thing that seems to be resolving it is if we clear the site’s cookies completely in chrome, close it and re-open.
But then it will happen again the next day, I’d find myself redirected to /account/unauthorisedldapaccess with this error and have to clear cookies again to login.
The only way I resolved it for what seems to be more than 5 days now, is:
Once I logged in successfully, i’d logout, and then login again, now using the Web-UI login form instead of the windows pop up authentication method,
Only after doing that, my session holds for 5+ days now.

Alas, I still have at least 1 user that is reporting he can’t login at all
He’s getting redirected again and again to /account/unauthorisedldapaccess no matter what he does, using incognito sessions and normal sessions with cookie clearing and the works - and still gets redirected and is unable to login (using chrome at least, he WAS able to login with internet explorer)
I see nothing relevant in CCI’s event viewer.

We’re working with Windows Server 2008 r2 with AD 6.1.7601.17514
(Connecting from Windows 10 on latest Chrome)
The authentication method we’ve selected during CCI installation was mixed, all the users that are setup are LDAP though; including the 1 user still reporting the problem.

Can you guys think of any reason anything like this could happen?
Thanks!

2

Hi,

a team mate is facing the same issue here. I need to get details though.

Thomas

1 Like
3

Hi @ktopaz,

Thank you for your report and well wishes. I guess we’re somewhat lucky in this profession in that we can continue to work at home.

We’ve been testing the relevant website authentication paths today, but did not manage to reproduce the issue. We have, however, found some areas of the Windows authentication code which needed improvement.

A new build with these improvements is available to download using the following links:

This build also contains some additional debug logging. If you continue to see the issue, please can you enable server debug logging in the server configuration file, and also for the website in the web.config file, then restart the Continua CI Server service. See Debug Logging for further (updated) information on how to enable debug logging.

Once the issue has been reproduced, can you send the debug log file to me by direct message on this forum or via email to support @ finalbuilder.com.

1 Like
4

I talked to my team mate. Using Chrome he found a cookie “continua-auth”. After deleting the cookie he was able to login again. However, the cookie will expire, so deleting it is something that will need an ongoing action.

Also we noticed that he had an entry missing “Continua-winmode” with value “enabled”. After creating it, he no longer faces issues with logging in to Continua.

We too use LDAP. In the login screen we select “Use Windows Account” for login.

My team mate does not face this issues if he uses Firefox.

Btw., there is a cookie “.ContinuaAuth” which is marked as HTTP-Only. Shouldn’t this be a secure cookie?

5

Hi Thomas,

The continua-auth cookie is generated after authenticating with the /windowsauthentication virtual folder and is required for LDAP authentication. It uses a time-based encryption which is only valid for a short amount of time and is set to expire when the browsing session ends. It should be recreated when re-authenticating. The build v1.9.1.639 improves the logic to ensure that this happens.

The Continua-winmode cookie is used in Mixed mode to switch between Forms authentication and LDAP authentication. It should have be created when logging in and it is set not to expire. We’ll investigate whether there is any reason why this would be missing tomorrow.

The .ContinuaAuth cookie is an ASP.NET forms authentication cookie. It is defined in the web.config file as follows:

<authentication mode="Forms">
  <forms name=".continuaAuth" loginUrl="~/account/login" timeout="30" slidingExpiration="true" />
</authentication>

If your Continua website is configured with SSL, then you can add requireSSL="true" to the forms element. Secure cookies do not work on HTTP websites.

6

I don’t have a “continua-auth” cookie at all.

As for the “.ContinuaAuth” cookie i will add the setting as suggested. Our site runs with SSL.

7

Hi Thomas,

This is not a problem, the “continua-auth” cookie is created when the LDAP re-authentication is required and only used briefly during authentication.

A missing Continua-winmode cookie is treated the same as a Continua-winmode cookie with the value “enabled”, so I can’t see how that would have changed anything.

Let us know if you still see any authentication issues after installing build v1.9.1.639.

8

We installed .639 yesterday. So far no problems. Myself, i don’t see that cookie at all. For my team mate, the cookie is persistent. It does not get removed at all.