Auffälligkeiten Public-Spot-Option in 1781EW

[Transcendence]

Hallo,
ein paar Auffälligkeiten der Public-Spot-Option im 1781EW (LCOS 8.60):

1. Lädt man eine Willkommensseite und eine Login-Seite hoch (nach Anleitung gem. http://www2.lancom.de/kb.nsf/1275/65771 ... enDocument), "kennt" der Router anschließend bei der Anzeige der Willkommensseite noch den aufgerufenen URL, hat ihn jedoch bei der anschließenden Login-Seite "vergessen", so dass nach der Login-Seite sowohl die automatische als auch die manuelle Weiterleitung nur noch zu einer Fehlermeldung führen ("Die URL ist ungültig und kann nicht geladen werden". Gemeint ist "http:///", das der Link zur Weiterleitung auf der Erfolgreich-angemeldet-Seite enthält , was für den Benutzer nicht ohne Weiteres ersichtlich ist). Es gibt weder ein hidden element auf der login-seite noch ein Element im URL, das die Information über die aufgerufene Webseite enthält und zum nächsten Status transportiert.

2. Auch ohne Willkommensseite gleiches Problem, wenn die Zugangsdaten auf der Login-Seite fehlerhaft eingegeben wurden. Spätestens ab der Fehlerseite ist jede Information über die ursprüngliche aufgerufene Webseite "weg" und so läuft der Benutzer auch bei anschließender korrekter Eingabe in die oben beschriebene Fehlermeldung.

Diese Verwirrung und Ins-Leere-Führung des Benutzers ist hoffentlich ein Bug, der behoben wird und kein Feature?

3. Eine Verständnisfrage zu einem anderen Thema: Ist es intentional, dass die Login-Seite nie verschlüsselt wird, sondern (über den Formularaufruf) erst die anschließende Erfolgs- bzw. Misserfolgsseite?

Grüße
T.

[alf29]

Moin,

zu (1) und (2):
Ja, das ist korrekt. Die Original-URL wird über hidden-
Elemente in einer Form transportiert. Wenn man von der einen
zur anderen Seite nicht per Submit einer Form weiterspringt,
sondern über einen einfachen Link, dann kann man da auch
keine hidden-Elemente weiterreichen. Die Alternative wäre,
beim Client einen Cookie zu setzen, aber ein vernünftig
konfigurierter Browser lehnt die auch ab...

Zu (3):
Ja, das ist korrekt. Auf der Login-Seite selber stehen keine
sicherheitsrelevanten Daten, also weshalb das Gerät mit
einer verschlüsselten Verbindung unötig belasten?

Gruß Alfred

[Transcendence]

Hallo alf

Zu (3):
Ja, das ist korrekt. Auf der Login-Seite selber stehen keine
sicherheitsrelevanten Daten, also weshalb das Gerät mit
einer verschlüsselten Verbindung unötig belasten?

Danke, das kann ich als Designentscheidung nachvollziehen.

zu (1) und (2):
Ja, das ist korrekt. Die Original-URL wird über hidden-
Elemente in einer Form transportiert. Wenn man von der einen
zur anderen Seite nicht per Submit einer Form weiterspringt,
sondern über einen einfachen Link, dann kann man da auch
keine hidden-Elemente weiterreichen. Die Alternative wäre,
beim Client einen Cookie zu setzen, aber ein vernünftig
konfigurierter Browser lehnt die auch ab...

Das allerdings nicht mehr, konstruktiv formuliert:

zu (2) - Hier wird ja das vorgegebene Login-Formular mit seinem Submit-Button verwendet. Es enthält die hidden inputs "refreshssl", "refreshhost" und "refreshdir". Diese enthalten zusammen den aufgerufenen URL und werden vom Formular mit übergeben.

Das Lancom könnte diese Daten doch auf der anschließenden Fehlerseite in den Link zurück zur Login-Seite einfach als Parameter mit hineinschreiben, so dass die Daten auf diesem Weg anschließend an den nächsten Schritt übergeben werden könnten? Soetwas ist wirklich simpel zu programmieren, das habe ich für Ergebnisseitenregister einer Suchmaschine selbst schon realisiert und es braucht keinerlei Cookies dafür. Das findet sich beispielsweise auch in den Ergebnisseitenregistern von Google oder anderen Suchmaschinen, die mit Links für den Aufruf von Ergebnisseiten arbeiten ("Seite 1, 2, 3" usw.), da diese Links u.a. Informationen über den Bereich der anschließend anzuzeigenden Ergebnisse enthalten müssen.

So ein Link sähe dann z.B. so aus:

Code: Alles auswählen

<a href="http://host-name-oder-ip-des-1781:80/authen/start/?refreshssl=0&refreshhost=hostname&refreshdir=unterverzeichnis-falls-angegeben">

Diese Parameter könnten dann im nächsten Schritt wieder ausgelesen und ausgewertet werden und ggf. in den nächsten Link als dessen Parameter oder in das nächste Formular als Hidden Input (login-seite) weitergegeben werden usw. usf.

zu (1) - Das Gleiche, auch bei der Abwandlung mit Willkommen-Seite mit Nutzungsbedingungen. Dort wird ja zwar ein Button, aber diesmal als Link und nicht als Teil eines Formulars verwendet.

Grüße
T.

[alf29]

Moin,

Das Lancom könnte diese Daten doch auf der anschließenden Fehlerseite in den Link zurück zur Login-Seite einfach als Parameter mit hineinschreiben, so dass die Daten auf diesem Weg anschließend an den nächsten Schritt übergeben werden könnten? Soetwas ist wirklich simpel zu programmieren, das habe ich für Ergebnisseitenregister einer Suchmaschine selbst schon realisiert und es braucht keinerlei Cookies dafür.

Das mag schon sein, aber dem Programmierer, der diese Login-Geschichichte vor ca.
einem Dutzend Jahren verbrochen hat, hatte sich die Übergabe der Parameter via
GET statt POST seinerzeit noch nicht erschlossen, und mit den Tücken der URL-
Kodierung von Parametern tut er sich gerüchteweise bis heute schwer. Andere Gerüchte
besagen, daß dieser Programmierer bis heute unter dem Pseudonym 'alf29' in Foren
sein Unwesen treibt und an die damaligen Schandtaten nur noch ungerne erinnert
werden möchte...

Gruß Alfred

[Transcendence]

Dann wäre es doch klasse, wenn dieser - sonst gewöhnlich sehr hilfreiche - Programmierer diese heutzutage gut dokumentierten und wirklich nur geringen Zusatzkenntnisse noch erwürbe (ist das grammatisch richtig? ) und einbrächte oder - falls er heute nicht mehr zuständig ist - die heute zuständige Person den entsprechenden Auftrag bekäme.

Das ist ein wirklich geringer Aufwand mit großer Wirkung, der nämlich ein - damals mögen die Dinge durchaus noch anders gelegen haben - heutzutage schon recht unprofessionell wirkendes Usability-Manko in eine professionelle Erfahrung des PS-Benutzers und damit auch in eine professionelle Darstellung des PS-Anbieters (des Lancom-Kunden!) verwandeln würde.

Und eine "ungerne" Erinnerung könnte mit diesem geringen Aufwand ja wieder in eine positive Story verwandelt werden, denn der Rest ist ja durchaus ansprechend und brauchbar gelöst, nur dieses Herumzicken der Vorabseiten nervt und macht heute wirklich keinen guten Eindruck mehr...

Ordentliche Algorythmen zum URL-Encoding sind heute übrigens frei verfügbar, notfalls würde ich auch entsprechendes dazugeben.

Dank von zufriedenen Nutzern wäre dem Forenherumtreiber jedenfalls gewiss.

Grüße
T.

[alf29]

Moin,

Der fragliche Entwickler hat einen halben Tag Urlaub geopfert, um das zu ändern. Kommt mit
dem Nachfolger der 8.60, welche Versionsnummer der auch immer heißen wird...

Gruß Alfred

[Transcendence]

Uiiii DAS nennt man aber mal Einsatz. Da möchte ich mich mal herzlich bedanken!

Ich sah mich schon eine Art externen cgi-wrapper in Perl dafür schreiben. Was deutlich weniger elegant und dazu anfälliger wäre als wenn das direkt im Lancom funktioniert.

Dann freue ich mich also auf die nächste LCOS-Version!

Grüße
T.

[LoUiS]

Hehehe
Cool Alfred!

Hint: Ich kenne da fragliche Entwickler, die sehr offen fuer Goodies in Form von Captain Morgan Flaschen sind.

[Transcendence]

Kein Thema, guter Hint. Urlaubstage sind schließlich wertvoll und Einsatz muss belohnt werden. Ist unterwegs (mangels Privatadresse als persönliche Sendung in die Firma).

Prost! und denkt an ein Gläschen auf mich

Grüße
T.

[Transcendence]

Kommt mit
dem Nachfolger der 8.60, welche Versionsnummer der auch immer heißen wird...

Gruß Alfred

Hm... mit der 8.62 Release von gestern hat sich das *nicht* geändert... :-/

Grüße
T.

[LoUiS]

Hi,

die Aenderungen waren fuer die kurze Zeit bis zur 8.62 leider zu heftig.
Ich denke das wird in die naechste "major" Release kommen.


Ciao
LoUiS