Backward compatibility is preventing the View.READ permission to apply
correctly. It actually overrides the View.READ instead of complementing
it.
This change only applies default READ right if the View.READ is not
available, and the user has View.CONFIGURE + the view is not empty.
The previous implementation was always appending the per-configuration unique suffix, making it impossible for different configuration builds to share workspaces. In this fix, we introduce a secondary field to control the workspace of sub-builds (which can be either absolute or relative to the matrix head workspace.)
In the past JDK download site had served error message with 200 error code, making Jenkins think that the download is actually successful. Without this check, such cache polution will not be corrected.
Previously, the untar code tries to set the last modified time and mode
on every untarred file. However, if the tar contains a broken symlink,
or a symlink that points to a file that has not been untarred yet, the
time/mode setting would fail on the broken symlink.
Symlinks don't have meaningful modified times or modes of their own, so
only set these values on non-symlinks.
Rename the file "a" in the test to expose the bug.
If a resource with 'Set-Cookie' header is cached (either by intermediary
like HTTP proxy and reverse proxy, or by the browser), it'll cause
identity swap / session mix-up as discussed in this ticket.
I suspect this was caused by HttpSessionContextIntegrationFilter2, which
is the only code path that attempts to create a session when a request
to a static resource is made.
So I'm disabling the creation of session in
HttpSessionContextIntegrationFilter2. This in turn requires that we
have sessions already created when the authentication was successful and
people need to login (or else the login will have no effect.)
We already do so in layout.jelly, so any request that renders a Jenkins
page would have a session, but I've also added it in
AuthenticationProcessingFilter2, which ensures that a successful login
does have a session.
When a client uses the buildWithParameters API and request a json output, return the job definition as a json string instead of doing a redirect on the job page.