JSF Navigation with URL rewrite
Hi,
The page that I'm developing needs to be able to manage session without using cookies. Therefore I'm using response.encodeURL() for all links.
However I don't know how to keep the sessions when submitting forms using commandbuttons that trigger backing bean functions.
E.g
I have a commandbutton:
<h:commandButton value="Action" action="#{myBean.action}"/>
method action() returns the string "success"
and navigation rule:
<navigation-rule>
<navigation-case>
<from-outcome>success</from-outcome>
<to-view-id>/nextPage.jsp</to-view-id>
<redirect />
</navigation-case>
</navigation-rule>
This navigation works fine but is there any way to pass the session Id in a similar way as using response.encodeURL() ?
Grateful for any help!
/R
# 1
Why don't you use the HttpSession object to store your session ID in?
It is accessible through the FacesContext as follows:HttpSession httpSession = (HttpSession) FacesContext.getCurrentInstance().getExternalContext().getSession(true);
Use HttpSession#setAttribute() and getAttribute() to set and get the session objects. Those are just reflected in the getSessionMap() by the way.
# 2
IMHO, the session ID should be included in any redirect generated by the navigation rules in this case without any effort on the programmer's part. I haven't checked the spec as I do not have it handy but that is the only reasonable behavior in this case.
If the implementation of JSF you are using does not do this then I would consider it a bug and report it to the implementor. Out of curiousity, which implementation are you using?
If you are stuck with the bug, a potential workaround would be to write a filter to wrap all requests and pass a custom HttpResponse object to the doFilter() method, The custom HttpResponse would extend HttpResponseWrapper and override the sendRedirect method to ensure the session ID is encoded in the URL.
# 3
I've checked the specifications and unfortunately they are silent on the issue, which means the session ID need not be appended for the implementation to be conforming. I'd still treat it like a bug and report it to the implementor. If you need more pointers on the workaround, let me
