[JSF] Redirect naar loginpagina na foute inlogprocedure

[Verwijderd]

Momenteel ben ik een website aan het maken in jsf/jsp. Ik zoek een methode om er voor te zorgen dat als je op een admin pagina terechtkomt en niet ingelogd bent, terug naar de login pagina verwezen te worden.
Hierbij wil ik geen gebruik maken van servlets.

Momenteel maak ik gebruik van een boolean in mijn bean, maar als ik terechtkom op de adminpagina, waar gecontroleerd wordt of ik ingelogd ben, aanvaard hij de boolean niet en blijf ik op de login pagina.

Indien iemand van jullie weet hoe ik dit probleem kan oplossen, zou ik dankbaar zijn.

[BalusC]

Je kunt hiervoor beter filters gebruiken dat de aanwezigheid van de User object in de HttpSession checkt. Deze object is uiteraard in de sessie gedrukt tijdens login en zal verwijderd moeten worden tijdens logout (gewoon HttpSession#invalidate() aanroepen tijdens logout is het beste).

[Verwijderd]

Dat van die httpsession snap ik een beetje, maar zou het mogelijk zijn om de code die in de bean moet staan en de code die in de jsp moet staan even te demonstreren met een klein voorbeeld?

[Janoz]

Er meot niks in de bean of in de jsp, BalusC heeft het over een filter, en die definieer je in je web.xml

[BalusC]

Dit soort logica hoort niet in een bean. De User object zelf is dus de bean in kwestie. Als je deze in de session drukt, dan heb je al een session scoped bean. In de FacesContext is deze dan gewoon bereikbaar via de sessionMap en in de ServletContext als een attribute van de HttpSession.

Om een filter te maken hoef je slechts javax.servlet.Filter te implementeren en de benodigde logica in de doFilter() method te schrijven. Indien de User object aanwezig is in de session, dan gewoon doorgaan met filteren mbv chain.doFilter(request, response), anders verwijzen naar de login pagina mbv response.sendRedirect("login.jsf"). Die filter definieer je dan in de web.xml met een url-pattern die matcht met de adminpagina(s).

[ Voor 4% gewijzigd door BalusC op 05-03-2008 13:49 ]

[Verwijderd]

Aangezien ik een leek ben, komt dit een beetje moeilijk over, zou het hierbij mogelijk zijn om dit aan te tonen met een concreet voorbeeld?

[NMe]

Ook een leek kan de zoekwoorden die hij aangereikt krijgt door anderen in Google stoppen en daarmee proberen een oplossing te vinden. Heb je dat al geprobeerd?

[jeetn]

Kan het zijn dat jij daar op je blog een tutorial hebt over geschreven, BalusC? Denk het niet, maar kan zijn...

Dit is de link:

http://balusc.blogspot.com/2007/03/user-session-filter.html

Zou het dan met JSF iets soortgelijks moeten zijn?

[BalusC]

Dit betreft iets anders. Het is overigens volledig toepasbaar op een JSF omgeving. Heck, JSF is gewoon niks meer of minder dan een verrijkte framework om JSP/Servlets heen. Dus alles wat je met JSP/Servlets doet is ook volledig bruikbaar met JSF.

Terugkomend op jouw probleem. Wat precies snap je niet? Waar precies loop jij op vast?

[ Voor 33% gewijzigd door BalusC op 05-03-2008 19:53 ]

[Verwijderd]

Dus:
Via sql controleer ik of de persoon die zich probeert in te loggen in de database aanwezig is. Hier zou volgens jouw dan de session moeten aangemaakt worden (HTTPSession?), daarna kan ik werken met doorverwijzingen naar andere pagina via send.redirect.

Concreet:
- Hoe en waar moet ik de HTTPSession initialiseren
- Welke code moet ik dan op elke jsp-pagina schrijven om te controleren of de gebruiker is ingelogd

[Janoz]

De session zit al in je request. Je hoeft niks te initialiseren. Je hebt gewoon je inlog actie die er voor zorgt dat je iets in je session aanmaakt waardoor bekend is dat diegene ingelogd is.

Aan de jsp pagina's doe je helemaal niks. Daarvoor gebruik je juist de filter.

[BalusC]

Verwijderd schreef op woensdag 05 maart 2008 @ 20:01:
Dus:
Via sql controleer ik of de persoon die zich probeert in te loggen in de database aanwezig is.

Dit doe je alleen tijdens de login.

Hier zou volgens jouw dan de session moeten aangemaakt worden (HTTPSession?), daarna kan ik werken met doorverwijzingen naar andere pagina via send.redirect.

Je maakt geen HttpSession aan. Die is er al. In de login code vraag je gewoon de User object op van jouw DAO ding. Indien je een User object krijgt dan zet je die als een attribute van de session. De Filter checkt daarop.

Concreet:
- Hoe en waar moet ik de HTTPSession initialiseren

Dat is dus niet nodig.

- Welke code moet ik dan op elke jsp-pagina schrijven om te controleren of de gebruiker is ingelogd

Niks. Je hebt genoeg aan een Filter en een login/logout logica.

Concreet: tijdens de login zet je de User object in de session. De Filter checkt de aanwezigheid daarvan. Indien aanwezig, sta de request toe. Indien afwezig, redirect naar login page. Tijdens de logout invalidate je de session. Je moet helemaal niet in JSP denken. De business logica hoort daar helemaal niet in.

[jeetn]

Ik ben één van de teamgenoten van jb.kg... Ik heb et nu overgenomen van hem om hier op te zoeken

In de filter moet ik dus gewoon in de methode doFilter() gaan kijken of het object in de sessie zit.

Dit veronderstel doe ik dan als volgt:

// Onze login actie staat hierin omdat bij deze bean parameters worden meegegeven die we hier kunnen gebruiken. Dit staat overigens niet in
AdminActiviteitenBean aab = new AdminActiviteitenBean();

Aangezien een bean een session bijhoudt zit het user object daarin en kan ik dus gewoon de user gaan opvragen en controleren of de user die werd meegegeven niet null is??

aab.getUserId() == null ?? // Dit werkt wel niet... Dus zal hier nog anders moeten op gaan controleren, maar wil gewoon ffkes weten of ik wel correct bezig ben.

[jeetn]

Ja, bovenstaand is volledig verkeerd...

De bean zit in mijn sessie... Dus ik moet mijn bean uit de sessie kunnen halen, uit de bean haal ik het Id van de user en ik kijk of dat niet null is ofzo?

Als dat null is dan doe ik een redirect? Is het niet null dan forward ik hem naar de correcte pagina??

[BalusC]

Je moet die bean pas bij de login erin stoppen. Als die bean niet aanwezig is in de sessie, dan is de gebruiker niet ingelogd.

[jeetn]

Hmm... Snap er niet veel meer van... Mss dat antwoorden op volgende vragen enkele zaken duidelijk zullen maken:

Wanneer wordt de sessie gestart?

Wordt een bean niet automatisch in de sessie geplaatst bij het oproepen van de bean?

Hoe plaats je een bean in een sessie?


Momenteel is het dus zo dat de loginactie plaatsvindt in AdminActiviteitenBean. Dit is een bean waar redelijk wat acties gebeuren... Maar loginactie staat in die bean (en niet in een aparte bean) omdat we het userId nodig hebben voor methoden in AdminActiviteitenBean en we weten niet hoe we die paramater zouden moeten doorgeven... Als we gaan verstaan hoe een sessie werkt denk ik wel dat we dit zullen kunnen...

[jeetn]

Je maakt geen HttpSession aan. Die is er al. In de login code vraag je gewoon de User object op van jouw DAO ding. Indien je een User object krijgt dan zet je die als een attribute van de session. De Filter checkt daarop.

Als ik dit lees dan snap ik het een klein beetje meer Heb een pauze genomen (kan wonderen doen)...

Dus...

De HttpSession is er al... In mijn loginactie krijg ik een User object... Dat user object moet ik nu nog toekennen aan die session...

Moet ik dan gewoon dit doen?

In de bean:

code:

private HttpSession httpSession;

public String loginAction() {
...
httpSession.setAttribute("gebruiker", persoon);
...
}

In de filter:

code:

private HttpSession httpSession;

public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) 
            throws IOException, ServletException 
    {
                
        if(httpSession.getAttribute("gebruiker") == null)
        {
            req.getRequestDispatcher("login.jsp");
        }
        else
        {
            chain.doFilter(req, res);
        }
    }

In mijn web.xml plaats ik dit:

code:

<filter>
    <filter-name>loginFilter</filter-name>
    <filter-class>Filter.LoginFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>loginFilter</filter-name>
    <url-pattern>admin*.jsp</url-pattern>
</filter-mapping>

[ Voor 15% gewijzigd door jeetn op 06-03-2008 14:28 ]

[BalusC]

jeetn schreef op donderdag 06 maart 2008 @ 12:23:
Wanneer wordt de sessie gestart?

Dat doet de webcontainer voor jou zodra een gebruiker jouw webapplicatie voor het eerst bezoekt.

Wordt een bean niet automatisch in de sessie geplaatst bij het oproepen van de bean?

Nee, dat doe jij zelf. Hetzij handmatig door het als een attribuut van de HttpSession te zetten, anders "automatisch" mbv een configuratiebestand zoals faces-config.xml in geval van JSF (maar dat doet in dit specifieke geval niet ter zake).

Hoe plaats je een bean in een sessie?

Met HttpSession#setAttribute().

[BalusC]

jeetn schreef op donderdag 06 maart 2008 @ 14:01:
De HttpSession is er al...

Juist. Die maak je helemaal niet zelf aan. Die kun je gewoon krijgen via HttpServletRequest#getSession().

[jeetn]

Ik heb nu volgende klasse:

code:

package Filter;

import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;

public class LoginFilter implements Filter 
{
    private HttpSession httpSession;
    
    public void init(FilterConfig arg0) throws ServletException 
    {
        
    }

    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) 
            throws IOException, ServletException 
    {
                
        httpSession = req.getSession();
        if(httpSession.getAttribute("gebruiker") == null)
        {
            req.getRequestDispatcher("login.jsp");
        }
        else
        {
            chain.doFilter(req, res);
        }
    }

    public void destroy() 
    {
        
    }
}

Ik krijg fout op deze regel:

httpSession = req.getSession();

Heb ook al:

HttpServletRequest.getSession(); geprobeerd... Maar dat lukt ook niet... Ook met # zoals jij het schrijft (waarom schrijf je dat zo?) lukt het niet...

Ik zou wel eventueel in de methode doFilter, ServletRequest naar HttpServletRequest kunnen veranderen, maar dan geeft em een foutmelding op het implementeren van mijn filter dat de methode doFilter niet langer abstract ofzo is...

[Janoz]

Ik krijg fout op deze regel:

Het helpt wanneer je verteld welke fout je krijgt. Nullpointer? ClassCast?

Ook met # zoals jij het schrijft (waarom schrijf je dat zo?) lukt het niet...

Hij schrijft dat zo omdat dat de manier is waarop het wordt gelinkt in de javadoc. Anders dan in het javadoc (achter @see) zul je de # niet op die manier in de code tegenkomen.

[ Voor 51% gewijzigd door Janoz op 06-03-2008 15:10 ]

[jeetn]

De fout is:

Incompatible types
found: javax.servlet.ServletRequest.getSession()
required: javax.servlet.http.HttpSession

Ik heb de code dan ook veranderd naar het volgende omwille van die fout:

private HttpServletRequest httpServletRequest;

httpServletRequest = null;
httpSession = httpServletRequest.getSession();


Als ik dan uitvoer dan krijg ik deze fout:

StandardWrapperValve[Faces Servlet]: PWC1406: Servlet.service() for servlet Faces Servlet threw exception
java.lang.NullPointerException
at Filter.LoginFilter.doFilter(LoginFilter.java:29)

lijn 29 is deze:

httpSession = httpServletRequest.getSession();


Maar zoals je kan zien heb ik httpServletRequest niet geïnstantieerd... Dus de fout ligt daar, maar hoe ik dat moet oplossen weet ik niet... Anders moet ik gewoon terugkeren naar de 1ste soort code waar ik fout op krijg...

[BalusC]

In een HttpServlet webcontainer is de ServletRequest gewoon gevuld met een HttpServletRequest instantie. Kortom: cast de ServletRequest naar HttpServletRequest.

Los hiervan, ik heb sterk de indruk dat jullie de basisprincipes van OO nog niet helemaal onder de knie hebben. Ik heb ook het idee dat jullie nog niet helemaal bekend zijn met het bestaan van de API documentaties. Ook blijkt dat jullie eenvoudige compilatiefouten niet eens kunnen interpreteren. Ik kijk echt op dat jullie zonder deze basiskennis gelijk op een Java EE projectje ingezet worden. Please, begin eens met een goed Java boek/tutorial voordat je met Java EE verder gaat. Anders wordt het alleen maar een zooitje.

[ Voor 11% gewijzigd door BalusC op 06-03-2008 15:51 ]

[jeetn]

Ok thanks

Voor de rest heb je wel gelijk... We hebben een opleiding in OO gekregen, maar we maken hier in het project er niet echt veel gebruik van... Ivm die API documentaties, daar kijk ik (kan niet spreken voor de rest) idd niet echt veel naar... Zou dat idd veel meer moeten onderzoeken...

Deze compilatiefout ging ik wel vinden na iets meer er op te zoeken, maar tijd is iets wat we niet echt meer hebben... Het was idd zeer simpel, maar ik zoek altijd veel te ver achter het probleem

[jeetn]

Hallo,

We zitten nog altijd met een paar problemen...

Het inloggen lukt al, we krijgen geen nullpointer exception meer...

Ik schrijf nu in de filter volgende code:

code:

/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */
package Filter;

import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
import javax.faces.context.FacesContext;


/**
 *
 * @author Jeremy Vanmaelsaeke
 */
public class LoginFilter implements Filter 
{
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) 
            throws IOException, ServletException 
    {
                if(FacesContext.getCurrentInstance().getExternalContext().getSessionMap().get("ActiviteitenBean") == null)
        {
            req.getRequestDispatcher("login.jsp");
        }
        else
        {
            chain.doFilter(req, res);
        }
    }

    public void destroy() 
    {
        if(FacesContext.getCurrentInstance().getExternalContext().getSessionMap().get("ActiviteitenBean") == null)
        {
            
        }
        else
        {
            FacesContext.getCurrentInstance().getExternalContext().getSessionMap().remove("ActiviteitenBean");
        }
        
    }
}

Wanneer ik uitlog wordt ik correct verwezen naar een andere pagina, maar als ik dan in de adresbalk een link geef naar een admin pagina dan kan ik daar toch nog naar toe... Terwijl ik in de destroy methode zeg dat die bean verwijderd moet worden en ook in de logoutAction methode zie hieronder verwijder ik die bean...

logoutAction:

code:

public String logoutAction()
    {
        String ingelogd = "logout";
        FacesContext.getCurrentInstance().getExternalContext().getSessionMap().remove("ActiviteitenBean");
        return ingelogd;
    }

Dit is overigens mijn web.xml file:

code:

<filter>
    <filter-name>loginFilter</filter-name>
    <filter-class>Filter.LoginFilter</filter-class>
    </filter>
    <filter-mapping>
    <filter-name>loginFilter</filter-name>
    <url-pattern>/admin*</url-pattern>
    </filter-mapping>

Moet ik trouwens ook niet een listener gebruiken?? Ik gebruik momenteel één, maar weet niet zeker of dit wel nodig is...

[BalusC]

Je betrekt de JSF er veel te veel bij. Je denkt dat er niks anders is buiten JSF. Je bent je er blijkbaar niet van bewust dat JSF slechts een framework is dat op JSP/Servlets leunt. De FacesContext is helemaal niet beschikbaar binnen een Filter. De FacesContext#getCurrentInstance() zou null retourneren. Zoals eerder gezegd, de HttpSession kun je krijgen via HttpServletRequest#getSession(). De bean haal je dan op mbv httpSession.getAttribute("beanName"); En die bean zou je trouwens niet in de faces-config moeten instellen, anders creeert JSF die voor jou terwijl je die alleen tijdens login zou moeten aanmaken.

Lees mijn eerdere reacties nog eens. De code laat bijna van zichzelf schrijven.

Login methode: zet bean in session met HttpSession#setAttribute().
Filter#doFilter(): check de bean in session met HttpSession#getAttribute(). Indien aanwezig, ga gewoon verder, anders redirect naar login.
Logout methode: invalidate de session met HttpSession#invalidate().

That's it.

Als je die bean in een van de JSF pagina's wil opvragen, bijvoorbeeld om de gebruikersnaam te tonen, dán pas heb je iets aan de sessionMap.

[ Voor 29% gewijzigd door BalusC op 07-03-2008 14:13 ]

[jeetn]

De bean wordt sowieso gebruikt, daarin zit een attribuut ingelogde gebruiker die een persoon object bevat. En die bean bevat nog meerdere methodes...

Als het attribuut ingelogde gebruiker null is, dan ben je niet ingelogd. Bevat het attribuut een object dan ben je wel ingelogd.

We weten dat het slecht is, maar we kunnen dit nu nog onmogelijk gaan veranderen Maandag moet het project worden ingediend, dus is er geen tijd meer om dit alles te gaan veranderen...

Het is overigens de 1ste keer dat we zo'n project maken... We weten nu dat we het de volgende keer anders zullen moeten doen... Al doende leert men Dus werkelijk van harte bedankt voor al je uitleg


Nog 1 vraagje... De loginmethode zit in de bean zelf... Dus in de loginmethode gaan we dus dit moeten doen:

httpSession.setAttribute("gebruiker", this);

Maar ik krijg daar een nullpointerexception op... httpSession bevat niets...

Ik moet die session dus opvragen en in httpSession stopen? Sorry voor mijn onwetendheid, maar ik weet het echt niet

[jeetn]

Ik heb nog ffkes verder gekeken en ik heb nu dit geschreven in de loginmethode:

code:

httpSession = (HttpSession) FacesContext.getCurrentInstance().getExternalContext().getSession(true);
httpSession.setAttribute("ActiviteitenBean", this);

In de logoutmethode doe ik gewoon:

code:

httpSession.invalidate();

In mijn web.xml gebruik ik dit als url pattern:

code:

<filter>
    <filter-name>loginFilter</filter-name>
    <filter-class>Filter.LoginFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>loginFilter</filter-name>
    <url-pattern>/admin*</url-pattern>
</filter-mapping>

Als ik uitvoer kan ik inloggen. Ik kan ook uitloggen. Ga ik via de adresbalk naar een admin pagina, dan lukt mij dit Druk ik dan op uitloggen krijg ik foutmelding op de lijn waar de sessie wordt invalidated:

code:

httpSession.invalidate();

[BalusC]

Sorry, mijn motivatie om jou verder te helpen is weg. Succes verder

[jeetn]

Ik weet dus dat ik httpSession.setAttribute moet doen... De sessie kan je ophalen met HttpServletRequest... In een servlet is dat allemaal geen probleem omdat in die methoden een ServletRequest wordt meegegeven die je kan casten naar een HttpServletRequest en zo de sessie kan ophalen...

In een bean (welke een JSF Managed Bean klasse is) kan je toch maar moeilijk HttpServletRequest gaan opvragen... Als je dat doet dan moet je ook alle methoden meenemen van die klasse omdat ze abstract is...

Ik heb al zitten zoeken en doen, maar ik vind enkel maar oplossingen waar ze een servlet gebruiken... En dat gebruiken wij niet...

Dus als iemand mij zou kunnen helpen?

Alvast bedankt

[flowerp]

jeetn schreef op zaterdag 08 maart 2008 @ 10:01:
Dus als iemand mij zou kunnen helpen?

Ik denk serieus dat niemand jou meer zou moeten proberen te helpen. Begrijp me niet verkeerd, dit is echt niet onvriendelijk bedoeld De fouten die je maakt zijn erg basic, we hebben allemaal ooit moeten beginnen en ik sta te popelen om het allemaal even voor je op te schrijven, maar daar ga je gewoon niets van leren.

Programmeren is niet alleen het samenvoegen van code fragments die anderen je geven, je moet ook zelf in staat zijn om een beetje uit te zoeken en logisch ergens over na te denken. Belangrijk is dat je gewoon een zekere basis kennis moet bezitten. Ik snap dat de 'google generatie' altijd heel gericht op zoek gaat naar antwoorden op heel specifieke problemen, maar als je niet weet waar je op moet zoeken en de dingen die je vind niet kan interpreteren omdat je niet snapt wat je nu gevonden hebt, schiet dat nog weinig op.

Zoals BalusC al aangeeft zou je tenminste basis Java/OO kennis moeten hebben en daarnaast het idee van Servlets/Filters/JSP pagina's moeten begrijpen en de plek die JSF hier in neemt.

Nu kan ik, BalusC of 1 van de anderen je wel weer wat dingen gaan uitleggen over de lifecycle in JSF, over het feit dat filters voor de FacesServlet komen en dat je pas vanaf de FacesServlet je FacesContext hebt, etc, maar als je de basis niet begrijpt zul je dat ongetwijfeld weer verkeerd interpreteren (no offence) zodat er weer veel, eigenlijk onnodige, extra vragen uit voortkomen.

Kortom. Lees eerst een boek en ga daarna pas aan zo'n opgave werken.

suc6 ermee

[BalusC]

Een laatste hint, de HttpServletRequest, HttpSession en ServletContext kun je allemaal via ExternalContext#getRequest(), getSession() en getContext() opvragen die op haar beurt via de FacesContext te opvragen is. De attributen daarvan zijn allemaal ook als een map te opvragen via de ExternalContext#getRequestMap(), getSessionMap() en getApplicationMap().