- 18 3月, 2014 2 次提交
-
-
由 Jesse Glick 提交于
-
由 Jesse Glick 提交于
-
- 17 3月, 2014 7 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
- 15 3月, 2014 6 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
The intent of this test is to make sure that a floating User object without any storage returns false from canDelete() method. The earlier change made User.impersonate() to actually check if the user is a valid, so to make this test case work where it does "user.impersonate" and "user2.impersonate2", I'm creating valid accounts for these two users. Now what that means is that user2 is no longer a floating flyweight storage-less User, so it breaks the assumption of the "User should not be able to delete because he is not saved." assertion. To make this test case work, I'm introducing the 3rd user that is storage-less, and using it for the test.
-
由 Jesse Glick 提交于
-
由 Jesse Glick 提交于
-
由 Kohsuke Kawaguchi 提交于
These tests weren't using a SecurityRealm that recognizes these user names
-
由 Kohsuke Kawaguchi 提交于
-
- 14 3月, 2014 10 次提交
-
-
由 Jesse Glick 提交于
There seems to be no way to export this over the REST API without incurring serious performance penalties.
-
由 Jesse Glick 提交于
Fix terminology used in BuildTrigger conditions
-
由 Harald Albers 提交于
Added some missing German translations
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 phoenix384 提交于
-
由 phoenix384 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
So far none of them are real regressions but just that I needed to update tets
-
由 Kohsuke Kawaguchi 提交于
Now that User.impersonate() actually checks if the user is valid, User.get("user").impersonate() is expected to fail. Use a DummySecurityRealm to make this user a valid user.
-
- 13 3月, 2014 5 次提交
-
-
由 Jesse Glick 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
- 12 3月, 2014 10 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
See javadoc for discussion why this possibly redundant use is desirable
-
由 Kohsuke Kawaguchi 提交于
I think the cleanest place to do this is as a filter of UserDetailsService. The problem is that SecurityRealm defines loadUserByName method, which AbstractPasswordBasedSecurityRealm overrides
-
由 Kohsuke Kawaguchi 提交于
So ApiTokenFilter no longer needs to do that.
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
Jenkins now remembers the authorities (read group memberships) that the user had carried when he/she last time interactively logged in. This information is exposed via User.impersonate(), which is used when using Jenkins SSH, Jenkins CLI, or access via API tokens. Previously this was impossible for a subset of SecurityRealms that does not allow us to read group membership information without successful login (such as Active Directory, OpenID, etc.) For security reasons, if the backend determines that the user does not exist (as opposed to the backend who cannot tell if the user exists or not), then the impersonation will fail. I need to check AD plugin is reporting a failure correctly in this case, before marking as JENKINS-20064 fixed.
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-