I have the following scenario in my application.
There are multiple controllers and views. There is no login/logout functionality and no traditional username/password stuff. The application does some logic on incoming requests directly (no authentication/authorization).
As the user goes through controllers and views, I need to persist the user specific data at some place. This is needed as I need to refer to this until the user is completely out of the application. Basically I need to persist user data without any authentication/authorization functionality.
Shall I go for the traditional HttpSession or Spring's #SessionAttribute to store the required details? Or is there any other better way to do this?
Thanks in advance!
Related
I'm working in MVC application. I need to put/pass couple of values in the controller level and retrieve the same in the service or business layer or persistence layer.
Few said we need to defined security context which is accessible in presentation or in any layer.
Please let me know how to define and access it. Is there is a better way then security context?
Thanks.
Assuming you follow DDD and you have your Domain, Application and Presentation (Controller) Layers, should the Application Layer be completely decoupled from knowing anything about HTTP requests and all the other things that go with it such as cookies, sessions, etc.
To illustrate, say our CommentingService in Application Layer needs a value from a cookie named guestId. Should this value be passed in as a parameter to our service or can we pass the whole Request (HttpContext) object and let our service extract it from there.
Commons sense tells me that if I would want to reuse this Application Layer somewhere else I would want it to be decoupled from web.
Services
Yes, you will want to decouple your application layer from any web concerns.
Application layer is responsible for managing your domain objects like aggregates, repositories etc (orchestration).
Mostly you will go with next layer providing Rest Api functionality.
If you decompose it like that, you could use your API with CLI, Rest, Soap or whatever your business want you to provide.
Cross-cutting concerns
You will want to implement cross-cutting concerns in your application layer, because you do not want to reinvent wheel for every outside layer.
For example: security, caching, transaction managing logging.
It doesn't provide you with business capabilities, so you do not implement them in domain layer, but you can implement it in your application layer.
Will the Freemarker Template support user session similar to JSP?
Can we read and write to user session?
Freemarker itself doesn't care about things like sessions, HTTP requests and the like. It just receives a bunch of objects via the data-model, and then it can access those. So it's up to the web application framework what the templates can do. Modifying a session in an MVC template really smells though. That's the duty of the MVC Controller.
However, if you are using FreemarkerServlet, that creates a data-model that exposes the variables from the request, session and application scopes, and also provides Request, Session, Application variables to read the specific scopes. Though FreemarkerServlet is really just an adapter for legacy or JSP-only apps, otherwise I would avoid it.
SETUP
At present I have a controller heavy spring MVC application. Its components are heavily guarded with spring security. Most of the datamodel fetching, form binding etc... is done within controllers.
I however see great value addition in using spring web flow.
However I would like to use web flow in a specific way.
First of all I would like the web flow to be like traffic police directing web requests to appropriate controllers inside every state (Along with form binding objects, request, session params etc...).
I would like the controller to ultimately determine direction of web flow like successful login or goto registration page. However it is web flow that will consume the decision and facilitate the transition to the next state.
This next state will in turn leverage mvc by invoking appropriate controllers.
This way spring web flow is just like a facilitator and does not contain too much decision making logic & business logic invocation calls.
This is important for me since controllers can get heavy with respect to services it invokes and can potentially invoke them in a multi-threaded approach. All this cannot be done in spring web flow definitions
QUESTION
My question is very simple and basic. Is Spring Web Flow designed to perform like this on top of Spring MVC?
Is it possible to designate just this traffic regulation and state flow functionality to web flow while preserving most of the control and service invocation logic inside the controller?
--Am I understanding anything wrong here? I want to get these questions cleared before
embarking along this path.
This may be a little late for you, but I'm not sure webflow will give you exactly what you want to achieve. You want a router, and that's not really what webflow was designed for. Webflow is used more for multi-page form type flows, and using it for much more risks running into the limitations of the framework. Webflow cannot be used to intercept all web requests -- only those initiated through the flow mechanism, and it has very strong opinions on what state transition is (for example, form/bean validation is the default, although it can be overridden if required).
It's not that it can't be used as a router, it's just that it's not designed for this so you're likely to find impedance from its form based design goals.
How can we flow user session from one spring application context to another?
Basically I have one spring application representing Web Layer and another spring application representing REST layer. I want when Web Layer access the REST layer the session containing user info to be available from to Web at REST layer for authentication.
Please suggest.
Edit after receiving first ans:
At present we do have Web Layer in place along with security and all the other flows. What we are about to intended is to introduce REST layer. This REST layer is suppose to be called by present Web Layer and by other APIs. We do not want to make any changes for Web Layer, but at the same time need security to be placed at REST Layer that should work for Web Layer too when calling REST services.
Differentiate between SSO and session sharing. If you just want the authentication to carry between application (user only has to log in once), then you want some form of Single-Sign-On (SSO), CAS is one example, but there are numerous.
If, on the other hand, you need to have access to the full session (and everything the application has put in it) across different nodes (or applications), you could look into something like Memcached or Terracotta. Worth noting is that session replication is fairly I/O intensive and for larger sites it often requires a dedicated network interface for the replication.
I would put it to you, however, that if your applications are so tightly coupled that they need to share the same exact session state, then perhaps they should not be separated in the first place? This smells of faulty design and architecture assumptions.