I have a JSF 2.1, Primeface 3.2, Spring/Spring security 3.05 web application. I signin with an account and do some UI manipulation (button click, some ajax actions, etc). I logout and then login with another user, I see the same view (means the same state after the manipulations done by the previous user)
I tried some tricks like change the scope to request, invalide session, set face redirect to true after logout, set javax.faces.STATE_SAVING_METHOD to client etc. but nothing works.
Edit 1: Tried using different browers with different users the same time I see the same view.
Edit 2:
Scenario 1: I have a with a list of checkbox, I tick some checkbox and then I click a who fire a event of a managedBean (actionListener="#{xxxxxMB.doSomething}") and I logout and login, the checkboxs keep ticked,
Scenario 2: the same I tick some checkbox and then I logout and login, the checkboxs are not ticked.
Related
We're using one of the new responsive themes of PrimeFaces 8 (Mirage if that matters) I've implemented a dynamic menu to create the menu of my page. Depending on several parameters, the landing page can be different. Example:
Suppose there's a communications environment in which the menu items are
Documents (opens by default)
E-mail
Pictures
When arriving in the communications environment, the application checks whether there are new e-mails. If so, the user won't arrive on the "Documents" page but on the "E-mails" page.
The theme uses cookies to restore the menu state based on what the user has chosen previously. So suppose last time (s)he has chosen "Pictures", the result now is that the menu item "Pictures" is marked as active-menuitem but the displayed page is "E-mail".
I was already able to clear the cookies so that no menu item is active, but now I'm trying to activate the correct menu item. I got most successful by calling
PF('sidebarMenu').activate($('.custom-active-menuitem').closest('li'));
PF('sidebarMenu').activate($('.custom-active-menuitem').closest('ul').closest('li'));
but since the page is rebuild using ajax, this only works once 🤨. Using the build-in .active-menuitem doesn't work so that's why I introduced .custom-active-menuitem that I set in Java code:
DefaultMenuItem.builder()
.value("E-mail")
.icon("fa fa-letter")
.command("#{communicationBean.openEmailPage()}")
.styleClass("custom-active-menuitem") // or something else to mark this item active
.process("#this")
.update(":page");
So now I'm puzzled. Can someone please get me in the correct direction? How can I make the theme show the menu item I choose as active one?
I'm trying to implement login functionality for a webapp. There's a Javascript version using JQuery and there's a non-Javascript version. The Javascript version is working fine, but I have a problem with the non-JS version:
Currently when the user clicks "login" I'm reloading the same page with a parameter which causes a loginform to be displayed (that means I don't have an explicit login view).
After the login or in case of any input errors I want the ViewController to go back to the view where the user initiated the login process. I cannot use a redirect for that, because especially the rejectedValues would be lost then. What I really need to do is redirect to the view-name on which the login-form was opened.
Is there a elegant way to do this or is it just a better idea to use a seperate login template?
Thanks in advance for any input!
It's not explicitely necessary redirect with spring (I guess you are using RedirectView or "redirect://"), you simply have to pass the parameter to the same view (with ModelAndView or whatever you use), indicating if you should show the login form or not.
If you used the classical #springFormInput , and used #springShowErrors tags accordingly, the error and the values will be recovered in the view, showing inside the login form because you have passed the variable to accomplish this in the controller.
Hope it helps.
I have a JSF 1.2 login page (login.xhtml) that has 2 sub-forms - menuForm, loginForm.
Using a browser, I am able to navigate from the login page to a productList.xhtml page by clicking on the Login button within the loginForm.
....
For allowing the Google Crawler to crawl through my pages that require login, I am trying to test a form submit with a Java program on the loginForm to see if I can retrieve the productList.xhtml page.
The hidden fields (View Source from browser) in the login.xhtml page includes the following:
username
password
autoScroll
loginForm
loginButton
javax.faces.ViewState
I have submitted all the values from above (except the javax.faces.ViewState) in my Java program, but I keep getting only the login.xhtml page back in my response. Why is this?
I cannot submit the javax.faces.ViewState because there is no state on the server-side for the form when a submit happens from the Java program. How do I submit a form that does not yet have a view state?
For allowing the Google Crawler to crawl through my pages that require login
A login requires a session (basically: a cookie). But web crawlers does not maintain the session (basically: they do not maintain cookies). So it ends up here. You have to remove the login form and replace all navigation commandlinks by normal links in order to let any webcrawler index your pages.
It's by the way beyond me why you would like to make restricted pages crawlable (thus: publicitly available). Why is the login there in first instance?
I have submitted all the values from above (except the javax.faces.ViewState) in my Java program, but I keep getting only the login.xhtml page back in my response. Why is this?
Because you omitted the view state field. JSF won't process the form submit then. For a part, this is a safeguard against CSRF attacks and for other part, this is because JSF is a stateful component based MVC framework.
I cannot submit the javax.faces.ViewState because there is no state on the server-side for the form when a submit happens from the Java program. How do I submit a form that does not yet have a view state?
You need to either maintain the session (basically: send all cookies from the server back in subsequent requests), or to set the state saving method in web.xml to client and you also need to pass the view state hidden field along with the form submit request.
I have a portlet which involves displaying several JSP pages.
In first JSP page A, when I click the Submit button on Page A the processAction() method takes action and a JSP page B appears.
Now if I use Web Browser's Back button to page A and click the Submit button again, the
JSP page B appears but I noticed the processAction() didn't take any action. (Usually clicking Submit button in a JSP page can result in the processAction() to take action).
Can anyone help for this problem? In my Porlet, it MUST go to the process action but it doesn't after back button.
This is the default behavior. Portal has "Multiple Action URL Protection " enabled by default. When a page loads, an action link is created and that link contains an action ID. The same action ID cannot be used again in the same session. So when you click on Back Button, if the page is loaded from the history cache, your Form contains the same action link which was used before. So portal simple reloads the page, rather than calling the processAction().
You can disable this by adding the following configuration for your portlet in portlet.xml file.
<init-param>
<name>wps.multiple.action.execution</name>
<value>true</value>
</init-param>
Without seeing any code, it sounds as if your form response may be cached. What is the method attribute on your <form> ? Forms submitted via GET (or no method attribute at all) are allowed to be cached; in which case neither the server nor your portlet's processAction(...) will be invoked - the browser will re-render the previous response from cache.
If you post some code there may be more offers to help...
HI,
How to retain the current state of the application with all the opened tabs and loaded grid when user does browser refresh or f5 in GXT using MVC pattern?
Regards,
Srini
One approach is to set browser cookies so that browser state can be restored at a later point.
Construct the grid/tab panel
Set a cookie with the current paging settings or open tabs
When the paging settings change or when tabs are opened/closed, update the cookie
Now that you're setting cookies, update step 1 so that you construct the grid/tab panel using settings you read from the user's cookies. Of course, if no cookies are set, use the default settings (grids start on page 1; no tabs open in the tab panel).
If you are using a fairly strict separation of concerns in your MVC pattern, the setting and updating of cookies should occur in the controller layer. The cookies themselves are another source of model data, and the view (UI widgets) need not understand why tabs are open or why the grid starts on page 3.