In my case, no, I'm only running on instance at one port on a given hostname.

More specific, I'm running the Debian package on port 8081 but accessing it via apache on port 80 with mod_proxy, my virtualhost looks like this:

<VirtualHost *:80>
    ServerName jenkins.qa01
    ServerAlias jenkins.qa01
    ProxyRequests Off
    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>
    ProxyPreserveHost on
    ProxyPass / http://localhost:8081/ retry=1
</VirtualHost>

Firecookie (with Firebug) reports that the Expires date for ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE is invalid.

Date: Mon, 03 Sep 2012 12:45:56 GMT
Set-Cookie: ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE=****; Expires=Mon, 17-Sep-12 12:45:56 GMT; Path=/

Note that the Expires date has hyphens in, which (unlike the Date header) is not valid according to RFC 822.

We see this a lot at our company, too. We are using Jenkins 1.458 and use the Active Directory plugin for authentication.

We have seen it with clients on various OS / browsers.

I, too, looked at the cookies on my machine with firecookie, and the "Expires" value for ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE seems valid (it expires a couple weeks from now).

We run Jenkins on port 8080, but forward port 80 to 8080 using iptables, but no client uses 8080 (that I know of).

We run our instance as a simple setup on a ubuntu 10.04 machine. Runs on port 8080 but forwarded from port 80. There is only one url that we use including the port (default, since we use 80 in practice).

Apparently the trick would be to update web.xml to include this right after the description (or later):

    <session-config>
      <session-timeout>1440</session-timeout> 
    </session-config>

This would tell WinStone (or Tomcat) to have a session expiration of 24h (24*60=1440). The problem is that it would require to extract jenkins.war, patch web.xml and re-zip jenkins.war. Not very automated to get the autoupdates.

ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE is set when 'Remember Me' is checked, it seems valid and expire after 2 weeks.

Same here, Jenkins on Linux and different browsers on Win7. Is there a chance to have it fixed?
Thanks if advance for your response.

Same here too, Jenkins runs on Debian Linux - we always update to the latest version from the jenkins-repository.
Jenkins is accessed via https on port 8443 (using the JENKINS_ARGS to supply the httpsPort argument, keystore et cetera) and use active directory for authentication.

If there's any more information I can supply that'd help in analyzing the problem please let me know.

This is the most annoying thing about Jenkins at our company.

I have a pull request that incorporates Stephane Odul's session timeout suggestion (with a default of two days). Please comment on the pull request if you'd like to see it approved. The more comments, the more popular, the better chance it has to make it in to the main line. Thanks!

https://github.com/jenkinsci/jenkins/pull/674

Stephane Odul's solution is just a hack though. The problem is not that the session expires, it's that the remember me feature does not do anything to make you a new one.

I agree though that it is the most annoying thing about Jenkins and really needs proper dev attention ASAP.

Agreed, but I'd prefer a hack over months and months of annoyance for hundreds of developers. Unfortunately, I don't have time to fix the underlying issue.

We upgraded from Jenkins 1.494 to 1.498 and all of the sudden, Remember Me stopped working. The server is running on a small EC2 instance with Amazon's standard AMI. After a few days, I downgraded us back to 1.494 and Remember Me started working again.

John, the issue with 1.494 is different and tracked in JENKINS-16278.

Just FYI for those of you who would like to see an immediate fix for this merged into the next version. A debate is happening at https://github.com/jenkinsci/jenkins/pull/674 and chances are that nothing will be done soon if more people aren't interested in a quick solution. Please chime in if you have an opinion.

It seems to me, that this is related to the way winstone generates the Expires-field for cookies. When using tomcat as a conatiner I can not reproduce the problems described, only using winstone. The differenc is, tomcat uses a four digit year field and winstone uses 2 digits.

https://github.com/jenkinsci/winstone/pull/6

We are having the same issue here with Tomcat too - or at least the same symptoms, on the current LTS version of Jenkins running on Fc13, Linux, x86_64.
Browsers are accepting cookies - this is seen by all users.

Release 1.502 contains https://github.com/jenkinsci/winstone/pull/6 as well as the fix for JENKINS-16278. Anyone still having problems with this on 1.502?

No change in behaviour observed with 1.502.
Still no persistence of login over browser sessions.
It appears the cookie format was a red herring.

Has anyone looked into the Active Directory plugin? That seems to be the constant factor for everyone that has this bug.

I've not had a moment to try out 1.502 - so cannot confirm this. However - we do not use the active directory plugin in our installation.

Upgraded to 1.502, Active Directory plugin is used.
Have the same behaviour: "Remember me on this computer" checkbox doesn't work.

I'll see what I can do to fix this.

I just set a Bind DN in Configure Global Security, and now the feature appears to be working as designed.
Looks like I was right about the AD plugin...

If you don't mind, could you explain in more detail what I might be able to do to get this working? I'm technically literate, but not familiar with Jenkins and Java configuration files!

You go to "Configure Global Security" and set a "Bind DN" in the Advanced Active Directory settings (see the in-line help there). I'm not sure what else I can say.

I only see the fields 'Domain name' and 'Domain controller' in the Advanced Active Directory Settings (running v1.33 of the Active Directory plugin and Jenkins 1.515).

Are either of those the fields that you mean?

No. I've got the same versions and I can see "Domain Name", "Domain controller", "Site", "Bind DN" and "Bind Password" on the "Configure Global Security" page in the "Security Realm" section with "Active Directory" selected, after pressing the "Advanced..." button (which I had to scroll right to find).

I'm running a system on a single Site (with no slaves). Perhaps that's why I don't see the options.

I only see the two options as well.

Are those of you who see only the 2 options running your master on Windows? I see only the 2 options on Windows and I see all of the options James Howe mentioned on my Linux masters.

Yes, I'm running it on Windows. FWIW, my Jenkins is at 1.516 and the Active Directory plug-in at 1.33. If I do not turn on "ENABLE AUTO REFRESH", then I have to log in frequently throughout the day. With auto refresh turned on, my session is extended all day.

Is there a setting in the Jenkins "web server" that would simply create JSESSIONID cookies that last longer? That would alleviate the problem. The cookie is set to expire after the "Session" but the server must decide otherwise.

Interestingly, doing a google search on "ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE" shows that many other tools and products, not just Jenkins, have been affected by this same issue.

Yes, I'm running my master on Windows. (And I don't see the options that James Howe mentions)

Assigning to Kohsuke, as active-directory lead.

We see this problem as well. Remember me simply doesn't work for us. Our Jenkins (1.519) installation runs on Linux, using our Active Directory for authentication.

I set up logging for the remember me functionality as described here:
https://issues.jenkins-ci.org/browse/JENKINS-16278?focusedCommentId=174193&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-174193

When log in with the remember me checkbox checked, I get the following log record (anonymized MY USERNAME and MY ACTIVE DIRECTORY GROUPS).

FINE: SecurityContextHolder not populated with remember-me token, as it already contained: 'org.acegisecurity.providers.UsernamePasswordAuthenticationToken@582818fa: Username: hudson.plugins.active_directory.ActiveDirectoryUserDetail@0: Username: [MY USERNAME]; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: [MY ACTIVE DIRECTORY GROUPS]; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@166c8: RemoteIpAddress: [MY WORKSTATION IP]; SessionId: 2F3D23A99F52702EC82F36BBBED3ED32; Granted Authorities: [MY ACTIVE DIRECTORY GROUPS]

Note that people only seeing 2 options for setting up AD, Kohsuke made a comment in this bug https://issues.jenkins-ci.org/browse/JENKINS-11948 which explains the difference. I do wish you would get all options all the time

"The behaviour difference you are seeing between your development environment vs production instance is likely because of the OS difference. When Jenkins runs on 32bit Windows, we switch to native ADSI implementation that's better integrated with Windows that's running the user."

As per the comment above, our server is running 64bit Windows Server 2008 R2.

This is becoming VERY annoying.
Our Jenkins master (1.542) is a WinServer2008R2 box, has several Windows slaves (WinServer2003 + WinServer2008R2 + a couple Linux boxes). We "authenticate via custom script". Logins work fine.

I'm using Chrome to view Jenkins. I do NOT close the browser; I don't even close all of the Jenkins tabs (only some of them).
Every few hours, a page refresh shows I'm no longer logged in.
Any suggestions? Polite ones, please.

Move the master to linux, or write a fix for the active directory plugin.

I can also confirm that I have this problem on Jenkins 1.509.4, Active Directory 1.33, running on a Windows Server 2012 master node. Most testing was done with the latest version of Chrome. The natives are starting to get restless, so a fix for the Active Directory plugin would be great. And just "moving the master to linux" isn't an option for a lot of people.

Moving the master to Linux is not an option for us, since our master is the company's main Exchange server.

What we're doing instead is allowing lots of things to be done in Jenkins without being logged in, but that is far from optimal. Still, it prevents the annoyance of having to log in every time you want to do something, so that is the workaround we ended up choosing.

Same on Jenkins 1.544, Active Directory 1.33 on SLES 11. Now I'm using "--sessionTimeout=sane_number_of_minutes" jenkins cmdline switch as a workaround, but still it is a hack.

Did you try this, Andrey?
https://issues.jenkins-ci.org/browse/JENKINS-9258?focusedCommentId=179274&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-179274

Linux is not an option.
And we do -NOT- use ActiveDirectory.
We authenticate with a Ruby script. AD is not involved at all.

Yet Jenkins logs me out after some period of time. Usually a couple of hours, whether inactive or not.
Note: =I= am the only user of our buildserver that is experiencing the periodic logouts. (Or no-one else is complaining.) At least one other user NEVER gets logged out.

@James, no I did not because logins worked as supposed (with short usernames) with empty "Bind DN" field and I didn't want to store and update password in one more place (though it is stored not in plaintext).

Now I tried to do set "Bind DN" and removed the "--sessionTimeout" crutch. WHOAA now it works as supposed, I'm happy, thanks.

So we can say that (at least for my case) it logins well, but bails out without "bind DN"; logins well and remembers well with "bind DN" set. But how could it be explained?

The same problem with LDAP plugin - we are being logged ~ out every hour. No errors in Jenkins log file. It is very annoying! Please find a way to fix this problem!

Still reproduceble

Yes, it still is. And recently, when accessing e.g. job site, users aren't even redirected to login page - they just get an error message.

Discovering my own comment in JENKINS-11643 that this is disabled in Active Directory plugin when Jenkins cannot load details of users by name. That is, either it needs to be running on Windows (where Jenkins can obtain information about other users through ADSI that uses the host computer's credential) or bind DN/password would have to be provided, where Jenkins can obtain information about other users by using this credential.

So the cause is at least known.

What about setups where we do NOT use AD at all?
We don't even have the ActiveDirectory plugin.

We validate logins via a local script.
Yet Jenkins still logs me out several times/day.
Jenkins 1.542 on Windows.

Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
src/main/java/hudson/plugins/active_directory/ActiveDirectorySecurityRealm.java
http://jenkins-ci.org/commit/active-directory-plugin/4f65a3f926aa857e94ea18b687c806eaabaff270
Log:
[JENKINS-11643 JENKINS-9258]

Revisiting the defensive check needed for JENKINS-11643 in light of making remember me service works (JENKINS-9258)

I've made changes in the core so that the TokenBasedRememberMeService2.autoLogin consults
the LastGrantedAuthoritiesProperty of the User object in Jenkins 1.556. So when used with
newer version of Jenkins, I can making remember me work with AD.

This fix makes AD plugin behave gracefully with earlier versions, while still allowing me
to leverage new additions in 1.556.

Changing the title to make sure people don't conflate this with other remember me problems.

That workaround doesn't work if your master is on a windows 2008 machine, since you can't enter a bind DN/password, since those fields are hidden.

The workaround also won't work if you're not using AD.
We don't use AD, we use a local script for login.
Yet Jenkins keeps logging me out, several times each day.
Why?

@Kohsuke We have Jenkins 1.577 installation with AD and have this issue, but I see that your fix went into 1.556 itself. Could I be seeing a corner case?