Hi,

i see the same on Jira 6.2.2.Is this related to the session timeout

Hi russellh and kari.kauppinen@grapica.fi I'd suggest asking on answers.atlassian.com for help.

We have same issue also in 4.4.4. We have exact the same situation as Russel H. Jira is behind reverse proxy and we are using ssl also.

Kari

We still have this issue in 4.4.4.

We are connecting to Jira behind a reverse proxy using ssl.

Everything works fine apart from adding attachments to issues. If we change the 'invalidate.session.on.login' setting to false then the dashboard fails to load.

The reason why we want to have authentication at the reverse proxy is to have access logging for our whole SCM system in one place for auditing purposes. Our SCM system consists of Subversion, Fisheye/Crucible and Jira all authenticating to Crowd and sitting behind a reverse proxy. SSL terminates at the reverse proxy.

Please help!

Cheers,

Russell

Follow-up: I configured the Apache vhost with ProxyPreserveHost On (it was Off by default) and now it allows me to select an attachment and seems to upload it (before that it just told me that the session may have timed out), but the moment I click accept, it tells me something along the lines of 'Temporary attachment with id '5,227,784,173,462,828,552' not found. Session may have timed out before submitting the form.'.

I think this might still be an issue if using JIRA from behind an Apache proxy using proxy_ajp and mod_ssl. We have an Internet-facing Apache server that serves the local network JIRA using proxy_ajp. It uses mod_ssl and does the (basic) authentication against AD using mod_authnz_ldap (not mod_auth_ldap). We disabled AD authentication in JIRA via Crowd after lots of problems with Crowd and AD (Crowd kept timing out or the AD server kept tiiming out, we're still not sure - we had to restart JIRA all the time).

When using the local network address for JIRA, everything works fine, uploads work fine, etc. When using the Internet address, logging in is done correctly and automatically via Apache's basic auth, but the upload problem persists. Worse, if we use the seraph-config.xml workaround, gadgets end up not loading across dashboards.

@Martin,

This is indeed the way to work around the problem.

Basic Auth is problematic since it presentsd user name and password on every request and hence Seraph uses that as a trigger to "estblish" a new session.

I think we need to improve Seraph so that it only does this if the user names changes between requests (which in BASIC AUTHS case is likely to be never other than going from anonymous to someone)

I had the same problem, and saw that user sessions are alsou increasing. So after I changed it:

at atlassian-jira/WEB-INF/classes/seraph-config.xml

<init-param>
<param-name>invalidate.session.on.login</param-name>
<param-value>false</param-value>
</init-param>

everything worked with basick audent.

And user sessions stayed normal, one user one session.

I have divined the source of this bug. The fundamental problem is the session fixation code we put into Seraph during 4.2

In order to be more secure, when a new session is established, Seraph will tear down the old session, copy a few thing across and create a new session.

For non- "basic auth" login this works because you only "establish" the session when you present os_username/os_password in the request that is when you fill in the login form.

However for "basic auth" requests, the username and password is presented with EVERY request and hence Seraph will tear down the session and recreate it ON every request.

We have code in JIRA that tracks "valueUnbound" events from sessions and removes internal state on objects. The Temporary Attachment code is an example.

In this case the session tear down cause the temporary attachment manager to "clean itself" up even though the manager object lives on into the next session.

We need to fix Seraph to do something different on basic auth requests and hence not caused the session disruption and other flow on effects from that.