[
https://issues.jenkins-ci.org/browse/JENKINS-12585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160871#comment-160871
]
Kohsuke Kawaguchi commented on JENKINS-12585:
---------------------------------------------
Thanks to Christian for helping the trouble-shooting session.
We couldn't exactly verify our hypothesis during the session. The hypothesis
hinges upon having Jenkins send "Set-Cookie" header in a static resource that
then gets cached by the reverse proxy, yet the code path that serves those
files do not touch HTTP sessions before committing the output, and the Acegi's
attempt to create a session afterward resulted in no-op, at least with Winstone.
With that said, toward the end, our discussion was mainly around how to fix
this, _assuming_ the hypothesis is correct. Since Jenkins as a webapp doesn't
exactly know when the 'Set-Cookie' header is set on the response by the
container, the solution has to be done on every single response we produce.
One thought was to add "Vary: Cookie", and the other was to add "Cache-Control:
private". Relevant read
[here|http://stackoverflow.com/questions/6491789/http-headers-controlling-cache-and-history-mechanism],
which also says IE<9 fails to locally cache the resouce if the Vary header is
set (and instead if requires conditional GET.)
While driving after the trouble-shooting session, another reason "Vary: Cookie"
header is wrong occured to me, which is that if a request does not contain a
cookie header (say it expired) and if the response contains "Set-Cookie",
"Vary: Cookie" will do no good as the said resource ends up getting cached by
the intermediary.
So I'm inclined to start serving everything with "Cache-Control: private"
unless I hear otherwise.
Incidentally, http://ci.jenkins-ci.org/ appears to have this header set on the
response, although Jenkins doesn't do this. I suspect haproxy or Apache are
doing it.
> SECURITY: LDAP authenticated users switch accounts randomly
> -----------------------------------------------------------
>
> Key: JENKINS-12585
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12585
> Project: Jenkins
> Issue Type: Bug
> Components: security
> Affects Versions: current
> Environment: Mac OSX: 10.6.8 Desktop
> Java version: 1.6.0_29
> Access Control
> * Security Realm: LDAP
> * Authorization: Project-based Matrix Authorization Strategy
> Jenkins: 1.448
> Apache
> * Server version: Apache/2.2.17 (Unix)
> * Server built: Dec 1 2010 09:58:15
> Reporter: guillermo c
> Assignee: Kohsuke Kawaguchi
> Priority: Critical
>
> Running Jenkins behind Apache: mod_proxy with HTTPS
> https://wiki.jenkins-ci.org/display/JENKINS/Running+Jenkins+behind+Apache
> So our setup is
> Open Directory group
> jenkins-admin - Jenkins Admins all
> dev-group-a - Developers can view kick off builds
> Project-based Matrix Authorization Strategy
> Admin all checked
> dev-group-a checked: Overall:Read Job:Read,Build Run:Update
> dev-group-b checked: Overall:Read Job:Read
> issue is I'm an admin and random developer will login and see that there user
> id is mine and can admin jenkins.
> there has been reported cases that developer A will login and actually be
> reported by jenkins as Developer B
> were they can no longer trigger CI builds
> My biggest concern is when users login and are reporting as admins and have
> full access to jenkins.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
