I created one web application so i want to store my past logged user name list for comparing new users which are going to login. so how i do that by using ServletContext ?
or is there any other way?
In JSF, application scoped managed beans are stored in the servletcontext. So, you could basically just create and declare an application scoped managed bean and put the list in there.
However, there are probably better ways for the particular functional requirement which is yet unclear in the question. At least, implementing a HttpSessionListener or HttpSessionBindingListener is probably a better idea since logins are usually coupled to the HttpSession.
Here are several examples:
How to invalidate session when user logs in twice?
How to check who's online?
Related
I have app with J2EE, EJB 3.0 and JSF. My session are been used with JSFSession. I want store user data in EJB that I can read and write in any point of my app (EJB, ManagedBean, Interceptor). Any idea?
THX
I'm not really sure, but if your data is not user specific, you should probably use #stateless Bean
Hi I am actually trying to get tips or ideas on a very specific problem. The technology context is
java web app with JSF 2.1 .
So I have a simple java ee app powered by JSF 2.1. The structure is the following
\webapp
\WEB-INF
\templates
header.xhtml
menu.xhtml
web.xml
\secured
\operation1
op1.xhtml
\operation2
op2.xhtml
\operation3
op3.xhtml
userhome.xhtml
login.xhtml
I have one #WebFilter that restricts the access to /secured/* in case the 'user' bean is not set (Actually a Session Scoped Bean).
At the same time upon login, I create a dynamic Menu depending on the user credential. this menu (MenuItems) point to one or more operations (xhtml pages).
So far so good, the user logins, the menu is dynamic, links are being generated and upon clicking he/she can navigate to whatever operations he/she is supposed to do.
My problem is that I can not decide on an elegant way on restricting access to the absolute url of these pages . If user1 is 'authorized' to execute operation1 but not operation2 or operation3, currently I can not find the most elegant way on checking his session state and applying a generic rule (navigation rule?), if the actual web user, writes on the url bar the absolute path of the operation.
'/secured/operation1/op2.xhtml'
What is the most JSF2 compatible way on achieve that kind of requirement?
I have tried the preRenderView on each separate opxx.xhtml page , unfortunately it did not work + i dont like repeating it on each operation
Many thanks for your tips.
Security in web applications is a more advanced topic. Basically you have two ways:
Container based: This means your servlet container like Tomcat does the job for you (recommended)
Application based: You have to do the job on your own
How to setup container based security is explained in detail here. To summarize it, you have to implement a simple form (no JSF form!) with a specific action and specific ids for the username and password field. Afterwards you can easily restrict access to specific URL patterns using your web.xml file. In the web.xml file you restrict access to certain URL patterns for certain user roles. The mapping from usernames to user roles is done by a security realm. How to setup a security realm is desribed e.g. for Tomcat here.
If you want to implement security on your own, you have to implement a ServletFilter that inspects all requested URLs and either forwards users that are not logged in to your login form or passes the request through if the user is authorized. If the user is not authorized to see the page, you will have to forward the user to your error page. As CDI injection does not work for ServletFilter, you will have to lookup the bean that stores the information about your user (logged in, rights) from the HttpSession.
I have read different articles on Session Management and am aware of the different ways of implementing the same.
However below are few questions that I wanted to understand:
How session management is implemented in a real world application (e.g. cookies,url rewriting)?
What would be the steps and which is the best way to do the same?
What way should one prefer over another?
How is session management done wrt different data centers/clusters?
Thanks!
Its security risk to use cookies and url rewriting for sensitive data management. The best mechanism is to use http session in conjunction with https.
In real world scenarios, http session is used carefully to avoid bottle necks. simply rather than adding an entire object to session, an attribute which can be used to obtain an entity from database is carried over the session. bottom-line is that sessions need to be kept light weight.
session best practices include removing the session and invalidating it once its use is completed.
in EJB context, its always better to avoid Stateful session beans. If used, the bean has to be invalidated as the last invocation of the bean.
We have an ideological problem while creating a Web Application in JSF, EJB and JPA.
Our example situation is:
Admin displays the list of users in datatable. Next, he selects user1, which leads him to new user-edition site. The issue occure if he tries to open second card or window and select user2 for simultaneous edition in the same session.
When we try to save user1 data after edition it is not possible, because it is being overwritten in Endpoint by user2.
Data storing:
Because we do not store any data in View part of our project [diagram available below], after displaying it the Managed Beans are being destroyed. Therefore in Controller part we decided to keep the currently selected user as a field in Endpoint [Stateful EJB Bean] which is constant for a session as it is held by Session Scoped Managed Bean.
We believe we should not store any Collections in Endpoint or Session Scope Managed Bean.
Problem:
Particular case is an overview of the situation. In our application we want to edit multiple entities of the same type during on session.
Question:
Where and how should we store the current selections of User/Admin, which lead to edition of that selected entity.
Storing data in view, request scoped part allowed us to control multiple entities in the same session, though we think it is not appropriate approach. But now storing it in controller part leads to limit of one entity of the same type being edited in the same session.
DIAGRAM HERE: http://i.stack.imgur.com/9PyYr.jpg
So the lesson you learned hopefully is to not use the session scope for editing data or for transferring data between pages.
What you should do here is use a GET request with merely the id of the user to be edited. Then on the edit page, use a single view scoped backing bean.
Using this pattern you do not need extra extensions. Only if you use CDI beans as backing beans would you need CODI, since the default #ViewScoped unfortunately does not work with CDI beans. CODI provides a version that does work with CDI.
But if you use JSF managed beans, follow the pattern outlined above and you'll be fine.
Since you are using a Java EE server (Glassfish 3.1) you could get advantage of using CDI which supports different scopes than JSF. There is a CDI extension called CODI which provides the so called "window scope", allowing you to scope your beans per browser window which will solve your problem. More info about the window scope can be found here.
Another option is to use IceFaces JSF library that also supports its own window scope. More info can be found here.
Is there any way to define a spring bean which will be notified when data in session has changed?
I would also like to know pure java solution if possible. All I want is when i add/edit/delete data in httpsession then I want one java class to be notified to do some processing on that data.
Thanks
You don't need Spring for this, the Servlet API provides that out-of-the-box, via the HttpSessionAttributeListener interface:
This listener interface can be implemented in order to get notifications of changes to the attribute lists of sessions within this web application.
You declare it as a <listener> in your web.xml file. See here for an example.
In don't know of a specific Spring-friendly way of doing this, though, I think you'll have to use the above listener approach, and notify your Spring beans from there.