I am using JSF 1.2 here i have a managed bean in request scope, my scenario is to open a seperate window. After action is performed oncomplete i am opening a new window since the managed bean in request scopes the values are not populated in new window. Because new object is being created while opening a new window. i can use session scope but that is restricted.
kindly help me in resolving this.
Two options:
use <rich:modalPanel> instead of a new window. Actually, window.open(..) should be even more restricted than session-scope (pop-up blockers would not allow the window to open)
use a conversation scope. MyFaces Orchestra provides such scope.
how about using a4j:keepalive to keep the request scope bean alive in the new page.
however for this to work i think your bean must implement Serializable interface.
Related
I have a #ManagedBean #SessionScoped class to represent a user session. Assume it has a theoretical method doHorribleThings(). Access to methods of this bean through JSF can, for example, be enabled through Expression Language attributes such as action="#{userSession.doHorribleThings()}" on a Prime Faces p:commandButton.
My question is, does JSF manage access security for such method? Can a user issue performing the action of a button that is not being rendered for him, e.g. by sending an artificial HTTP package? Or does JSF capsulate a virtual client desktop that stretches accross the network, effectively enabling access control through GUI design?
No, JSF doesn't have an access security for invoking a method in a managedbean other than the UI, as far as I know.
Because if your able to mimic an action that happens through the click of a JSP/Primefaces button with a manual HTTP request then JSF container cannot identify the difference between the two and hence work the same way for both the request
I'm working with JSF 2.0 and and existing framework. We have a listener class that allows us to see when objects are being added to the request/session by implementing HttpSessionAttributeListener and ServletRequestAttributeListener.
Now that we are dealing with #ViewScoped objects I can't figure out a way to get alerted when a ViewScoped object is added. Is there a new listener for this similar to the 2 mentioned above?
The view scope is represented by UIViewRoot#getViewMap(). This map only fires the creation and destroy events, the PostConstructViewMapEvent and PreDestroyViewMapEvent respectively, which can be listened by a ViewMapListener implementation (which is by the way quite verbose to set up as compared to e.g. HttpSessionBindingListener; the JSF system event listener API is not really well thought out as to configuration). This map does not fire any events for add/remove. To be sure, I even looked in source code of Mojarra if it didn't sneakily do that, but, unfortunately, it doesn't.
Your best bet is to fire those add/remove events manually in #PostConstruct and #PreDestroy of your view scoped beans. Noted should be that in JSF 2.0/2.1 the #PreDestroy of a view scoped isn't invoked on a session expire. This was an oversight in the spec and is fixed for JSF 2.2.
I use JSF and I want to avoid a same session sharing 2 tabs in my browser. I think an easy way is to force url rewriting instead of using cookies.
Can anyone tell me how I can force the url rewriting with JSF?
Thanks.
Stéphane
I want to avoid a same session sharing 2 tabs in my browser
Sorry, but this makes no sense. This is not something which you can control from the server side on. All browsers use the same session in all opened tabs/windows (expect of anonymized tabs/windows like Chrome Ingognito via Ctrl+Shift+N). That's just how all browsers work and completely beyond your control.
If you're having a problem with it, then you should absolutely solve it differently than attempting to disable session sharing in multiple browser tabs/windows (which simply isn't possible). It sounds much like as if you're incorrectly storing request or view scoped data in a session scoped bean. You should not do that. You should store request scoped data in a request scoped bean and view scoped data in a view scoped bean. The session scope should only be used for session scoped data, such as the logged-in user and its preferences like language settings.
I think the view scope is actually what you're looking for; it lives as long as you're interacting with the very same view (read: the very same browser window/tab) by postbacks and it it not shared in other browser windows/tabs.
See also:
How to choose the right bean scope?
I want a method in a session scoped backing bean to be called after a user logs in. How can I do that?
Environment: Spring Security 3.0.x, Spring 3.0.x and JSF 1.2. The backing beans are managed by Spring.
Background: Sessions are created even without login. My session scoped bean holds settings, that are initially set to default values. After login I want to update the session state to the preferences stored in the database for that particular user. To achieve that I imagined an interface or even simpler an annotated (e.g. #PostLogin) method, but so far I have not found anything like that.
It would be OK if that method is called on every principal change, i.e. also on logout. It would also be acceptable if the whole bean is destructed and recreated on login, though my other session scoped beans should survive.
What I have found so far is:
ApplicationListener<AuthenticationSuccessEvent>: The listener apparently needs to be application scoped, and I can't get access to my session scoped bean in it. #Autowired plus scope proxy don't work. The injected object is broken; it does not contain its dependencies although the real backing bean does.
<form-login authentication-success-handler-ref="..">: haven't tried this, but I need the method to be called independent of the used login procedure. Other than form based we support remember me and programmatic login (e.g. automatically logged in after password forgotten process).
Answering my own question:
ApplicationListener was the right track, however #Autowired was not.
I defined an interface with one method, that is implemented by my session scoped bean. The (singleton scoped) event listener class then uses ApplicationContext.getBeansOfType(..) to find the session beans by that interface and invokes the interface's method on each of them.
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.