nicht angemeldet
Gunnar Bittersmann
MudGuard
MudGuard
Der Martin
MudGuard
Gunnar Bittersmann
Auge
Hallo Fachwelt,
sagen wir, ich habe eine website auf der ich den Hash benutze, um Positionen in Videos zu verlinken. Beispiel:
link: example.com/schedule/date/watch?date=2015-01-16#51ck1k3pl
springt zu einer gewissen Stelle im Video. Eine DB enthält die Zuordnung event id (51ck1k3pl) und zugehöriges Video und Zeitstempel. Programmiertechnisch geht das so: die Seite gibt eine Liste an Links aus (e.g. <a data-ts="1401351251" data-eventid="51ck1k3pl">Event xyz</a>) und eine JS Funktion klickt diesen Link, wenn ein Hash in der URL gefunden wird woraufhin das Video springt. Alles schön sauber in den Callbacks platziert.
So weit so gut, funktioniert auch alles.
Jetzt das Problem: die Seite ist nur für angemeldete Nutzer sichtbar. Wenn ein Link verschickt wird, per Email bspw., landet der Nutzer auf einer Loginform. Nach erfolgreichem Login werden alle URL parameter wieder an die Weiterleitungsurl gehängt. Zum richten Datum kommt man also. Allerdings geht der Hash verloren! Nach kurzer Suche fand ich: es gibt keine Möglichkeit den Hash mit php zu bekommen, da er nicht zum Server gesendet wird. Niemals.
Möglichkeiten:
a) ich nehme für die Videopositionen keine Hashs, sondern auch einen URL parameter
example.com/schedule/date/watch?date=2015-01-16?eventid=51ck1k3pl
b) ich benutze für den Login einen Ajaxlogin, d.h. ich muss die Seite nicht verlassen und die URL bleibt so stehen?!? (nicht sicher, ob das gelingt)
c) Auf der Loginformseite schicke ich einen AJAX request zum server los, der den Hash als GET parameter zum Server sendet. Dort wird sie bswp. in einer SESSION-Variable bis zur Weiterleitung aufgehoben.
d) ?
Meine Frage:
Was wäre für euch die beste Lösung in diesem Falle? Irgendwie mag ich es semantisch, dass ich für Positionen in einem Video ein Hash benutze. Daher scheue ich mich ein bisschen vor a).
Viele Grüße,
Baba
@@Baba:
nuqneH
link: example.com/schedule/date/watch?date=2015-01-16#51ck1k3pl
Warum nicht wie im Standard vorgesehen?
Also example.com/schedule/date/watch?date=2015-01-16#id=51ck1k3pl
▲▲▲
Qapla'
Oh, schön. Antworten!
Warum nicht wie im Standard vorgesehen?
Also example.com/schedule/date/watch?date=2015-01-16#id=51ck1k3pl
▲▲▲
Ja, gerne. Aber das Problem bleibt doch das gleiche...
Cheers,
Baba
Hi,
Warum nicht wie im Standard vorgesehen?
Also example.com/schedule/date/watch?date=2015-01-16#id=51ck1k3pl
Was Baba bräuchte, wäre, daß der Fragment Identifier an den Server übermittelt wird, damit er ihn an den Weiterleitungs-Link anhängen kann.
Das scheitert aber daran, daß der Fragment Identifier, auch wenn er media-frags-konform ist, an den Server übermittelt wird.
cu,
Andreas
Was Baba bräuchte, wäre, daß der Fragment Identifier an den Server übermittelt wird, damit er ihn an den Weiterleitungs-Link anhängen kann.
Das scheitert aber daran, daß der Fragment Identifier, auch wenn er media-frags-konform ist, an den Server übermittelt wird.
exactamente.
Cheers,
Baba
Hi,
Was Baba bräuchte, wäre, daß der Fragment Identifier an den Server übermittelt wird, damit er ihn an den Weiterleitungs-Link anhängen kann.
Das scheitert aber daran, daß der Fragment Identifier, auch wenn er media-frags-konform ist, an den Server übermittelt wird.exactamente.
ne - da fehlt ein "nicht" am Anfang des letzten Satzteils.
cu,
Andreas
ne - da fehlt ein "nicht" am Anfang des letzten Satzteils.
Leute. Ich habe es MIT der Verneinung gelesen, auch wenns nicht dasteht. Darauf bin ich schon im OP eingegangen.
Cheers,
Baba
Hallo,
Das scheitert aber daran, daß der Fragment Identifier, auch wenn er media-frags-konform ist, an den Server übermittelt wird.
hier fehlt wohl im zweiten Halbsatz eine Verneinung?
Ciao,
Martin
Hi,
Hallo,
Das scheitert aber daran, daß der Fragment Identifier, auch wenn er media-frags-konform ist, an den Server übermittelt wird.
hier fehlt wohl im zweiten Halbsatz eine Verneinung?
Siehe andernorts
cu,
Andreas
Mahlzeit,
Was wäre für euch die beste Lösung in diesem Falle?
Das zu nehmen, was dafür gedacht ist. Also einen Parameter, den du an den Server übergibst.
Irgendwie mag ich es semantisch, dass ich für Positionen in einem Video ein Hash benutze.
Ich halte es nicht für semantisch, wenn es falsch ist, ich halte es für falsch wenn es falsch ist.
Daher scheue ich mich ein bisschen vor a).
Viele scheuen sich, das Richtige zu tun, deshalb gibt es auch so viel auf der Welt was nicht funktioniert, wie deine Webseite nach einem Login ;)
@@M.:
nuqneH
Irgendwie mag ich es semantisch, dass ich für Positionen in einem Video ein Hash benutze.
Ich halte es nicht für semantisch, wenn es falsch ist, ich halte es für falsch wenn es falsch ist.
Es ist aber richtig.
Qapla'
Mahlzeit,
Es ist aber richtig.
Du verlinkst mir deinen Beitrag, indem du selbst sagst, der Standard sieht anders aus und mir erklärst du es wäre richtig? Nein, das verstehe ich nicht.
Wenn es richtig ist, ist dein verlinkter Beitrag falsch.
@@M.:
nuqneH
Es ist aber richtig.
Du verlinkst mir deinen Beitrag, indem du selbst sagst, der Standard sieht anders aus und mir erklärst du es wäre richtig? Nein, das verstehe ich nicht.
Mit „richtig“ meinte ich hier die Verwendung eines Fragment-Identifiers #… als solche.
Und für einen Media-Fragment-Identifier war der von Baba (example.com/schedule/date/watch?date=2015-01-16#51ck1k3pl) nicht richtig.
Dabei bin ich davon ausgegangen, dass example.com/schedule/date/watch?date=2015-01-16 der URI des Videos ist; nicht der einer Seite, in der ein Video eingebettet ist. Im zweiten Falle wäre die Diskussion um die Fragment-Identifier hier müßig.
Qapla'
Mahlzeit,
Nachtrag:
Es ist aber richtig.
Wenn es richtig ist, also für den Zweck des OP geeignet, wieso werden diese Daten nicht an den Server übertragen? Entweder ist deine Aussage falsch oder die Implementierung fehlerhaft.
Also erklär mal, was jetzt zutrifft. Bin schon gespannt.
@@M.:
nuqneH
Wenn es richtig ist, also für den Zweck des OP geeignet, wieso werden diese Daten nicht an den Server übertragen?
Nicht geeignet ist eher der Ansatz des OP mit der Weiterleitung. Ich glaube, ich stimme hier mal mit hotti überein.
Ich glaube, das ist einen Eintrag in den Kalender wert. ;-)
Qapla'
Vielen Dank für die Reaktivierung (auch an M.). Ich war auch noch sehr auf eine Auflösung gespannt.
Mich beschleicht das Gefühl, dass dies
Nicht geeignet ist eher der Ansatz des OP mit der Weiterleitung.
und dies
Ich glaube, ich stimme hier mal mit hotti überein.
nur das Gleiche ist, wenn man die Antwort schon kennt. Ich tappe immernoch einigermaßen im Dunkeln und werde weder aus dem Einen noch dem Anderen schlau.
Also: wenn ich nun auf die Resource zugreife, nicht eingeloggt bin und die Loginform sehe soll *was* geschehen, damit ich keine Weiterleitung benötige? Mir fällt dazu nur ein, dass ich a) keine Loginform anbiete, gut, das löst natürlich das Problem oder b) dass ich das action Attr. der Form auf die Ressource umschreibe (statt "/account/login") und per JS den Hash wieder anhänge.
Vielen Dank,
Baba
Hakuna matata!
Also: wenn ich nun auf die Resource zugreife, nicht eingeloggt bin und die Loginform sehe soll *was* geschehen, damit ich keine Weiterleitung benötige? Mir fällt dazu nur ein, dass ich a) keine Loginform anbiete, gut, das löst natürlich das Problem oder b) dass ich das action Attr. der Form auf die Ressource umschreibe (statt "/account/login") und per JS den Hash wieder anhänge.
Option c) Du lässt action-Attribut im <form>-Tag einfach weg. Ein Abschicken des Formulares bewirkt dann, dass das Formular an die selbe Adresse geschickt wird. Der Hash in der Adresszeile bleibt erhalten.
Option c) Du lässt action-Attribut im <form>-Tag einfach weg. Ein Abschicken des Formulares bewirkt dann, dass das Formular an die selbe Adresse geschickt wird. Der Hash in der Adresszeile bleibt erhalten.
Halleluja!
Tausend Dank,
Baba
Hallo
Meine Frage:
Was wäre für euch die beste Lösung in diesem Falle?
Der URL-Parameter, also a), wäre mir das Passende.
Irgendwie mag ich es semantisch, dass ich für Positionen in einem Video ein Hash benutze. Daher scheue ich mich ein bisschen vor a).
Der Hash referenziert ein Sprungziel im Dokument oder einen Fensternamen (was man so alles wegen Nichtnutzung vergisst). Mit ein wenig gutem Willen kann man eine Position in einem Video ebenso als Sprungmarke bezeichnen (was wohl deine Intention ist). Allerdings befindet sich das Video nicht *direkt* im Dokument, sondern ist nur dorthinein eingebunden. Von daher halte ich den Hash an dieser Stelle nicht für das richtige Mittel.
Tschö, Auge
Hi,
Der Hash referenziert ein Sprungziel im Dokument oder einen Fensternamen
#fenstername ???
Wie kommst Du darauf?
Dein Link zeigt auf's target-Attribut, was nichts mit dem # in der Url zu tun hat.
cu,
Andreas
Hallo
Der Hash referenziert ein Sprungziel im Dokument oder einen Fensternamen
#fenstername ???
Wie kommst Du darauf?
Was fragst du mich denn #das?
Dein Link zeigt auf's target-Attribut, was nichts mit dem # in der Url zu tun hat.
Öhhm, ja, nöö. Verwirrt, also ich.
Tschö, Auge
Hallo Fachwelt,
Jetzt das Problem: die Seite ist nur für angemeldete Nutzer sichtbar. Wenn ein Link verschickt wird, per Email bspw., landet der Nutzer auf einer Loginform. Nach erfolgreichem Login werden alle URL parameter wieder an die Weiterleitungsurl gehängt.
Falls der Referrer überhaupt mitkommt, ist das Fragment so oder so weg.
Was wäre für euch die beste Lösung in diesem Falle?
Ein Login-System so bauen, dass Webressourcen, die einer Zugangskontrolle unterliegen, an einen bestimmten, idealerweise frei konfigurierbaren Realm (Benutzergruppe) gebunden sind, wobei solche URLs nach dem Request weder einen unauthorized- noch einen location-Header senden sondern einfach nur mit HTTP-Status-Code 200 denjenigen Content auslieferen, der für eine bestimmte Benutzergruppe vorgesehen ist.
MfG
Ein Login-System so bauen, dass Webressourcen, die einer Zugangskontrolle unterliegen, an einen bestimmten, idealerweise frei konfigurierbaren Realm (Benutzergruppe) gebunden sind, wobei solche URLs nach dem Request weder einen unauthorized- noch einen location-Header senden sondern einfach nur mit HTTP-Status-Code 200 denjenigen Content auslieferen, der für eine bestimmte Benutzergruppe vorgesehen ist.
Langer Satz.
Ein Login-System so bauen, dass Webressourcen, die einer Zugangskontrolle unterliegen, an einen bestimmten, idealerweise frei konfigurierbaren Realm (Benutzergruppe) gebunden sind,
check
wobei solche URLs nach dem Request
welchen Request meinst Du? Ich gehe im Folgenden davon aus, dass Du den Request auf die Resource mit der Zugangskontrolle
weder einen unauthorized- noch einen location-Header senden sondern einfach nur mit HTTP-Status-Code 200 denjenigen Content auslieferen, der für eine bestimmte Benutzergruppe vorgesehen ist.
Tun sie doch. Schreibe ich irgendwo was Gegenteiliges?
Cheers,
Baba
@@Baba:
nuqneH
einfach nur mit HTTP-Status-Code 200 denjenigen Content auslieferen, der für eine bestimmte Benutzergruppe vorgesehen ist.
Tun sie doch. Schreibe ich irgendwo was Gegenteiliges?
Ich glaub schon: „Nach erfolgreichem Login werden alle URL parameter wieder an die Weiterleitungsurl gehängt.“
Warum eine Weiterleitung?
Qapla'
Ich glaub schon: „Nach erfolgreichem Login werden alle URL parameter wieder an die Weiterleitungsurl gehängt.“
Warum eine Weiterleitung?
Beispiel:
example.com/schedule/date/watch?date=2015-01-16#51ck1k3pl
eingeloggt: http status 200 -> alles Schicki
nicht eingeloggt: http status 401 -> Loginform statt content. Action attr = /account/login (Alle URL parameter in Session variable)
Dort angegkommen validiert: per Weiterleitung zum Ursprünglichen Ziel.
Ist das generell schlecht? Sollte das Loginformular besser gleich auf der Adresse bleiben? Von den http-stati her ist es glaub eich ok.
Cheers,
Baba
hi,
wobei solche URLs nach dem Request
welchen Request meinst Du? Ich gehe im Folgenden davon aus, dass Du den Request auf die Resource mit der Zugangskontrolleweder einen unauthorized- noch einen location-Header senden sondern einfach nur mit HTTP-Status-Code 200 denjenigen Content auslieferen, der für eine bestimmte Benutzergruppe vorgesehen ist.
Möglicherweise ist hier schon das Missverständnis, ich meinte: Nicht der URL unterliegt der Zugangskontrolle, sondern der Content.
MfG
Möglicherweise ist hier schon das Missverständnis, ich meinte: Nicht der URL unterliegt der Zugangskontrolle, sondern der Content.
Gut. Was aber bedeutet das. Es ist nunmal so, dass unter der gleichen URL sich einmal ein Dokument verbirgt mit dem Status 200 (wenn eingeloggt) oder 401 (wenn nicht eingeloggt). Das liegt in der Sache.
verliert langsam den Faden,
Baba
Möglicherweise ist hier schon das Missverständnis, ich meinte: Nicht der URL unterliegt der Zugangskontrolle, sondern der Content.
Gut. Was aber bedeutet das. Es ist nunmal so, dass unter der gleichen URL sich einmal ein Dokument verbirgt mit dem Status 200 (wenn eingeloggt) oder 401 (wenn nicht eingeloggt). Das liegt in der Sache.
Genau das ist das Problem: HTTP kennt kein Login/Logout. Das musst Du Dir selbst bauen.
Hotti
Genau das ist das Problem: HTTP kennt kein Login/Logout. Das musst Du Dir selbst bauen.
I'm out.
Falls der Referrer überhaupt mitkommt, ist das Fragment so oder so weg.
Das weiß ich. Das war die Ursprungsproblematik.
Ein Login-System so bauen, dass Webressourcen, die einer Zugangskontrolle unterliegen, an einen bestimmten, idealerweise frei konfigurierbaren Realm (Benutzergruppe) gebunden sind, wobei solche URLs nach dem Request weder einen unauthorized- noch einen location-Header senden sondern einfach nur mit HTTP-Status-Code 200 denjenigen Content auslieferen, der für eine bestimmte Benutzergruppe vorgesehen ist.
Und was kriegen nicht angemeldete Nutzer, wenn es absolut keinen Content für diese gibt? Bei mir eine Form und einen 401.
Cheers,
Baba
