In a jsf application I have a table with summarized data. If I'm interested in the details I can click on a row an see the details in another page.
If the managed bean of the 'master' page is ion view scope it is re-created every time I return back from the 'detail' page and I don't think it is a good idea if the user is supposed to check the details more times. I can solve putting the bean in sessions cope but this way the bean (and the data) are kept in memory also when the user is interacting with the application in a completely different section. Probably I would need a custom scope but:
the documentation about custom scope is poor and I'm a bit frightened about people complaining it has bugs and doesn't work well.
the scenario I'm dealing with seems to me quite general, so I wonder why there is no ready solution for it.
Thanks
Filippo
If the detail page has to be idempotent (i.e. it's permalinkable, bookmarkable, searchbot-crawlable), just use two request or view scoped beans and use a GET link with the entity ID as request parameter to go from master page to detail page. See also Creating master-detail pages for entities, how to link them and which bean scope to choose for a concrete example.
If the detail page does not need to be idempotent, then you can always conditionally render the master and detail in the very same view or even display the detail in some modal dialog from the master page on. This way you can continue with a single view scoped bean.
In JSF side you must not be too much worried about the DB performance cost. Rather configure and finetune it in the persistence layer. In JPA for example you can setup a second level cache. If you've much more than 500~1000 items, then consider database-level pagination.
It may be valid to reload the master page each time e.g. if the data could have changed after viewing the details page. However, if you want to keep the data available for longer than #ViewScoped your options are:
You should be using JEE6 of which JSF 2.0 is a part of, so look at Conversation Scope (part of CDI)
Some additional scopes for JEE6 CDI is available through the MyFaces CODI
Potentially use Session Scope and make sure you tidy up when a Request hits which is not for the Master or Details page
Rework your design to use Ajax, so if clicking a record on the Master page its details load in the same view. You could then use #ViewScoped
My preference would be to look at the Conversation Scope. You don't mention which JSF implementation you are running or in which environment.
Related
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.
We have been securing our backing bean methods using a custom #Secure interceptor to prevent forged invocations of the method.
But recently, it hit me that these methods are not reachable if the component invoking the action is not rendered. It is my understanding that JSF will generate the view, and if the component is not rendered based on permissions (e.g. EL with isUserInRole), then any forged POST with that component as the source will not fire because the component will not be found in the restored view. Is this correct?
Essentially, any forgery would have to have a compromised and current JSESSIONID and perhaps even ViewState depending on whether they needed the same view.
Can someone please confirm that my assumptions are correct and, if possible, point me to a place in the spec?
Thanks
Ok,I think I have confirmation that actions for non-rendered components are indeed not reachable according to the spec.
Section 2.2.2 of the specification states:
During the Apply Request Values phase, the JSF implementation must
call the processDecodes() method of the UIViewRoot of the component
tree.[P1-end] This will normally cause the processDecodes() method of
each component in the tree to be called recursively, as described in
the Javadocs for the UIComponent.processDecodes() method.
It also states:
During the decoding of request values, some components perform special
processing, including: Components that implement ActionSource (such as
UICommand), which recognize that they were activated, will queue an
ActionEvent. The event will be delivered at the end of Apply Request
Values phase if the immediate property of the component is true, or at
the end of Invoke Application phase if it is false.
So ActionSource components will only queue an action if they are processed according to processDecodes. Looking at the javadoc for that:
Perform the component tree processing required by the Apply Request
Values phase of the request processing lifecycle for all facets of
this component, all children of this component, and this component
itself, as follows.
If the rendered property of this UIComponent is false, skip further
processing.
So the first check must be whether or not the component is rendered, and if not, skip the rest. The ActionSource is never queued and the action never invoked.
One more note, it does appear that ViewState is only reliable for CSFR prevention as of JSF 2.2 per the spec:
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-869
Previous implementations were apparently too predictable and didn't cover GET requests. The spec now requires this.
So, while it may still be a good practice to secure the server side as well, it does appear it is sufficient to control rendering of the ActionSource component.
JSESSIONID is definitely needed. but that can be easily accessed if a user logged in - I am talking about a case when the user is logged in, but supposedly doesn't have access to the specific method.
The other part is more tricky. If the state is stored on client side, then that can be forged. Beside, there is mechanisms to provide direct link to the actions and pages - like pretty or simple link. If the method is exposed in any of those ways, it should be restricted.
I would secure them to prevent future headaches of constantly monitoring which method is exposed in what way - just imagine if you wanted to add a REST or SOA interface for the application.
I have a drop down menu from which user selects an item(in my case project he is working on), most of the data displayed by a webpage depends on that selection. So I have couple of view scoped beans that call EJB beans which do database queries that depend on the selected project.
I want to cache most of that data in order to reduce Database queries, but when user changes project it has to notify other beans that change has happened and new data needs to be fetched.
So I had an idea:
projectChangeManager (session scoped managed bean), saves which project is selected, notifies it's subscribers when project changes. Has #PreDestory method implemented where I cleanup observers.
project observers (view scoped managed beans), gets data from EJB based on project selection, has onProjectChange() method which fetches new data from EJB. Has #PreDestory method implemented where projectChangeManager.detach(this) is called to unsubscribe from projectChangeManager.
Is this reasonable approach in JSF? Or is it better not to implement observer pattern but just when user changes project I fetch all cached data and save it in session bean and then in ViewScoped bean I just access that data from SessionScoped bean? Or is there a better way?
To me this looks like overengineering. Initially, I would probably just let every managed bean call the repository/EJB whenever it needs data. Then rely on caching in the persistence layer (JPA/Hibernate/whatever you use).
If this turns out to be a performance problem, you can consider some hand-rolled caching solution.
Even in that case I still don't quite see the advantage of your observer approach. Your second approach (cache in session bean, access from ViewScoped bean) looks simpler and should work just as well.
Finally, if you decide to use caching, consider how to avoid a stale cache. If you cache per session, changes in one session will not be visible in another session. Incidentally, I think this is another reason to leave caching to the persistence layer.
I am a beginner in JSF. I am building an application where on loggin on user details from the database are to be displayed in another JSP. I use a managed bean each for all of my jsp pages (JSF) I have defined thier scope as request in my faces-config XML. On logging in the details are verified by an actionListener method in my login page. Before leaving this method I am attempting to set attributes of the managed bean of the next page. But the state that I have set is not preserved in the second page. What am I missing out.
P.S. Please redirect me if this question was asked before and answered.
Thank you
The boundary between the two requests is when you return the navigation outcome from your managed bean action. Then a redirect (if configured so) is triggered to that outcome.
You have three options:
don't use <redirect /> in your navigation rules - thus you'll stay within the same request even when you show another page after submit. The downside is that this hurts user experience - if refresh is pressed, the ugly 'resubmit' dialog appears
use session scope - this is not harmful in small doses, but be careful not to have too many session-scoped beans.
use a conversation framework (like MyFaces Orchestra) - defines a custom scope called "conversation.access" - your data is accessible as long as it is needed.
use <a4j:keepAlive> from richfaces - preferred for ajax-requests.
We have the following problem...
Application's environment:
JSF, Richfaces, a4J
Consider having the following scenario:
The user logs into the system
The user navigates to a new page which consists of an a4j form containing a4j components, the user fills into the form but doesn't submit.
The user opens a new Tab and opens the same URL and fill in the new form with new data
The user returns to his first Tab and submits the information (Note: All beans are defined are session scope)
Result:
The submitted information is the information from the second Tab but submitted from the first Tab, which is expected as long as the beans are defined as session scope.
Problem:
We need to get the behavior of a request scope (i.e: dealing with new tab as a new request although the bean is defined as a session scope).
Notes:
When defining the bean scope as a request scope the partial Ajax response from individual components in the same form, resets the other components since they are not submitted yet.
Any suggestions ?
--
Thanks so much
This is a well known problem for Web applications.
Of course you can try to solve this problem using more custom code
but my quick suggestion is to use the seam framework which solves exactly this.
Seam is a superset of JSF and introduces a new conversation scope for
beans that does exactly what you want.
Seam supports richfaces natively (both are projects of JBoss/Redhat) so
you should not expect any problems with integration.
What is the reason the bean needs to be in session scope ?
If this is only to get ajax functionality then you can change the bean to request and use the a4j:keepAlive tag.
a4j:keepAlive extends the live cycle for the request scope bean, your bean instance then acts like it is in session scope for ajax requests. When the user opens two of the same page they are using two different bean instances.