Anzeige:
Ergebnis 1 bis 6 von 6

Thema: Passwort in URL verhindern/ Seitenaufruf steuern

  1. #1
    Registrierter Benutzer
    Registriert seit
    25.10.2005
    Ort
    Hamminkeln
    Beiträge
    302

    Question Passwort in URL verhindern/ Seitenaufruf steuern

    Hallo zusammen,

    ich habe angefangen JSP Seiten zu programmieren auf Basis eines Buches, klappt auch, aber mir gefallen folgende Sachen nicht:
    1) Passwort und Benutzername an Auswertungsseite per "post" gesendet, aber in der URL wird trotzdem der Benutzername und das Passwort angezeigt.
    2) Wie kann beim Aufruf einer *.jsp/html Seite abgefragt werden, ob der Benutzer erfolgreich angemeldet ist?
    Da JSP Neuland für mich ist, weiss ich momentan nicht so richtig, wo nach ich suchen muß, im Buch steht es jedenfalls nicht
    Kann mir jemand von euch weiterhelfen?
    Vielen Dank schonmal im Voraus!
    Vereinfacht die Dinge, und ihr erleichtert euch das Leben. (Henry David Thoreau)

  2. #2
    Registrierter Benutzer Avatar von ptr
    Registriert seit
    22.10.2006
    Beiträge
    8
    Wenn die Daten per "post" gesendet wurden, dürften sie nicht in der URL stehen.
    Es wäre jedoch hilfreich, wenn du mal Quellcode posten würdest...
    Freiheit braucht Alternativen!

  3. #3
    Registrierter Benutzer Avatar von Waxolunist
    Registriert seit
    19.06.2006
    Ort
    Wien
    Beiträge
    485
    Also für mich haben sich Frames als ganz günstig herausgestellt um sowas zu umgehen.


    Meine index.jsp:
    Code:
    <%@ page 
    language="java"
    contentType="text/html; charset=ISO-8859-1"
    pageEncoding="ISO-8859-1"
    isThreadSafe="true"
    session="true"
    %>
    <%
    	response.setHeader("Pragma", "no-cache");
    	response.setHeader("Cache-Control","no-store, no-cache");
    	response.setDateHeader("Expires", 0);
    	
    	String ctxPath = request.getContextPath();
    %>
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
    <html>
    <head>
    	<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
    	<meta http-equiv="expires" content="0" />
    	<meta name="robots" content="noindex, nofollow" />	
    	<title>MyTitle</title>
    </head>
    <frameset cols="0,100%" frameborder="NO" border="0" framespacing="0">
      <frame src="<%=ctxPath %>/blank" scrolling="NO" noresize />
      <frame src="<%=ctxPath %>/default_content" scrolling="yes" noresize />
    </frameset>
    </html>
    <% 
    if(session != null){
    	session.invalidate();
    }//if 
    %>
    im blank.jsp steht nicht mehr als:
    Code:
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
    <%@ page 
    language="java"
    contentType="text/html; charset=ISO-8859-1"
    pageEncoding="ISO-8859-1"
    session="false"
    %>
    <%
    	response.setHeader("Pragma", "no-cache");
    	response.setHeader("Cache-Control","no-store, no-cache");
    	response.setDateHeader("Expires", 0);
    %>
    <HTML>
    <HEAD>
    <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
    <TITLE></TITLE>
    </HEAD>
    <BODY>
    </BODY>
    </HTML>
    im default_content habe ich dann nur noch eine Weiterleitung auf die eigentlich login-seite:
    Code:
    <%@ page 
    language="java"
    contentType="text/html; charset=ISO-8859-1"
    pageEncoding="ISO-8859-1"
    isThreadSafe="true"
    session="true"
    %>
    <%
    	response.setHeader("Pragma", "no-cache");
    	response.setHeader("Cache-Control","no-store, no-cache");
    	response.setDateHeader("Expires", 0);
    
    %>
    <jsp:forward page="/login"> 
    	<jsp:param name="operation" value="login" />
    </jsp:forward>
    
    <% 
    if(session != null){
    	session.invalidate();
    }//if 
    %>
    Mag jetzt etwas kompliziert klingen, hat sich für mich aber als Einstieg in eigentlich jedes Projekt, dass ich bisher mit jsp abgewickelt habe, bewährt.

    Die blank-seite habe ich nur, um den scrollbalken zu verhindern. Danach werden die Parameter loginname und passwort ganz normal im Controller abgefragt über request.getParameter und wenn erfolgreich wird auf die willkommen-seite weitergeleitet mittels

    ServletContext.getRequestDispatcher(String pagename).include(request, response);

    War der Login nicht erfolgreich, so wird er auf eine error-page weitergeleitet.

    Nie solltest du solche Logik in die JSP geben. Immer über Controller arbeiten, also Klassen, die von HttpServlet abgeleitet sind.

    mfg, christian
    Geändert von Waxolunist (01-03-2007 um 10:35 Uhr)
    Spezialitäten heute: PLSQL, TSQL, Java (alles mit Webanwendungen), Groovy, Grails, ASP.NET, Javascript, Python, Django
    Straight through, ohne Umwege ans Ziel

  4. #4
    Registrierter Benutzer
    Registriert seit
    25.10.2005
    Ort
    Hamminkeln
    Beiträge
    302
    Hallo ptr, hallo christian,
    vielen Dank für eure Antworten! Ich werde versuchen meinen Quellcode, falls noch nötig, am Wochenende (Sonntag) zu posten.
    Christian, dein Code ist sehr umfangreich und ich werde ihn mir noch genauer zu Gemüt führen! ;-)
    Momentan bekomme ich keine richtige Weiterleitung hin frü folgende Situation:
    Ein Benutzer ruft z. B. die Seite Mitgliederbereich.jsp im Browser auf, dann möchte ich überprüfen ob die Anmeldung ok ist und wenn dies so ist, wird die Seite angezeigt, wenn dieses nicht so ist, dann soll der Benutzer auf eine forbidden_access.html weitergeleitet werden.
    Habt ihr dafür auch einen Tipp? Über die Session bekomme ich das nicht hin,
    und jetzt ...
    Vereinfacht die Dinge, und ihr erleichtert euch das Leben. (Henry David Thoreau)

  5. #5
    Registrierter Benutzer Avatar von Waxolunist
    Registriert seit
    19.06.2006
    Ort
    Wien
    Beiträge
    485
    Die Parameter password und loginName werden selbstverständlich gepostet. Hab ich noch vergessen dazuzusagen.

    Hab ich das richtig verstanden, dass du bei jedem Aufruf einer JSP den Benutzer validieren möchtest?

    Wenn, dann ist das eine eher schlechte Taktik.

    Du solltest hier mit dem Filterkonzept arbeiten. Ist ein bisschen wie Trigger in Datenbanken. Der Filter wird immer dann aufgerufen, wenn eine Seite aufgerufen wird, die den Filter matcht.

    Such einfach mal nach jsp + filter.

    Ich hab das hier so gelöst, dass ich in einen Ordner alle JSPs habe, die nicht für den öffentlichen Bereich sind.

    Darauf hab ich nun einen Filter im Deploymentdeskriptor registriert:

    Code:
    	<filter>
    		<description>
    		</description>
    		<display-name>PrivateFilter</display-name>
    		<filter-name>PrivateFilter</filter-name>
    		<filter-class>at.sterzl.myproject.PrivateFilter</filter-class>
    	</filter>
    	<filter-mapping>
    		<filter-name>PrivateFilter</filter-name>
    		<url-pattern>/private/*</url-pattern>
    		<dispatcher>REQUEST</dispatcher>
    	</filter-mapping>
    	<filter-mapping>
    		<filter-name>PrivateFilter</filter-name>
    		<url-pattern>/META-INF/*</url-pattern>
    		<dispatcher>REQUEST</dispatcher>
    	</filter-mapping>
    Die Filterklasse implementiert das Interface javax.servlet.Filter

    In der Methode doFilter leite ich dann alles auf eine Fehlerseite um:

    Code:
    		httpResp.setContentType("text/html");
    		
    		httpResp.setHeader("Pragma", "no-cache");
    		httpResp.setHeader("Cache-Control","no-store, no-cache");
    		httpResp.setDateHeader("Expires", 0);
    		
    		// then write the data of the response
    		out = resp.getWriter();
    		
    		out.println("<html><head><title>");
    		out.println("Forbidden");
    		out.println("</title></head><body>");
    		out.println("<h2>" + "Forbidden" + "</h2>");
    		out.println("</body></html>");
    (Ist jetzt nur ein Ausschnitt, den ganzen Code, darf ich hier nicht posten, sry)

    Der Aufruf geht nun folgendermaßen:

    index.jsp (bindet blank.jsp und default_content.jsp ein).
    |
    |
    Weiterleitung zu Servlet (bzw. Controller)
    |
    |
    Dispatcher weißt auf eine Standard.jsp welche meine Login-Seite einbindet.
    |
    |
    Login erfolgreich
    |
    |
    Zurück zu Controller
    |
    |
    Weiterleitung wieder auf Standard.jsp welche nun nächste Seite (private/Willkommen.jsp) einbindet.
    |
    |
    Klick auf Funktion
    |
    |
    Zurück zu Controller
    |
    |
    Weiterleitung wieder auf Standard.jsp welche nun nächste Seite (function.jsp) einbindet.
    |
    |
    ...

    Es geht auch einfacher mit weniger jsps, aber so gehe ich in der Praxis vor.

    Ruft nun ein Benutzer eine Seite direkt auf, z.B. private/function.jsp, die im Ordner private liegt, so leitet der Filter ihn auf die Forbidden-Seite um.

    Zusätzlich habe ich noch einen Filter, der auf alles geht, der immer die Session überprüft, ob diese eh != null ist und ein bestimmtes Attribut gesetzt ist.

    Wenn eine der beiden Bedingungen nicht zutrifft, so leite ich ihn ebenfalls auf eine Fehlerseite weiter.

    Ich hoffe ich hab dich jetzt nicht verwirrt, aber das Konzept ist im Grunde immer das gleiche, und funktioniert im Bankenbereich ganz gut.

    Ich bin manchmal nicht gut im Erklären, vor allem wenn man nicht von Angesicht zu Angesicht sprechen kann, aber frag einfach weiter nach.

    mfg, christian
    Spezialitäten heute: PLSQL, TSQL, Java (alles mit Webanwendungen), Groovy, Grails, ASP.NET, Javascript, Python, Django
    Straight through, ohne Umwege ans Ziel

  6. #6
    Registrierter Benutzer
    Registriert seit
    25.10.2005
    Ort
    Hamminkeln
    Beiträge
    302
    Hallo Christian,

    vielen Dank für die Erklärung und den Code. Tatsächlich hatte ich die Zugriffsregelung so vor, wie du es gedacht hast. Schien mir aus meinem Newbie-Blickwinkel ganz passabel. Ich werde mir deinen Code ausdrucken und dann in Ruhe zur Brust nehmen. Waren einige neue Sachen dabei, die ich erstmal bei mir installieren/einrichten und dann ausprobieren muß. Ich arbeite mit der NetBeans-IDE, ich finde sie sehr gut und die Geschichte soll auch noch in Richtung JSF und Beans 3.0 gehen. Allerdings habe ich wie gesagt noch nicht einen umfassenden Einblick, z.b. das Deployment läuft (noch) nicht richtig..., da die Banken mit deiner Zugriffslösung zufrieden sind, und es in ihr Sicherheitskonzept paßt, werde ich es natürlich übernehmen.
    Ich habe gelesen, das beim Posten mit "POST" die Daten verborgen bleiben sollen, aberr das habe ich nicht hinbekommen, ob ich GET oder POST in die Aktion einbinde ist egal, die Daten sind im Browser immer sicht bar.
    Vielen Dank noch mal !!!
    Vereinfacht die Dinge, und ihr erleichtert euch das Leben. (Henry David Thoreau)

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •