Im facing problem expiring session in JSF 2.2, I tried many solutions but in vain.
FacesContext.getCurrentInstance().getExternalContext().invalidateSession();
and
HttpServletRequest request = (HttpServletRequest) FacesContext.getCurrentInstance().getExternalContext().getRequest();
request.getSession().invalidate();
I checked bean with both scopes 'View' and 'Session'. Im not using JSF scope annotations rather our application architecture restrict us to use Spring scope like #scope("session") and i created view scope bean (according to: http://comdynamics.net/blog/109/spring3-jsf2-view-scope/) and register with Spring scopes and used like #scope("view"). It doesn't throw any exception, calls bean logout code and navigate to login page but after logging out when i try to access homepage or any other page it shows all session data even in different browser.
It was working fine with JSF 1.2, I upgraded JSF from 1.2 to 2.2 and now its not working since.
Please help me in this regard.
Related
I'm migrating a JSF application from Spring Security 3.2 to 4.0.1. This version changes many default urls, for example the default login url to /login.
The application has its own login page (using JSF AJAX) and it is still displayed when calling /login, but all POST-Requests to this URL (and so all AJAX-Requests from the Login-Page) are captured by the UsernamePasswordAuthenticationFilter and that is trying to process the authentication, causing the request to get redirected to the loginform again.
After looking at the code this url seems to be hard-coded:
public UsernamePasswordAuthenticationFilter() {
super(new AntPathRequestMatcher("/login", "POST"));
}
So I have to disable this filter completely, or better, avoid it's creation. Can anybody point me how I can do it.
Changing my login page to another url is working, but is not the nice solution.
EDIT: I have created a Bugticket in Spring Security for this: https://jira.spring.io/browse/SEC-2992
EDIT 2: I've found another workaround: If I set the login-processing-url for the form-login to something unused it is working, but seems to be very hacky. There should be a way to disable it completely. Also it should be stated in the migration guide, I lost hours until I found this.
I am going to assume that you are trying to upgrade to Spring Security 4.0.0 (the latest available version is 4.0.1).
Spring Security 3.x used spring_security_login as the default login URL (source: official documentation). This could be set to a custom value as <security:form-login login-page="/login"> and mapped to a controller to render a custom page.
Spring Security 4.x has abandoned spring_security_login and switched to login as the default login URL (source: official Spring Security 4.x migration guide). Therefore, the URL login now goes to the default Spring Security infrastructure, that displays the default, auto-generated login page.
There was a bug in 4.0.0 due to which the default infrastructure was still getting used in cases where the URL /login was manually mapped to a custom controller method. This bug has been fixed in 4.0.1. Do try upgrading to Spring Security 4.0.1 to see if you can use /login as the login URL.
It looks like you could call setFilterProcessesUrl(String) (or, equivalently, setRequiresAuthenticationRequestMatcher(RequestMatcher)) to override the default of /login.
I am developing a JSF web based application that makes use of CDI managed beans and Shiro managed sessions. The problem I've got is when a JSF page that references an object annotated with #javax.enterprise.context.SessionScoped an UnknownSessionException is thrown. I have set the logging level to finest and looking through the application server log file I can see that when the user accesses the login page a new session is created along with a cookie that sets JSESSIONID to b2b69494-2236-467f-9e0b-3c262c74b7c4. When the user accesses the page that references the SessionScoped bean the cookie is updated to have a JSESSIONID set to 49253beaee601d4107cba4b61c77, at this point an UnknownSessionException is thrown. When accessing pages that reference a managed bean annotated with either #javax.enterprise.context.ApplicationScoped or #javax.faces.view.ViewScoped everything works fine.
It appears that when accessing a page that references a session scoped bean, the servlet container is creating a new session rather than allowing the Shiro managed session to be used. If I configure Shiro to use something other than JSESSIONID then the error isn't thrown but instead two sessions appear to be created, one managed by Shiro and the other managed by the servlet container.
The contents of my shiro.ini file is
[main]
authc.loginUrl = /login.xhtml
authc.usernameParam = login:username
authc.passwordParam = login:password
authc.rememberMeParam = login:rememberMe
user.loginUrl = /login.xhtml
authc.successUrl = /app/index.xhtml
sessionManager = org.apache.shiro.web.session.mgt.DefaultWebSessionManager
securityManager.sessionManager = $sessionManager
[users]
admin = password
[urls]
/login.xhtml = authc
/app/** = user
My environment is using Glassfish 4.1, Java EE version 7, Mojarra version 2.2.7 for JSF, Weld version 2.2.2 for CDI, and Shiro version 1.2.3. I have also reproduced the same issue on Glassfish version 4.0 albeit with earlier versions of Mojarra and Weld.
I have uploaded the relevant portion of the application server log to PasteBin which can be accessed with the URL http://pastebin.com/2sPHfdTQ
I've also created an example Maven project to demonstrate the problem. The example project can be downloaded from https://www.dropbox.com/s/1x9pe2o9ja0q9jw/TestJavaEE-web.zip?dl=0 which contains the source code and the complied war file.
Is anyone else currently using CDI managed session scoped beans with Shiro managed sessions, and if so have you had any problems?
Is there a configuration setting I've missed either in Shiro or GlassFish or is this a bug?
Note: I have previously posted this question on the Shiro mailing list but I'm yet to find a solution and I'm hoping that there will be a wider audience on StackOverflow.
So we're using spring-security-redirect as a parameter in the form that is sent to j_spring_security_check, in order to send the user to the correct page after a successful login. Migrating from Spring security 3.0 to 3.1, this stopped working. We use a subclass of SavedRequestAwareAuthenticationSuccessHandler, overriding onAuthenticationSuccess(), and debugging that method I see that getTargetUrlParameter() returns null. isAlwaysUseDefaultTargetUrl() returns false.
Browsing around I can't find anyone having similar problems... I find some references to AbstractAuthenticationTargetUrlRequestHandler.DEFAULT_TARGET_PARAMETER, which seems to have disappeared in 3.1.
Any ideas?
As per Spring security 3.1 xsd,
Attribute : authentication-success-handler-ref
Reference to an AuthenticationSuccessHandler bean which should be used to handle a successful authentication
request. Should not be used in combination with default-target-url (or always-use-default-target-url) as the
implementation should always deal with navigation to the subsequent destination.
So, in your subclass, you have to perform the redirection.
I am working on a weam web application where the once the user logs in, the main (or landing) page calls 4 stateful session beans. So once the user logs in, there will be atleast 4 threads of stateful session beans created. The page also has a logout button. The logout component in the xhtml calls a POJO which has a logout method.
In the logout method, the following statement is executed:
Session.instance().invalidate();
Now the question is, will the 4 threads/instances of the stateful session beans which are created when the user logs in will be destroyed or not.
I am running this application on JBOSS 4.2.3, Seam 2.2.1 Final
I am using JOSSO for authentication.
Yes, they're all part of the same session. You're actually creating session scoped beans, not separate sessions.
Easy enough to check though. Create a method in each of the session beans and annotate them with #Destroy, when the annotated bean is destroyed, it will call this method.
#Destroy
public void callMeWhenIDie(){
log.debug("I'm melting, I'm melting" + this.someDefiningCharacteristic);
}
I want to know about setting and un-setting the session in JSF2.0. Although following some blogs and books (Core JavaServer Faces-3rd Edition), i got to know that using annotation #SessionScoped we can set any manage bean to be in session. I have a loginBean which is #ManagedBean and SessionScoped declared. On the top right corner, my web has login button.
When this session is created (i am not setting it manually, that is why i am confused) and when i gets destroyed? It must be destroyed either by time out or by clicking in logout button only.
JSF uses the Servlet API under the covers. A session scoped managed bean is in essence set as an attribute of the HttpSession. It will be created and set whenever the EL expression referencing the managed bean #{sessionBean} is evaluated for the first time. It will be "removed" from the session whenever the session expires (by either a restart of the client or a timeout in the server) or get invalidated. If you let your logout button call ExternalContext#invalidateSession(), then the session will be invalidated.
If you're familiar with the basic Servlet API, you should already understand how this all works. For an in-depth explanation of the Servlet's HttpSession works under JSF's covers, read this answer: How do servlets work? Instantiation, sessions, shared variables and multithreading.
In jsf 2.0 we can set total class ob as session like i mention
Class_name sm;
ExternalContext extContext = FacesContext.getCurrentInstance().getExternalContext(); extContext.getSessionMap().put("Give name for access this property",sm);
Class_name sm = (Class_name) extContext.getSessionMap().get("Give name for access this property");