I'm working on a prototype that initiates Spring Batch jobs from web requests. The jobs consist of a series of Tasklets, and I'd like the Tasklets to have some of their members auto-wired in with a session scope.
I'd also like to be able to use the role of the user who initiated the request in Spring Security if possible.
Is there a sensible way to do this?
Related
I would want organize multithreaded access via the rest api to a resource using Spring Boot.
There is information (I found it here) that SrpingBoot can parallelize requests (which I doubt) to the controller with scope-singlotone.
How to start the design of such a controller, or what approach to apply for this?
Spring handles requests in parallel - that means your singleton controllers have to be thread-safe.
If you have a single resource which cannot handle parallel access you have to use Java's synchronized or locks to serialize the access.
Spring Rest Controllers do handle request using a thread pool. Since Spring beans are singleton, your Spring Beans should be Stateless or we can say bean should have a sheared state. Which means you cannot have a state that will change with the time.
I am using Spring boot 2 with spring webflux running on netty.
I would like to add session management without needing to have a backing database or redis server (so Spring Session doesn't seem to be a solution here).
I could use WebSession in my controllers, but then I would need to enable sticky sessions on my load balancer, which I would prefer to avoid.
What I would like is one of the following:
Client side session like in Play framework (session is stored as a cookie and added onto each subsequent request)
Hazelcast session replication but this only works with servlet containers
Has anyone experienced the same thing and found a viable solution?
Spring Session has plans for providing Hazelcast implementation of ReactiveSessionRepository. The current plan is to wait for Hazelcast 4.0, which will move to Java 8 as baseline and use CompletableFuture instead of their own ICompletableFuture. You can track gh-831 for progress on this topic.
In the meanwhile you could try and use ReactiveMapSessionRepository, passing in Hazelcast's IMap.
A simple question, what is the use of Spring session where I can do a login with session using spring security?
What feature can spring session offer?
To put it simple, Spring Session project provides infrastructure for managing user's session.
Most notably, this includes replacing the HttpSession implementation provided by your Servlet container (e.g. Tomcat) with an implementation provided by Spring Session which is then persisted using SessionRepository implementation of your choice (Redis, Gemfire, Hazelcast, JDBC, Mongo are supported backends in current 1.2.0.RELEASE). This ensures your sessions are stored in container/platform agnostic way and makes session clustering very easy.
Additionally, Spring Session provides some other nice features such as:
configurable strategies for correlating user's requests with a session (either cookie or HTTP request header based)
support for multiple sessions in a single browser instance
WebSocket integration, meaning the HttpSession is kept alive when consuming only WebSocket
ability to retrieve all the sessions for a given user
For more information please take a look at Spring Session's user manual as it contains detailed guides which describe the most common use cases.
I have a vanilla Spring Boot application that consists of a controller, a service and a DAO layer. The controller code calls the service code and so on.
To implement some semblance of security, I am currently using Spring Security 4.0.x's global method security annotations in combination with Spring Security ACL to lock down my service methods.
Requests that go through my controllers are auth-ed and authorized just fine because a principal / user is in context. HOWEVER, I also have some additional non-user facing code that listens for messages from an AWS queue. Within this listener code I invoke some secured services (to stay DRY and not duplicate business logic) but for this situation no user is in scope.
Generally speaking:
For a situation like the one I'm describing, what is a good / acceptable way to authenticate user-less method invocations e.g. ones that don't come through an HTTP request (or to bypass the check)? I am considering manually setting the SecurityContextHolder with a "system user" in my message listener code but this has some code smell.
Is method level security better applied at the controller level?
How would we implement a Session Facade design pattern in the Spring application? Would the role of the Session facade be simply served by the service bean class that would be annotated for the transactions and will have a session scope?
A Spring service (with singleton scope) is like a local stateless session bean, it is an implementation of the Session Facade pattern, only for applications that are not distributed. Spring does make the case that in most cases services don't need to be distributed and that the distributed aspects of Session facade are not as all-pervasive as J2EE made them out to be.
(When you say "session scope" it sounds like you're confusing session as in transactional with session as in HttpSession, because Spring uses the term session scope to refer to HttpSessions. (At least it's confusing me about what's intended.) My reading of the Session facade description leads me to think it doesn't have anything to do with an HttpSession.)
Anyway, I'd say the basic goal of encapsulating complexity is still valid. In some cases the goal of giving distributed access is still very valid, it's just not the default case like J2EE tried to make it out to be. And Seam makes a case for stateful session beans still being relevant.
Session should be associated with the web tier, not services.
Services do indeed own transactions, so they should have that annotation.