# Authentifizierung über PhaseListener je nach Seite



## mad-din (2. Jun 2008)

Hi Leute!

Ich bin gerade dabei für eine kleine Webapplikation eine Anmeldung zu realisieren. Ich dachte mir dabei, am elegantesten gehts über den PhaeListener, also hab ich mir eine LoginListener-Klasse geschrieben, die PhaseListener implementiert. Ich bin auch schon soweit, dass jede Anfrage an die Login-Seite weitergeleitet wird. Meldet sich der User an, kann er auch die Seiten ansehen. So, der grundlegende Ablauf funktioniert jetzt also. Aber es sollen nur bestimmte Seiten und nicht alle Seiten geschützt sein, sondern nur bestimmte. Eine Möglichkeit wäre, in dem LoginListener abzufangen, welche Seite gerade abgerufen wird (müsste doch über fc.getViewRoot().getViewId() gehen...), aber das macht bei vielen Seiten einen enorm hohen Aufwand.

Die einfachste Möglichkeit wäre, irgendwo ein Flag zu setzen, ob die Seite einen Login benötigt oder nicht. Nur wo setzt man so ein Flag? 

Danke & viele Grüße,
Martin


----------



## maki (3. Jun 2008)

Warum so umständlich?

Servlets unterstützen Zugriffsschutz von Haus aus, lässt sich in der web.xml konfigurieren.


----------



## SnooP (3. Jun 2008)

Guck dir vielleicht mal acegi an... wenn du nicht den vorgeschlagenen servlet-weg gehen willst.

der ist im übrigen auch nich soo dufte, weil der form-based-login z.B. nur die Möglichkeit bietet Klartextpasswörter zu speichern... für kleine anwendungen geht das natürlich.


----------



## maki (3. Jun 2008)

> der ist im übrigen auch nich soo dufte, weil der form-based-login z.B. nur die Möglichkeit bietet Klartextpasswörter zu speichern... für kleine anwendungen geht das natürlich.


Hi snoop, jetzt hab ich mal ne Frage 

Hab schon von acegi gehört, allerdings verstehe ich nicht ganz was du mit "weil der form-based-login z.B. nur die Möglichkeit bietet Klartextpasswörter zu speichern" meinst?
In einem cookie? URL?


----------



## SnooP (4. Jun 2008)

in der datenbank... und beim Übertragen... sprich anstatt wie man das kennt via md5, ssh1 oder blowfish zuerst "hashen" und dann mit dem hashwert des passworts in der db vergleichen, müssen die passwörter im klartext in der db stehen. Im Prinzip kann man das via HTTP Digest Authentication auch machen - da hat man aber keine html-form mehr - was man im 21. Jahrhundert aber dann doch haben möchte imho 

ich hab das gleiche Problem mit acegi aber noch nicht gelöst... hatte mir nur mal ein simples tutorial angeschaut und da ging das ganze auch ohne hashen...:

hab's gefunden - reine Spring-Konfiguration (wie einfach *g*):

```
<bean id="daoAuthenticationProvider"
        class="org.acegisecurity.providers.dao.DaoAuthenticationProvider">
    <property name="userDetailsService" ref="authenticationDao" /> 
    <property name="passwordEncoder">
        <bean class="org.acegisecurity.providers.encoding.Md5PasswordEncoder" />
    </property>
</bean>
```


----------



## maki (5. Jun 2008)

Naja, die DB hast du ja im Griff, bei der Übertragung hilft HTTPS, dann darf es auch ein Form Login sein.


----------



## ms (5. Jun 2008)

Was spricht dagegen schon im Browser zu hashen?
Oder hab ich jetzt was falsch verstanden?

ms


----------



## SnooP (5. Jun 2008)

wieso hab ich die DB im Griff? ... ich will als User ehrlich gesagt nicht, dass jeder Praktikant der Firma wo die DB gehostet wird, meine Passwörter ausspähen kann... https reicht da nich...

wie hasht man im Browser? JS? fänd ich jetzt imho nich so hübsch... kann man natürlich machen... obige Lösung geht auch ohne JS.


----------



## ms (5. Jun 2008)

Ja, JavaScript bzw. Applet.
Und hübsch muss es ja nicht sein.

ms


----------



## maki (5. Jun 2008)

> wieso hab ich die DB im Griff? ... ich will als User ehrlich gesagt nicht, dass jeder Praktikant der Firma wo die DB gehostet wird, meine Passwörter ausspähen kann... https reicht da nich...


Wenn die Passwörter nur als Hashes in der DB stehen, dann "hast du die DB im Griff" 

Wenn die Benutzerdaten zwar vom Browser im Klartext übertragen werden, macht das nichts, solange HTTPS benutzt wird.
Dann kann man sogar wieder in Java Has(c)hen...


----------



## mad-din (10. Jun 2008)

Hi!

Also erstmal danke für eure Antworten. Hab mir das Acegi zwar mal angeschaut, aber ich muss ehrlich sagen hier geht es um eine reine JSF-Webapplikation, die nicht mit Spring arbeitet. 

Ich dachte an eine einfache Anmeldemethode, die man auch schön in die Website einbauen kann. Klar kann man Servlets über web.xml schützen, aber angenommen ich hab ein Servlet, dass eine Tabelle darstellt und daneben zusätzlich Informationen für angemeldete Benutzer. Dann ist das Servlet einerseits für jeden zugänglich, andererseits müsste es auch geschützt werden und das ist IMHO mit der Authentifizierung über die web.xml-Methode nicht möglich.

Viele Grüße,
Martin


----------



## SnooP (11. Jun 2008)

Doch genau das ist mit der Authentifizierung via Servlet (form-based-authentification - google mal) und den tomahawk-JSF Komponenten von Apache möglich... dort kannst du bei jeder Komponente abfragen: isUserInRole etc... kannst eine Komponente dann entweder rendern oder disablen (z.B. links oder buttons ausgrauen). Also sehr komfortabel und vermutlich genau das was du willst 

Acegi nutzt zwar Spring... aber das einzubauen ist doch recht easy... das schöne an Spring ist ja, dass man es nur soweit nutzen muss, wie man gerade will/benötigt und zusammen mit den Tutorials im Netz sollte das eine machbare Sache werden.

@maki: genau so wie du es gesagt hast, meinte ich es ja  ...in DB als hash, der browser sendet an server, der baut ein hash um das klartext-gesendete passwd und vergleich das mit dem Wert in der db.
Bei Form-Based-Authentification ist genau das nicht möglich. Hier hilft nur das versenden via https und vergleichen von klartextpasswörtern so dass ich in der db eben nicht die hashwerte habe sondern auch klartexte...
andere möglichkeit ist via js das passwort im browser zu hashen und dann zu schicken - hier könnte man dann sogar wieder den form-based-authentification nehmen... müsste man halt nur leicht anpassen... aber wie ich schon sagte - du bist dann auf js angewiesen... sofern man JSF verwendet macht das ja nix, weil da brauchts JS eh 

gibt's in Prototype&Co. evtl. sogar schon funktionen zum hashen?


----------

