nicht angemeldet
Redirect erst nach Laden der Seite
Hi,
ich hätte eine Frage, die aus noch zu wenig Erfahrung in der jsp-Programmierung kommt. Was ist eleganter?
Ich habe ein Login programmiert. Wenn man sich einloggt kommt man in
login.jsp rein. Tippt man jetzt aber login.jsp einfach so in die linkleiste,
dann soll der Browser wieder zur index.jsp umleiten.
Das habe ich so realisiert:
Ich habe eine session gesetzt nach dem erfolgreichen login. Am Anfang der login.jsp wird geprüft ob diese Session existiert.
Dann musste ich mich zwischen response.redirect und jsp:forward entscheiden.
Beim letzteren werden zwar die parameter mitgeschickt, aber es unterbricht die seite beim laden. Beim ersteren wird die Seite erst geladen und dann findet die weiterleitung statt.
Jetzt wird auf meiner login.jsp Daten aus der Datenbank ausgelesen. Da ist es doch besser, wenn man mit forward weiterleitet, da dann das Auslesen und laden ins HTML unterbrochen wird.
Danke im voraus!
Der Code:
//session nach erfolgreichem login, auf loggeuser.jsp, wird gesetzt
session_.setMaxInactiveInterval(600);
response.sendRedirect("../cm.jsp");
//am anfang der login.jsp wird auf die session geprüft:
<%
HttpSession session_ = request.getSession();
if(session_.getAttribute("login") == null){
%><jsp:forward page="index.jsp" /><%
}
%>
-
hi,
ich hätte eine Frage, die aus noch zu wenig Erfahrung in der jsp-Programmierung kommt. Was ist eleganter?
Ich habe ein Login programmiert. Wenn man sich einloggt kommt man in
login.jsp rein. Tippt man jetzt aber login.jsp einfach so in die linkleiste,
dann soll der Browser wieder zur index.jsp umleiten.Umleitungen sind völlig unelegant ;)
Viel eleganter ist es, wenn ohne ein gültiges Login die Seiten, die einen Login erfordern, den Status 404 Not Found ausgeben, also gar nicht erst erreichbar sind.
Hotti
-
Umleitungen sind völlig unelegant ;)
Viel eleganter ist es, wenn ohne ein gültiges Login die Seiten, die einen Login erfordern, den Status 404 Not Found ausgeben, also gar nicht erst erreichbar sind.
Inwiefern ist das elegant? Das ist nur benutzerunfreundlich.
-
Umleitungen sind völlig unelegant ;)
Viel eleganter ist es, wenn ohne ein gültiges Login die Seiten, die einen Login erfordern, den Status 404 Not Found ausgeben, also gar nicht erst erreichbar sind.
Inwiefern ist das elegant?
Weil damit das ganze Berechtigungssystem komplett aus dem nachfolgenden Code raus ist.
Das ist nur benutzerunfreundlich.
Inwiefern das denn?
Hotti
-
Umleitungen sind völlig unelegant ;)
Viel eleganter ist es, wenn ohne ein gültiges Login die Seiten, die einen Login erfordern, den Status 404 Not Found ausgeben, also gar nicht erst erreichbar sind.
Inwiefern ist das elegant?
Weil damit das ganze Berechtigungssystem komplett aus dem nachfolgenden Code raus ist.
Modulare Programmierung?
Das ist nur benutzerunfreundlich.
Inwiefern das denn?
Du belügst den Benutzer einfach. Du sagst die Ressource ist nicht da, obwohl sie da ist. Das ist eine Lüge.
Entweder schickst du ihm den richtigen Fehlercode oder (und das finde ich die bessere Alternative) du leitest ihn mit einem freundlichen Hinweis auf die Login-Seite und bei einem erfolgreichem Login präsentierst du ihm die angeforderte Ressource.Ich stimme dir allerdings dabei zu, dass Client-seitige Weiterleitungen nervtötend seien können.
-
hi,
Du belügst den Benutzer einfach. Du sagst die Ressource ist nicht da, obwohl sie da ist. Das ist eine Lüge.
Nein. Stichwort Content-Negotiation.
bei einem erfolgreichem Login präsentierst du ihm die angeforderte Ressource.
Spannende Frage: Welche Ressource gilt bei einem erfolgreichen Login als angefordert?
Antwort: Nicht eine einzelne Ressource ist näher klassifiziert sondern der gesamte Content, der aus mehreren Ressourcen bestehen kann, wird nach einem erfolgreichen Login komplett neu ausgehandelt.
Hotti
-
Nein. Stichwort Content-Negotiation.
Schönes Stichwort, aber bedeutungslos bei dieser Debatte.
Spannende Frage: Welche Ressource gilt bei einem erfolgreichen Login als angefordert?
Antwort: Nicht eine einzelne Ressource ist näher klassifiziert sondern der gesamte Content, der aus mehreren Ressourcen bestehen kann, wird nach einem erfolgreichen Login komplett neu ausgehandelt.
Erlaube mir meine Aussage zu korrigieren:
Du leitest ihn mit einem freundlichen Hinweis auf die Login-Seite und bei einem erfolgreichem Login präsentierst du ihm die ursprünglich angeforderte Ressource.
Im Übrigen ist das zum Beispiel die Vorgehensweise von Facebook und anderen renommierten Netzwerken.
Wenn mir ein Freund beispielsweise einen Link zu einem Foto in seinem Facebookalbum schickt und ich ihn anklicke und das obwohl ich nicht eingelogt bin, darf ich mich erst einlogen und dann bekomme ich sofort das Foto zu sehen. Das nenne ich benutzerfreundlich. Wenn Facebook mir stattdessen eine 404-Fehlerseite präsentieren würde, würde ich vermutlich als erstes meinem guten Freund am Puls fühlen und ihn fragen, warum er mir Fantasylinks schickt. Weil 404 eben aussagt, dass es die Seite nicht existiert.
-
hi,
Du leitest ihn mit einem freundlichen Hinweis auf die Login-Seite und bei einem erfolgreichem Login präsentierst du ihm die ursprünglich angeforderte Ressource.
Welche angeforderte Ressource? Wir reden/schreiben aneinander vorbei. Du schreibst von einer angeforderten Ressource, ich schreibe von Content-Negotiation.
Vielleicht hilft ein hinkender Vergleich: Language-Negotiation. Wenn Du meine Website in en anforderst, bekommst Du Seiten in en obwohl es auch de Seiten gibt. Du bekommst, je nach Sprachauswahl, einen komplett anderen Content geliefert, genauso mache ich das auch mit Seiten, die eine Authorization erfordern. Wenn im Browser als bevorzugte Sprache en eingestellt ist, wäre es doch absurd, alle anderen Seiten der anderen Sprachen mit einem Status (?) zu versehen und dann umzuleiten. Programmiertechnisch gesehen, könntest Du genausoo versuchen, aus Quadtraten Kreise zu machen ;)
Im Übrigen ist das zum Beispiel die Vorgehensweise von Facebook und anderen renommierten Netzwerken.
Ach was ;)
Wenn mir ein Freund beispielsweise einen Link zu einem Foto in seinem Facebookalbum schickt und ich ihn anklicke und das obwohl ich nicht eingelogt bin, darf ich mich erst einlogen und dann bekomme ich sofort das Foto zu sehen. Das nenne ich benutzerfreundlich.
Fragwürdige Freundschaften nenne ich das.
Wenn Facebook mir stattdessen eine 404-Fehlerseite präsentieren würde,
Vergleiche hinken. Dein Freund braucht kein FB um Dir ein Foto zu schicken, er muss Dich auch nicht auf eine Seite schicken, die ein Login erfordert und wenn, könnte er Die die Credentials mitteilen.
würde ich vermutlich als erstes meinem guten Freund am Puls fühlen und ihn fragen, warum er mir Fantasylinks schickt. Weil 404 eben aussagt, dass es die Seite nicht existiert.
Wenn Du mit CN arbeitest, Sonderfall Language-Negotiation, könnte es sein, dass auf einundderselben URL ein komplett anderer Content ausgegeben wird. Es kann aber auch sein, dass es einen URL, der auf der en Site vorhanden ist, auf der de Site nicht vorhanden ist, dafür gibt es den Status 404, was denn sonst: Das die Inhalte bereitstellende Programm kennt die Inhalte der anderen Sprachen, sprich die einzelnen namentlichen Seiten gar nicht.
Schließlich: Wenn ich CN für authorisierte Seiten verwende, wird alles ausgetauscht, d.h., eine /index.html im Webroot kann für einen nicht angemeldeten Benutzer was völlig anderes zeigen als einem, der eingeloggt ist, in beiden Fällen wäre der Status 200 OK.
Und überhaupt muss ich nicht jeden Blödsinn nachmachen, den andere machen, es wird auf der öffentlichen Seite ganz einfach keine Links mit Status 40* geben, fertig.
Sch??ne Gr???e,
Hotti--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.-
مرحبا
Vielleicht hilft ein hinkender Vergleich: Language-Negotiation.
Es geht doch um Authentifizierung, was hat Language damit zutun?
Wenn mir ein Freund beispielsweise einen Link zu einem Foto in seinem Facebookalbum
Fragwürdige Freundschaften nenne ich das.Praktiken des 21. Jahrhundert nenne ich das ;)
Dein Freund braucht kein FB um Dir ein Foto zu schicken, er muss Dich auch nicht auf eine Seite schicken, die ein Login erfordert und wenn, könnte er Die die Credentials mitteilen.
So ist das nun mal in einer Welt, in der mehr als 800 Millionen Menschen Facebook nutzen.
Wenn Du mit CN arbeitest, Sonderfall Language-Negotiation, könnte es sein, dass auf einundderselben URL ein komplett anderer Content ausgegeben wird.
Darum würde ich das auch nie benutzen, sondern alles als Alternative Inhalte anbieten, samt Link. Jede URL sollte Idealerweise einen einzigartigen Content haben, diesem Konzept widerspricht aber CN.
Es kann aber auch sein, dass es einen URL, der auf der en Site vorhanden ist, auf der de Site nicht vorhanden ist, dafür gibt es den Status 404, was denn sonst:
Ja, dass ist richtig. Nicht aber bei einer fehlgeschlagenen Authentifizierung, da lautet der Korrekte Fehlercode "Error 401 - Unauthorized!".
Schließlich: Wenn ich CN für authorisierte Seiten verwende, wird alles ausgetauscht,
Du gehörst wohl einer sehr kleinen Gruppe an, wenn du mit CN arbeitest. Gibt es überhaupt Webseiten, die mit CN arbeiten, ausser das W3C (die es wohl auch nur gezwungener maßen machen)?
Und überhaupt muss ich nicht jeden Blödsinn nachmachen, den andere machen
Den richtigen Statuscode einer Seite zu senden war noch nie Blödsinn ;)
Oder schickst du bei Seiten, die es gibt, statt "200 ok" ein "Seite wurde gefunden, yippie"? ;)mfg
-
hi,
Den richtigen Statuscode einer Seite zu senden war noch nie Blödsinn ;)
Richtig. Eine /foo.html wird auch bei mir nur dann einen 404 liefern, wenn es sie nicht gibt. Wobei: Es könnte eine /foo.html geben, wenn ein anderer Content ausgehandelt wurde. Z.B. im Zuge der Language-Negotiation als Sonderfall der Content-Negotiation, die in meinem Framework auch die Authorization abdeckt. Warum sollte ich z.B. auf /index.html einen 401 senden mit dem Hinweis auf nicht angemeldete Besucher: "He tut mir leid, aber in meinem Web ist /index.html nur für authorizierte Benutzer gedacht!"
So benutzerunfreundlich bin ich nun auch wieder nicht ;)
Hotti
PS: Guck Dir mal die w3w Seiten an, wo Gunnar mit übersetzt hat. Die machen das ganz ordentlich mit der Lang.-Negotiation. Und meine Startseite gibts neuerdings auch in fr außer de,en ;)
-
مرحبا
Warum sollte ich z.B. auf /index.html einen 401 senden mit dem Hinweis auf nicht angemeldete Besucher: "He tut mir leid, aber in meinem Web ist /index.html nur für authorizierte Benutzer gedacht!"
Wenn deine Startseite eine Authenitifzierung erfordert, solltest du es dem User mitteilen, oder?
So benutzerunfreundlich bin ich nun auch wieder nicht ;)
Dein Framework, deine Entscheidung ;)
Und meine Startseite gibts neuerdings auch in fr außer de,en ;)
Bei der Französischen Version steht im Header
Content-Language: de, enOb das so richtig ist? Und was ich noch wichtiger finde: wie wechsele ich die Sprache auf deiner Seite, ohne in die Einstellungen meines Browsers zugreifen zu müssen? Deine User wissen nicht einmal, dass es den Content in verschiedenen Sprachen gibt.
Auch Suchmaschinen werden sich schwer tun mit deinem Content, wo unter einer URI möglicherweise 7 Inhalte in 7 Sprachen zu finden sind.
mfg
-
moin,
Wenn deine Startseite eine Authenitifzierung erfordert, solltest du es dem User mitteilen, oder?
Mein Framework arbeitet mit Content-Negotiation (CN) womit ich auch "autorisierte Seiten" abdecke. D.h., alles was Authorization betrifft, ist aus dem Code komplett raus. Oder anders ausgedrückt: Es gibt aus der Sicht des Programmcodes keine Ressourcen, die eine Authorisierung erfordern, die werden alle gleichermaßen ausgeliefert, entweder mit Status 200 oder 404.
Mit CN könnte z.B. sowas gemacht werden:
/index.htm en
/index.htm de
/index.htm fr
/index.htm de/admin
/index.htm en/admin
/index.htm fr/adminHotti
-
Wenn deine Startseite eine Authenitifzierung erfordert, solltest du es dem User mitteilen, oder?
Mein Framework arbeitet mit Content-Negotiation (CN) womit ich auch "autorisierte Seiten" abdecke. D.h., alles was Authorization betrifft, ist aus dem Code komplett raus. Oder anders ausgedrückt: Es gibt aus der Sicht des Programmcodes keine Ressourcen, die eine Authorisierung erfordern, die werden alle gleichermaßen ausgeliefert, entweder mit Status 200 oder 404.
Deine Antwort ist also, dass die Archtitektur deines Frameworks es nicht erlaubt bedeutungsvolle Fehlercodes zu senden?
Wo ist der Vorteil daran, dass dein Programmcode keinen Bezug zu deinem Authentifizierungssystem hat? Klar Codetrennung ist wichtig, aber ich glaube da bist du übers Ziel hinausgeschossen.
Ich finde deinen Ansatz ja hoch interessant, aber mir erschließt sich einfach kein Vorteil daraus. Vielleicht kannst du mir ja auf die Sprünge helfen, vielleicht sehe ich einfach den Baum vor lauter Wäldern nicht.-
hi,
Ich finde deinen Ansatz ja hoch interessant, aber mir erschließt sich einfach kein Vorteil daraus. Vielleicht kannst du mir ja auf die Sprünge helfen, vielleicht sehe ich einfach den Baum vor lauter Wäldern nicht.
Ein Beispiel wäre evntl. gut, einmal ein Gefühl für diesen verrückten Kram zu vermitteln ;)
Authorization over Content-Negotiation.
Mein bisheriger Code kann natürlich bleiben, das sind nur zwei Methoden in der Basisklasse. Es ist nur eine weitere Möglichkeit...Hotti
--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.-
مرحبا
Ein Beispiel wäre evntl. gut, einmal ein Gefühl für diesen verrückten Kram zu vermitteln ;)
Dein Framework schickt eine ganze menge falscher header. Wenn du mit Englisch im Browser dein Gastlogin ansteuerst, steht im HTML
<html lang="en">
Was aber nicht korrekt ist, weil auf der Seite der Hinweis erscheint:
<cite>Fehler: Die angeforderte Seite gibt es nicht ...</cite>Das nächste, weiterhin im Gastlogin (unter dem Login-Formular):
<cite>This page is also available in English, please select your preferred language from the browser.</cite>
Stimmt nicht, siehe meinen vorangehenden Absatz.Login erfolgreich, im HTML steht:
<html lang="de">
im header der Seite steht allerdings: Content-Language: de, enDas sind Augenscheinlich nur kleinigkeiten, aber du weisst ja, Kleinvieh macht auch Mist (und ich habe den Gastlogin nur überflogen).
mfg
-
hi,
Ein Beispiel wäre evntl. gut, einmal ein Gefühl für diesen verrückten Kram zu vermitteln ;)
Dein Framework schickt eine ganze menge falscher header. Wenn du mit Englisch im Browser dein Gastlogin ansteuerst, steht im HTML
<html lang="en">
Was aber nicht korrekt ist, weil auf der Seite der Hinweis erscheint:
<cite>Fehler: Die angeforderte Seite gibt es nicht ...</cite>Das ist vollkommen korrekt: In en gibt es diese Seite (/gastlogin.html) nicht, der Header Status: 404 stimmt also. Nur den Body-Text muss ich noch übersetzen ;)
Login erfolgreich, im HTML steht:
<html lang="de">
im header der Seite steht allerdings: Content-Language: de, enLt. RFC darf Content-Language mehrere Einträge enthalten.
Hotti
-
-
-
-
-
-
-
[latex]Mae govannen![/latex]
Und überhaupt muss ich nicht jeden Blödsinn nachmachen, den andere machen
Den richtigen Statuscode einer Seite zu senden war noch nie Blödsinn ;)
Oder schickst du bei Seiten, die es gibt, statt "200 ok" ein "Seite wurde gefunden, yippie"? ;)Der Status-Header muss wie auf folgender Seite gesetzt sein http://test.knrs.de/zweinullnull/ ;)
Stur lächeln und winken, Männer!
Kai--
It all began when I went on a tour, hoping to find some furniture
Followed a sign saying "Beautiful Chest", led to a lady who showed me her best)
SelfHTML-Forum-Stylesheet
-
-
-
-
-
-
-
-
مرحبا
Viel eleganter ist es, wenn ohne ein gültiges Login die Seiten, die einen Login erfordern, den Status 404 Not Found ausgeben, also gar nicht erst erreichbar sind.
Wenn dann würde ich einen "Error 401 - Unauthorized!" ausgeben. Die Seite gibt es ja (da ist 404 eh falsch), nur erfordert diese eine Authentifizierung. Mit einem 404er verwirrst du den User nur. Das hat dann auch nichts mehr mit Benutzerfreundlich zutun.
mfg
-
hi,
ich hätte eine Frage, die aus noch zu wenig Erfahrung in der jsp-Programmierung kommt. Was ist eleganter?
Ich habe ein Login programmiert. Wenn man sich einloggt kommt man in
login.jsp rein. Tippt man jetzt aber login.jsp einfach so in die linkleiste,
dann soll der Browser wieder zur index.jsp umleiten.Umleitungen sind völlig unelegant ;)
Naja, ganz ohne Umleitungen gehts auch nicht immer. Aber die Möglichkeit, authorisierte Seiten über Content-Negotiation laufen zu lassen, zeige ich gerne mal in einer Demo, einloggen als Benutzer: gast, Passwort: gast.
Nach dem Einloggen wird der bisherige Content der gesamten Website komplett ausgetauscht, es gibt faktisch nur noch zwei Ressourcen (als Beispiel).
Hotti
-
Wie schon hier erwähnt erschließt sich mir daraus kein Vorteil.
Gut der gesamte Content wird ausgetauscht. Aber das allein ist doch noch kein Vorteil gegenüber herkömmlichen Authentifizierungssystemen. Wo liegen die Vorteile beim Endnutzer, wo liegen die Vorteile beim Entwickler?
-
Wie schon hier erwähnt erschließt sich mir daraus kein Vorteil.
Gut der gesamte Content wird ausgetauscht. Aber das allein ist doch noch kein Vorteil gegenüber herkömmlichen Authentifizierungssystemen. Wo liegen die Vorteile beim Endnutzer, wo liegen die Vorteile beim Entwickler?
Z.B. können Seiten/Anwendungen für administrative Zwecke parallel zu anderen Anwendungen entwickelt werden, ohne dass sich die Entwickler gegenseitig behindern oder voneinander abhängig sind.
Der Anwender kann sich auch auf das Wesentliche konzentrieren...
Und der Kompiler (Perl-Interpreter, PHP-Parser) kriegt auch weniger zu tun.
Hotti
--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.-
Z.B. können Seiten/Anwendungen für administrative Zwecke parallel zu anderen Anwendungen entwickelt werden, ohne dass sich die Entwickler gegenseitig behindern oder voneinander abhängig sind.
Das kann ich auch durch modulare Programmierung erreichen.
Und der Kompiler (Perl-Interpreter, PHP-Parser) kriegt auch weniger zu tun.
Das ist wirklich mal ein Argument, allerdings wird die Arbeit natürlich nur direkt an den Server weiter gereicht. Benchmark-Tests wären hier sinnvoll.
Wie verhält es sich, wenn ich mehrere Seiten mit deinem Framework auf einen Server installieren will? Kommt es da eventuell zu Interferenzen?
Finde deine Idee wirklich hochinteressant. Würde mich freuen, darüber mal was detailtiertes zu lesen. Vielleicht hast du ja mal Zeit was dazu zu verfassen. Deine Homepage liefert leider nur sperrliche Informationen.
-
hi,
Wie verhält es sich, wenn ich mehrere Seiten mit deinem Framework auf einen Server installieren will? Kommt es da eventuell zu Interferenzen?
Es kommt eher zu synergie-Effekten ;)
Content-Negotiation (CN) macht den Code auch noch multi-Domain-fähig. Also über die gesamte Tragweite der CN bin ich mir da selbst noch nicht ganz im Klaren... das muss ich mal überschlafen ;)
Fakt ist: Authorization kann ich in meinem FW auch über Attribute regeln, was natürlich auch die hier erwähnten Stati z.B. 401 ermöglicht, diese Möglichkeiten gibt es nach wie vor und selbst das ist vom Code weitgehend getrennt.
Installation: Das FW kannst Du enweder komplett in Perl oder komplett in PHP einsetzen oder Beides verwenden. Von den Systemvoraussetzungen ist es total anspruchslos und im Handumdrehen aufgespielt, hier eine weitere Domäne, wo das läuft: für meine Kinder gemacht und da ist alles in PHP (ist ja nicht viel, bis jetzt jedenfalls).
Hotti
-
Ob das alles gut oder schlecht ist, mag ich noch nicht beurteilen. Auf jedenfall ist es interessant und ich werd hin und wieder mal ein Blick auf deine Seite werfen. Ich entwickle seit geraumer Zeit nur noch für NodeJS-Server, also wirds wohl kaum vorkommen, dass ich dein Framework mal benutze, aber viel Erfolg damit. Nebenbei gefragt: Was sind deine Ziele für das Framework? Ich konnte auf der Homepage keine Angaben zu Preisen und Lizenzen finden.
-
-
-
-
-
-