…well, because they depend on other changes from master
Added way back in commit 71b6a9d The reasons for doing this was _probably_ to enable internal tasks (unsolved back than, had no security context) to still run and work with unpublished repositories. Hoping the best.
Since not all ResourceStoreContentPlexusResource extending classes are going over Router, some of them go directly with Repository instances, and repo instance itself does not care about isExposed. That flag is meant for _transport layer_ to expose it or not for external request. Conflicts: nexus/nexus-rest-api/src/main/java/org/sonatype/nexus/rest/AbstractResourceStoreContentPlexusResource.java
This reverts commit 09f15c6.
This reverts commit 49ec678.
This reverts commit d676390.
…T be used be tests (unless that test does some house keeping)
…s some combination of user error though.
They had been blocked in the "create" but not the "update". Both update and create are now handled now. When a "stateless-session" is created, an attribute is set, when the session is updated, it will NOT be added to the cache if that attribute is found. Also, we do NOT wrap "stateless-sessions" in a delegating session, the session is stored directly in the Subject. So Subject.getSession() will return the active session, but SessionManager.getSession*() will NOT. All of this trickery needs to be removed when we switch to Shiro 1.2 (unreleased at the moment) where there is proper support for this use case. Conflicts: nexus/nexus-rest-api/src/main/java/org/sonatype/nexus/security/StatelessAndStatefulWebSessionManager.java
… cope with 403
…etSubject() so a new Subject is not created when Nexus starts up. SecuritySystem.getSubject() wrapps SecurityUtils.getSubject() which will create an empty subject and attach it to the current thread. This happens on startup when ConfigurationCommitEvent is fired. All threads in the thread pool will inherit this ThreadLocal. NOTE: this subject is NOT authenticated or authorized, it was just an empty Subject.
…he anonymous user, as they will NOT have a session. We also do NOT need to clean up the ThreadContext as is handled by Shiro web framework.
… method is called even if the request through an exception. Conflicts: nexus/nexus-rest-api/src/main/java/org/sonatype/nexus/security/filter/authc/NexusHttpAuthenticationFilter.java
Added happy path test. (A couple of the IT's found this problem, but only after a two hour build).
…reference to TODO
…in the anon user. This seems to be caused by the DelegatingSession if an unknown session is thrown, the subject will be logged out, then a second login attempt will be made.
…if you now set the header: "X-Nexus-Session: none" a session will NOT be created. Cleaned up the test a bit, (changed to hamcrest asserts)