navigation buttons in JSF2 and PrimeFaces when doing logout

0

I request your support with a Dinamica web application, which uses Java server faces 2.17 and primefaces 5.1 .

It is mounted on a weblogic 10 and this is accessed through a web server! planet.

The problem is that when performing the log out of the application, if you press the backward buttons of the browser, you see the previous screens which should not be see why the session has already died, if I select any of the options, then if you go back to the Login part, but what they ask me is that you can not see the previous screens returning with the navigation buttons.

The code for my closing session is as follows.

ExternalContext 
extContext=FacesContext.
getCurrentInstance().
getExternalContext();

setUrlLogout((String)
configProps.get
("visor.oam.logout.url"));


        session=(HttpSession)FacesContext.getCurrentInstance().getExternalContext().getSession(false);
        session.invalidate();

        //Codigo de prueba de termino de sesión
        FacesContext.getCurrentInstance().getCurrentInstance().getExternalContext().


        extContext.redirect(getUrlLogout());
    
asked by Alberto D 27.04.2018 в 23:14
source

3 answers

0

OK the problem is that in the application that I have, it is that after logging out, if I navigate with the buttons of the aegator, all the screens of all the sections where I accessed with the active session are shown, and even the information of a query is displayed, for example, if I logged in, I went to the users section, I showed the user screen and the user list, then I went back to the providers section and showed me the providers screen and the list of providers, and then to log out, pressing the back button or foward of the browser were appearing those screens with the data consulted was what they did not want.

The problem was not the session, but the cache, what you had to do was tell the application that it would NOT KEEP CACHE and it is done this way,

A class like this is created

public class ControlCachePhaseListener implements PhaseListener {
private static final long serialVersionUID = 2759127646789250121L;
public ControlCachePhaseListener() {
    // TODO Auto-generated constructor stub
}
/* (non-Javadoc)
 * @see javax.faces.event.PhaseListener#afterPhase(javax.faces.event.PhaseEvent)
 */
@Override
public void afterPhase(PhaseEvent arg0) {
    // TODO Auto-generated method stub
}
/* (non-Javadoc)
 * @see javax.faces.event.PhaseListener#beforePhase(javax.faces.event.PhaseEvent)
 */
@Override
public void beforePhase(PhaseEvent arg0) {
    // TODO Auto-generated method stub
    FacesContext facesContext = arg0.getFacesContext();
    HttpServletResponse response = (HttpServletResponse) facesContext
            .getExternalContext().getResponse();
    response.addHeader("Pragma", "no-cache");
    response.addHeader("Cache-Control", "no-cache");
    // Stronger according to blog comment below that references HTTP spec
    response.addHeader("Cache-Control", "no-store");
    response.addHeader("Cache-Control", "must-revalidate");
    // some date in the past
    response.addHeader("Expires", "Mon, 8 Aug 2006 10:00:00 GMT");
}
/* (non-Javadoc)
 * @see javax.faces.event.PhaseListener#getPhaseId()
 */
@Override
public PhaseId getPhaseId() {
    // TODO Auto-generated method stub
    return PhaseId.RENDER_RESPONSE;
}

}

and then in the faces-config.xml file the following tag is added

<lifecycle>
<phase-listener>com.myapp.util.ControlCachePhaseListener</phase-listener
</lifecycle>

These actions eliminated the cache, and now when I log out I do not go back, I found the answer on this site

link

I hope someone wants to explain this procedure better, it worked for me but I totally do not know how it works,

I see that just in each phase, if I understand well when changing the screen, then each load asks to eliminate the cache, but to whom? How are you ?, are other doubts hehehe

    
answered by 02.05.2018 / 19:40
source
0

To handle sessions correctly in jsf you have annotations that you can manage depending on the scope you want to give you use them in each managedBean of the pages.

They are the following:

The first one is @ViewScoped will be active while the user has the page open and if the recharge will kill the session and open another one.

The second @RequestScoped lives exactly the same time as a request HTTP . Therefore, it will be closed at the end of each application and will be recreated in each new application, thus losing all modified properties.

The third @RequestScoped is only activated while the request is made right there it ends

The fourth @SessionScoped this is hard while you have open the browser will close the session.

    
answered by 28.04.2018 в 01:25
0

Friend this topic is a fight but you must implement 2 things:

  • The exit of the application and the destruction of the context.
  • This is sample code:

    FacesContext.
    getCurrentInstance().
    getExternalContext().
    invalidateSession();
    
    FacesContext.
    getCurrentInstance().
    getExternalContext().
    redirect("/app/paginas/
    ingreso_sistema.jsf");
    

    In line 1 the session is invalidated, in line two it is redirected to the login page (here the server and the browser automatically make a connection and create the new session).

  • The second thing to do is to implement that your pages have a session control, something simple can be to place a Boolean variable something like this:

    public class 
    ControladorSesion  {
    private Boolean booUsuAuto___t = false;
    
    public login(){
       booUsuAuto___t = validarUsuario(arg1,arg2);
    }
    
    }
    
  • When you execute the code from step 1, you must set it to false.

    Then in your pages you do something like this

    <h:panelGroup rendered=#{controladorSesion.booUsuAuto___t}>
    Tu codigo de la pagina con la autorizacion
    </h:panelGroup>
    
    
    <h:panelGroup rendered=#{!controladorSesion.booUsuAuto___t}>
    Tu sesion ha caducado por favor inicia sesion.
    </h:panelGroup>
    

    If you're going to do that, I recommend using TEMPLATES to not do the same in each of your pages.

    The other alternative is to have an http filter and validate the same variable.

        
    answered by 28.04.2018 в 00:34