I have a simple question. All my life I have been in the world of .Net and now I am in a Java project, so I feel rookie.
I'm using
JSF 2.2
JDK 11
Eclipse 2019-06
Can I have a session variable that lives only while the connection of that request is active and is not shared by other request / sessions?
I have drivers of type #ViewScoped.
I want to assign from a Controller, for example:
Request.IdSomething = 10
Request.ObjectUser = MyObjectUser; //my entitys
I from two other different Controller, from other views / pages, to have access to those variables. This to avoid creating those same variables in all Controllers where I need to "travel" that object.
Can be done?
In production this application will be used with Containers (kubernetes), so I do not want my object to be shared between the different connected users.
The object that I want to travel between Controllers, does not require that the user is necessarily logged into the system.
Greetings and thanks!
I have a basic question about JSF ManagedBeans for which I can't find a answer.
Suppose I have a bean MyBean with two methods method1 and method2 and a JSF page with a command link
<h:commandLink action="#{myBean.method1}">
</h:commandLink>
Is it possible for someone to analyse the source code of the page and call method2 instead of method1?
Answer
No, this is not possible by design.
Reasoning
Technically the client can only tell the server "The user clicked a html element with a certain id".
This event is then processed by JSF on the server-side, the component with the corresponding id is looked up and in this case the method "#{myBean.method1}" is executed.
As you can see, the client can not[!] tell the server what to do with this event.
Sources
JSF 2.2 Spec - 3.4 Event and Listener Model
Caveat
JSF is stateful and there are multiple ways to hold this state. The default is to hold state information server-side (e.g. in the users HttpSession).
Another option is to transfer (encrypted) state to and from the client. This is still conceptionally secure, but there *might* be bugs with client side state saving. Such a bug *could* be exploitable to do something like you described.
Yes, it is always possible to modify code (or markup-language) on the client-side. Your "action" will be called through some forms and/or Javascript-Methods - everything visible to experienced users.
But that's not an issue of JSF-2 only - this applies for every language which allows insights from the client side.
You shouldn't apply "security through obscurity" (https://en.wikipedia.org/wiki/Security_through_obscurity) but rather make sure, that you can handle this on the server-side.
If a user, who has access to two urls modifies url1 to url2 - that's fine, why not? (Could be bookmarked) - But YOU should take care of the modified request, if he is not allowed to access url2.
I launched two different instances of JBoss AS 7.1 on my machine on two different ports and deployed the same application (with the same root context) to both of them. This configuration gave me, deterministically, the following exception as I was doing tabbed browsing with the same browser (either Chrome or Firefox or Conkeror):
javax.servlet.ServletException: viewId:/whatever.xhtml - View /whatever.xhtml could not be restored.
javax.faces.webapp.FacesServlet.service(FacesServlet.java:606)
org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62)
When I was browsing with different browsers things were ok.
Upon further investigation on how different browsers store cookies I discovered that the combination (IP / path) has to be unique to avoid such tabbed browsing problems and that the port does not come into play. I.e. cookies are stored per IP and per path but not per port. So doing tabbed browsing with the same browser on two different applications deployed on the same IP and path (but obviously on separate ports) will result in expired views as the browser mixes up the two sessions. I recognize that my setting is unlikely to arise in a production environment but I would like to ask:
is there any standard that defines this cookie organizing behavior?
are there any best practices one must be aware of in order to avoid session mixups when doing tabbed browsing in multiple JSF applications?
does the javax.faces.STATE_SAVING_METHOD have any bearing on this (in my setting it was set to "server") ?
is there any standard that defines this cookie organizing behavior?
Version 0 cookies (Netscape spec cookies) do not support ports in any way.
Version 1 cookies (RFC2965 spec cookies) supports the Port attribute. If this is absent, then version 0 behavior is used.
The average servletcontainer sets the JSESSIONID cookie as a version 0 cookie. You could theoretically override this by providing a custom "Session Manager" in the servletcontainer. Note that MSIE 9 does still not support version 1 cookies.
are there any best practices one must be aware of in order to avoid session mixups when doing tabbed browsing in multiple JSF applications?
The canonical approach in real world projects is to use a different subdomain (on same port!). E.g. beta.example.com, dev.example.com, update.example.com, test.example.com, etc.
does the javax.faces.STATE_SAVING_METHOD have any bearing on this (in my setting it was set to "server") ?
If you set it to client, then the ViewExpiredException will indeed disappear as the view is not stored in the session anymore, but instead in a hidden field of the form. But you might still face other session-related trouble, for sure if you're storing some stuff in the session, such as session scoped managed beans and the logged-in user.
If I have a #ManagedBean that's #SessionScoped, why would I use a #Stateful EJB? I used it before for shopping carts and maintaining a conversational state, but since a managed bean will be kept during the user session I can store state there, then call SLSB for bussiness logic. Is that correct? If it is, then stateful ejbs will be left for more specific applications such as when you need transactions etc?
Very often stateless session beans can be used for a lot of business problems.
Stateful does not necessarily means only a remote server keeps state, although this is certainly one of the options. A remote Swing client could first send a bunch of data to a stateful session bean, hold on to the stub and then subsequently send some commands that operate on this data. This saves the client from having to send the same (large amount of) data each and every time.
In the remote use case, it indeed somewhat mirrors the usage of the HTTP session when web clients (browsers) are used. The major difference is that the session is per bean here, while with the HTTP session, the session is a scope shared by many beans. Since the HTTP session is based on cookies, and cookies are global for a domain for the entire browser, the HTTP session can not directly support multiple sessions from the same client (e.g. per tab or per window). This is trivial with stateful session beans.
However...
Remote Swing clients talking to remote EJBs are not that common.
In the context you described in your question, you will typically use local EJBs and you will store most state in the HTTP session (be careful with sharing!) and these days in the view scope or conversation scope.
So, finally, when to use stateful session beans in this scenario?
One important use case is the extended persistence context in JPA. Normally with a transaction scoped entity manager, when an entity crosses the transactional boundary of an EJB method call it will be detached. If you want to (optimistically) lock an entity between user interactions, this is undesirable. You'll lose the lock.
With an extended persistence context, the entity remains attached and the locks valid when you return from a call to the stateful session bean. This is very useful for preview functionality to assure that nobody else has made any changes to the entity when you okay after the preview. Or indeed for a shopping cart where you want to assure that for some time the item can't be sold to anyone else while in the cart.
I'm developing a java EE web app using JSF with a shopping cart style process, so I want to collect user input over a number of pages and then do something with it.
I was thinking to use an EJB 3 stateful session bean for this, but my research leads me to believe that a SFSB is not tied to a client's http session, so I would have to manually keep track of it via an httpSession, some side questions here . . .
1) Why is it called a session bean, as far as I can see it has nothing to do with a session, I could achieve the same by storing a pojo in a session.
2) What's the point of being able to inject it, if all I'm gonna be injecting' is a new instance of this SFSB then I might as well use a pojo?
So back to the main issue I see written all over that JSF is a presentation technology, so it should not be used for logic, but it seems the perfect option for collecting user input.
I can set a JSF session scoped bean as a managed property of all of my request beans which means it's injected into them, but unlike a SFSB the JSF managed session scoped bean is tied to the http session and so the same instance is always injected as long as the http session hasn't been invalidated.
So I have multiple tiers
1st tier) JSF managed request scoped beans that deal with presentation, 1 per page.
2nd tier) A JSF managed session scoped bean that has values set in it by the request beans.
3rd tier) A stateless session EJB who executes logic on the data in the JSF session scoped bean.
Why is this so bad?
Alternative option is to use a SFSB but then I have to inject it in my initial request bean and then store it in the http session and grab it back in each subsequent request bean - just seems messy.
Or I could just store everything in the session but this isn't ideal since it involves the use of literal keys and casting . etc .. etc which is error prone. . . and messy!
Any thoughts appreciated I feel like I'm fighting this technology rather than working with it.
Thanks
Why is it called a session bean, as far as I can see it has nothing to do with a session, I could achieve the same by storing a pojo in a session.
From the old J2EE 1.3 tutorial:
What Is a Session Bean?
A session bean represents a single
client inside the J2EE server. To
access an application that is deployed
on the server, the client invokes the
session bean's methods. The session
bean performs work for its client,
shielding the client from complexity
by executing business tasks inside the
server.
As its name suggests, a session bean
is similar to an interactive session.
A session bean is not shared--it may
have just one client, in the same way
that an interactive session may have
just one user. Like an interactive
session, a session bean is not
persistent. (That is, its data is not
saved to a database.) When the client
terminates, its session bean appears
to terminate and is no longer
associated with the client.
So it has to do with a "session". But session not necessarily means "HTTP session"
What's the point of being able to inject it, if all I'm gonna be injecting' is a new instance of this SFSB then I might as well use a pojo?
Well, first of all, you don't inject a SFSB in stateless component (injection in another SFSB would be ok), you have to do a lookup. Secondly, choosing between HTTP session and SFSB really depends on your application and your needs. From a pure theoretical point of view, the HTTP session should be used for presentation logic state (e.g. where you are in your multi page form) while the SFSB should be used for business logic state. This is nicely explained in the "old" HttpSession v.s. Stateful session beans thread on TSS which also has a nice example where SFSB would make sense:
You may want to use a stateful session
bean to track the state of a
particular transaction. i.e some one
buying a railway ticket.
The web Session tracks the state of
where the user is in the html page
flow. However, if the user then gained
access to the system through a
different channel e.g a wap phone, or
through a call centre you would still
want to know the state of the ticket
buying transaction.
But SFSB are not simple and if you don't have needs justifying their use, my practical advice would be to stick with the HTTP session (especially if all this is new to you). Just in case, see:
Stateless and Stateful Enterprise Java Beans
Stateful EJBs in web application?
So back to the main issue I see written all over that JSF is a presentation technology, so it should not be used for logic, but it seems the perfect option for collecting user input.
That's not business logic, that's presentation logic.
So I have multiple tiers (...)
No. You have probably a client tier, a presentation tier, a business tier, a data tier. What you're describing looks more like layers (not even sure). See:
Can anybody explain these words: Presentation Tier, Business Tier, Integration Tier in java EE with example?
Spring, Hibernate, Java EE in the 3 Tier architecture
Why is this so bad?
I don't know, I don't know what you're talking about :) But you should probably just gather the multi page form information into a SessionScoped bean and call a Stateless Session Bean (SLSB) at the end of the process.
1) Why is it called a session bean, as far as I can see it has nothing to do with a session, I could achieve the same by storing a pojo in a session.
Correction: an EJB session has nothing to do with a HTTP session. In EJB, roughly said, the client is the servlet container and the server is the EJB container (both running in a web/application server). In HTTP, the client is the webbrowser and the server is the web/application server.
Does it make more sense now?
2) What's the point of being able to inject it, if all I'm gonna be injecting' is a new instance of this SFSB then I might as well use a pojo?
Use EJB for transactional business tasks. Use a session scoped managed bean to store HTTP session specific data. Neither of both are POJO's by the way. Just Javabeans.
Why shouldn't I use a JSF SessionScoped bean for logic?
If you aren't taking benefit of transactional business tasks and the abstraction EJB provides around it, then just doing it in a simple JSF managed bean is indeed not a bad alternative. That's also the normal approach in basic JSF applications. The actions are however usually to be taken place in a request scoped managed bean wherein the session scoped one is been injected as a #ManagedProperty.
But since you're already using EJB, I'd question if there wasn't a specific reason for using EJB. If that's the business requirement from upper hand, then I'd just stick to it. At least, your session-confusion should now be cleared up.
Just in case you're not aware of this, and as a small contribution to the answers you have, you could indeed anotate a SFSB with #SessionScoped, and CDI will handle the life cycle of the EJB... This would tie an EJB to the Http Session that CDI manages. Just letting you know, because in your question you say:
but my research leads me to believe that a SFSB is not tied to a client's http session, so I would have to manually keep track of it via an httpSession, some side questions here . . .
Also, you could do what you suggest, but it depends on your requirements, until CDI beans get declarative transaction support or extended persistence contexts etc, you'll find yourself writing a lot of boilerplate code that would make your bean less clean. Of course you can also use frameworks like Seam (now moving to DeltaSpike) to enhance certain capabilities of your beans through their extensions.
So I'd say yes, at first glance you may feel it's not necessary to use a stateful EJB, but certain use cases may be better solve through them. If a user adds a product to his cart, and another user adds this same product later, but there is only one unit in stock, who gets it? the one who does the checkout faster? or the one who added it first? What if you want to access your entity manager to persist a kart in case the user decides to randomly close his browser or what if you have transactions that spawn multiple pages and you want every step to be synchronized to the db? (To keep a transaction open for so long is not advisable but maybe there could be a scenario where this is needed?) You could use SLSB but sometimes it's better and cleaner to use a SFSB..