Passwortabfrage bei POST

[pl]

s. Thema. Also ich würde mir das gerne mal angucken wie das geht, daß bei einem POST (z.B. Forum) eine Passwortabfrage kommt. Also nur beim POST und das soll auch über AJAX funktionieren. Unter Passwortabfrage soll der übliche Prompt für eine Authorization Basic verstanden werden.

MFG

[Felix Riesterer]

Lieber pl,

für eine Authorization Basic

Deine URL ist ein String der Form http://user:[e-mail]/pfad/datei:

GET /pfad/date HTTP/1.1
Host: exaple.org
Authorization: Basic dXNlcjpwYXNz

Der Authorization-Header benötigt einen String in Base64-Kodierung, bei dem Benutzername und Passwort mit einem Doppelpunkt separiert sind. So erklärt sich das obige dXNlcjpwYXNz (kannste mit unseren Helferlein selber testen).

Liebe Grüße

Felix Riesterer

[Felix Riesterer]

Ach ja... POST war gefragt. Nun ja, da bin ich mir sicher, dass Du den Header entsprechend dort einsetzt.

Liebe Grüße

Felix Riesterer

[Der Martin]

Hallo Felix,

Deine URL ist ein String der Form http://user:[e-mail]/pfad/datei:

diese Notation gilt schon lange als missbilligt^[1] und wird von den derzeitigen Browsern nur noch widerwillig akzeptiert - das heißt: Bei der direkten Eingabe in der Adressleiste mit einem Warnhinweis, in einem Link AFAIK gar nicht mehr.

Davon abgesehen glaube ich nicht, dass Hotti das gemeint hat. Ich habe ihn eher so verstanden, dass er eine Server-Konfiguration erstellen möchte, die GET-Requests ohne Einschränkung bedient, bei POST-Requests aber eine Authentifizierung fordert.

Ich würde vermuten, dass man da für denselben VHost zwei Konfigurations-Blöcke vorsehen sollte und mit der Limit-Direktive unterscheidet. Ist mir aber ehrlich gesagt im Moment nicht spannend genug, dass ich mich selbst da reinknien möchte.

GET /pfad/date HTTP/1.1
Host: exaple.org
Authorization: Basic dXNlcjpwYXNz

Der Authorization-Header benötigt einen String in Base64-Kodierung, bei dem Benutzername und Passwort mit einem Doppelpunkt separiert sind.

Ja. Spielst du darauf an, so einen Request mit Javascript (vulgo "AJAX") zu bauen? - Ich denke, auch bei einem AJAX-Request müsste ein Browser den Nutzer zur Eingabe der Zugangsdaten auffordern, wenn eine 401-Response kommt. Damit wäre das Selberbauen dann unnötig.

Ciao,
 Martin

---

1. Jedenfalls in HTTP(S). In FTP ist diese Syntax dagegen offizieller Teil der Spezifikation. ↩︎

[Felix Riesterer]

Lieber Martin,

Davon abgesehen glaube ich nicht, dass Hotti das gemeint hat. Ich habe ihn eher so verstanden, dass ...

leider formuliert @pl dermaßen ungenau, dass ich schon fast nicht mehr auf seine Frage antworten wollte. Was genau soll man sich unter s. Thema eigentlich als Problembeschreibung vorstellen? Und ein Thema ist keine Beschreibung, sondern bestenfalls ein Titel. Und der lautet Passwortabfrage bei POST - von einer Beschreibung eines Problems keine Spur.

Immerhin schreibt er:

mal angucken wie das geht, daß bei einem POST (z.B. Forum) eine Passwortabfrage kommt. Also nur beim POST und das soll auch über AJAX funktionieren.

Es soll also bei einem POST-Request eine "Passwortabfrage" kommen. Er nennt auch Authorization Basic als Kontext. Daraus schließe ich, dass er will, dass wenn der Browser (z.B. via Ajax, aber auch ohne Ajax) einen POST-Request sendet, das übliche modale Browser-Dialogfenster zum Eingeben der Zugangsdaten anzeigt.

Mir ist nicht klar, wie man anders die Logindaten senden will, als über eine passende URL-Struktur. Bei Ajax-Calls kann man die Header direkt definieren, womit man die missbilligte Notation der URL dort nicht benötigt.

Keine Ahnung, wofür @pl das braucht, was er da konkret zu erreichen sucht und ob ihm meine Antwort überhaupt weiterhilft. Letzten Endes ist es ja sein Problem und nicht meines. Wenn er etwas anderes gebraucht hätte, wird er sich sicherlich melden.

Liebe Grüße

Felix Riesterer

[Der Martin]

Guten Abend,

leider formuliert @pl dermaßen ungenau, dass ich schon fast nicht mehr auf seine Frage antworten wollte.

ja, das kann ich nachvollziehen. Seine angeschlagene Gesundheit mahnt uns zwar zu etwas Nachsicht, aber ich gebe zu, es ist schwer, ihn zu verstehen, geschweige denn, mit ihm zu kommunizieren.

Was genau soll man sich unter s. Thema eigentlich als Problembeschreibung vorstellen? Und ein Thema ist keine Beschreibung, sondern bestenfalls ein Titel. Und der lautet Passwortabfrage bei POST - von einer Beschreibung eines Problems keine Spur.

Ja. Das Problem muss man erraten.

Es soll also bei einem POST-Request eine "Passwortabfrage" kommen. Er nennt auch Authorization Basic als Kontext.

Also HTTP-Authentication, Auth-Type:Basic.

Daraus schließe ich, dass er will, dass wenn der Browser (z.B. via Ajax, aber auch ohne Ajax) einen POST-Request sendet, das übliche modale Browser-Dialogfenster zum Eingeben der Zugangsdaten anzeigt.

Genau. Und dein Lösungsansatz beschreibt einen Weg, wie man sozusagen proaktiv das Abfragen der Credentials verhindert, quasi als Komfort-Feature.

Mir ist nicht klar, wie man anders die Logindaten senden will, als über eine passende URL-Struktur.

Eigentlich so, wie du es schon beschrieben hast: Mit entsprechenden HTTP-Headern. Nur dass ich mich nicht selbst darum kümmern würde, sondern das lieber dem Browser überlasse.

Bei Ajax-Calls kann man die Header direkt definieren, womit man die missbilligte Notation der URL dort nicht benötigt.

Ja. Das meinte ich mit proaktiv: Du willst die Login-Daten ungefragt direkt mitschicken, bevor überhaupt die Abfrage aufpoppt.

Wenn er etwas anderes gebraucht hätte, wird er sich sicherlich melden.

Nein. Er wird uns erklären, dass wir völlig auf dem Holzweg sind, weil er in Wirklichkeit was ganz anderes gemeint hat, was wir mit unserer begrenzten Intelligenz nicht verstanden haben. :-D

Ciao,
 Martin

PS: Eventuelle Tippfehler stammen mutmaßlich aus zwei Bierflaschen und zwei Schluck Wodka.

[pl]

s. Thema. Also ich würde mir das gerne mal angucken wie das geht, daß bei einem POST (z.B. Forum) eine Passwortabfrage kommt. Also nur beim POST und das soll auch über AJAX funktionieren. Unter Passwortabfrage soll der übliche Prompt für eine Authorization Basic verstanden werden.

Also ich frage mich wie das die bekannten Frameworks machen. Ich habe z.B. meine Foren z.Z. auf readonly gesetzt, so kommt beim POST der Prompt. Bei mir ist das nur eine Zeile:

if( $this->rdonly() && ! $this->_authbasic() ){ return; }

Und das wird per Konfiguration ein/aus geschaltet.

Wie machen das Symfony & Co? MFG

[pl]

Wie machen das Symfony & Co?

Mir persönlich wurde hier im Forum Symfony empfohlen. Also habe ich mir mal ein Feature rausgepickt, was mit einem Framwework einfach machbar sein sollte. Nur habe ich das bei Symfony nicht gefunden, deswegen frage ich hier. MFG

[Raketenwissenschaftler]

Ich würde zunächst einmal von http-auth Abstand nehmen, weil die Passwort-Hash-Methoden der oder des Webservers nicht unbedingt Weltspitze sind.

Wo ist das Problem im Falle gesendeter Daten nach einer Session mit einem gültigen Login zu schauen und diese ggf. durch eine Passwortabfrage zu initialisieren? Man kann auch danach noch zum vorherigen Schritt zurück gehen und dort weitermachen, wo das fehlende Login aufgefallen ist.

Wie machen das Symfony & Co?

Hoffentlich richtig. Fragt sich, wer es dann wie implementiert.

[Proghorst]

Auth Basic habe ich auch erst nachträglich in mein FW eingebaut, das ursprüngliche Konzept der Anmeldung ist aber auch umgesetzt und in Anwendung.

Wie machen das Symfony & Co?

Hoffentlich richtig. Fragt sich, wer es dann wie implementiert.

Und wo sie es dokumentiert haben und wie lange man dafür braucht denen ihren Implementationismus zu verstehen. Und es sollte natürlich nicht nur auf POST beschränkt sein, es solle auch bei GET funktionieren.

MFG

[pl]

Ich habe auch schon CMS gesehen, da kommt beim Umschalten in den Editmodus einer Seite die Passwortabfrage. Bspw. beim Parameter /seite.html?edit=123

Und natürlich gibt es weitere Fälle wo man sowas macht. Aber das war dann wohl nicht Dein CMS oder? MFG

[Raketencmsstrickmusterentwerfer]

Und natürlich gibt es weitere Fälle wo man sowas macht. Aber das war dann wohl nicht Dein CMS oder? MFG

Nein. Da ist das ganz anders geregelt. Es gibt eine simple, strikte und also leicht beherrschbare Trennung zwischen der Webseite und dem Admin-Bereich. Per Ordner.

[pl]

Ich würde zunächst einmal von http-auth Abstand nehmen, weil die Passwort-Hash-Methoden der oder des Webservers nicht unbedingt Weltspitze sind.

Authorization Basic hat mit Hash-Methoden gar nichs zu tun.

Und im Gegensatz zu einem Login mit Session, ist Auth Basic wesentlich einfacher zu realisieren. Eines sollte man jedoch auch beachten, nämlich daß Auth Basic an den URL gebunden ist und nicht an den Inhalt.

Von daher könnte ich meine Frage hier auch so formulieren: Wie bindet man Auth Basic an den Inhalt? Bspw. so, daß ein URL ohne Parameter ohne Passwort zugänglich ist, mit bestimmten Parametern jedoch ein Passwort erfordert.

MFG

[Felix Riesterer]

Lieber pl,

Authorization Basic hat mit Hash-Methoden gar nichs zu tun.

inwiefern denn nicht? Muss nicht das Passwort mit einem gespeicherten Wert (aka Hash) abgeglichen werden? Ob das der Webserver mittels einer .htaccess-Datei tut, oder ein wie auch immer geartetes Plugin eines wie auch immer gearteten Frameworks, ist dabei doch egal! Und dieser gespeicherte Wert muss ja irgendwo stehen - womit wir wieder bei der üblichen Debatte um möglichen Passwortklau und die damit verbundenen Risiken und Nebenwirkungen bei schwachen Hashing-Algorithmen sind.

Und im Gegensatz zu einem Login mit Session, ist Auth Basic wesentlich einfacher zu realisieren.

Das kommt (wie üblich) darauf an, was das System in diesem Zusammenhang leisten soll. Will ich ein Affenformular so bauen, dass der Server nur noch die fehlenden Daten einfordert und die bereits eingegebenen Daten nicht mehr erneut abfragt, benötige ich eine Session, damit ich die bereits eingegebenen Daten nicht in versteckten Formularfeldern unsichtbar doch wieder abfragen muss.

Eines sollte man jedoch auch beachten, nämlich daß Auth Basic an den URL gebunden ist und nicht an den Inhalt.

Wenn man das mit einer Apache-Direktive via .htaccess macht, ist es an den Pfad (Verzeichnis) gebunden. Implementiert man das mit einer Scriptsprache, kann man das beliebig gestalten und Deiner Forderung entsprechen. Warum man das "an den URL gebunden" handhaben sollte, erkenne ich jetzt nicht. Was sind Deiner Meinung nach die Gründe dafür?

Von daher könnte ich meine Frage hier auch so formulieren: Wie bindet man Auth Basic an den Inhalt? Bspw. so, daß ein URL ohne Parameter ohne Passwort zugänglich ist, mit bestimmten Parametern jedoch ein Passwort erfordert.

Das muss dann wohl die Programmlogik des verwendeten Systems/Frameworks leisten.

Liebe Grüße

Felix Riesterer

[pl]

Authorization Basic hat mit Hash-Methoden gar nichs zu tun.

inwiefern denn nicht?

Weil Authorization Basic eben nur HTTP ist und Digest eine andere Sache die mit HTTP gar nichts zu tun hat.

Muss nicht das Passwort mit einem gespeicherten Wert (aka Hash) abgeglichen werden?

Nein. PHP liefert beides in $_SERVER['PHP_AUTH_USER'] bzw. $_SERVER['PHP_AUTH_PW'].

Ob das der Webserver mittels einer .htaccess-Datei tut, oder ein wie auch immer geartetes Plugin eines wie auch immer gearteten Frameworks, ist dabei doch egal!

Nein das ist nicht egal. Per Serverkonfiguration kann man Authorization Basic nur an bestimmte URLs binden. Über nachgelagerte Prozesse hingegen, hier ein Beispiel für PHP kann man Authorization Basic auch so verwenden daß bestimmte Inhalte nur mit den richtigen Credentials ausgeliefert werden.

Man denke beispielsweise auch an Webservices die ein Passwort erfordern, was damit recht einfach umgesetzt werden kann.

Aber mich interessiert eigentlich eher wie das Andere so machen. MFG

[Felix Riesterer]

Lieber pl,

Aber mich interessiert eigentlich eher wie das Andere so machen. MFG

offensichtlich nicht. Du willst nur Recht behalten. An Erkenntnisgewinn liegt Dir nachweislich nichts.

Liebe Grüße

Felix Riesterer

[dedlfix]

Tach!

Also ich würde mir das gerne mal angucken wie das geht, daß bei einem POST (z.B. Forum) eine Passwortabfrage kommt.

Ist es überhaupt sinnvoll, dass die HTTP-Authentication bei einem POST-Request beginnt? Ein POST-Request überträgt Daten, oftmals mehr als bei einem GET-Request. Sollen diese Daten erneut übertragen werden, nachdem der Nutzer die Anmeldedaten eingegeben hat? Wenn der Anmeldezustand innerhalb eines Frameworks ausgewertet werden sollen, muss üblicherweise der gesamte Request empfangen werden, bevor der Webserver diesen an die Application weiterreicht. Je größer die Daten, desto weniger sinnvoll erscheint es mir, dass die HTTP-Auth am POST startet und nicht bereits bei vorhergehenden GET-Requests.

Abgesehen davon ist HTTP natürlich zustandslos, und der POST-Request kann auch ohne Anmeldedaten kommen. Der Fall muss auch abgefangen werden. Aber den würde ich nicht als normalen Use-Case ansehen.

Also nur beim POST und das soll auch über AJAX funktionieren. Unter Passwortabfrage soll der übliche Prompt für eine Authorization Basic verstanden werden.

Bei Ajax-Requests schickt man üblicherweise die Anmeldedaten gleich mit, statt sich einen Mechanismus einzubauen, der die Daten erstmal ohne Anmeldung losschickt und sich die Anmeldedaten erst danach besorgt. In dem Fall weiß man normalerweise vorher, dass solche benötigt werden.

Etwas anders sieht der Fall allerdings aus, wenn man mit Authentisierungsmechanismen arbeitet, die mit zeitlich begrenzen Tokens arbeiten. Hier sollte man seine Anwendung aber so schreiben, dass sie clientseitig mitbekommt, wenn der Token abgelaufen ist, und das Besorgen eines neuen Tokens vor dem eigentlichen Request einschieben.

dedlfix.

[Proghorst]

Bei einem Framework sollte es möglich sein, eine Authorization Basic an beliebiger Stelle einbauen (konfigurieren) zu können. Also bspw. so, daß eine Passwortabfrage bei jedem Request auf eine URL, egal welche Parameter im Spiel sind und auch egal mit welcher Requestmethode, erscheint.

Die Anforderung, daß die Passwortabfrage nur bei bestimmten Parametern im Request erscheinen soll ist natürlich ein Sonderfall.

MFG

[Christian Kruse]

Hallo Proghorst,

Bei einem Framework sollte es möglich sein, eine Authorization Basic an beliebiger Stelle einbauen (konfigurieren) zu können.

Nein, das sehe ich nicht so. Authorization: Basic spielt heutzutage höchstens noch auf API-Ebene eine Rolle, und auch da wird es mehr und mehr von OAuth2 verdrängt.

Und Authorisierung/Authentifizierung ist nicht Aufgabe eines Frameworks, dazu sind die Anforderungen an solche Systeme viel zu umfangreich und vielfältig. Das sollte durch den Entwickler und/oder ein Plugin gelöst werden.

Freundliche Grüße,
Christian Kruse

[pl]

Authorization: Basic spielt heutzutage höchstens noch auf API-Ebene eine Rolle

API's im Sinne von Webservices betrachte ich als Komponenten die selbstverständlich auch zu einem Framework gehören.

Das sollte durch den Entwickler und/oder ein Plugin gelöst werden.

Ja natürlich, bei mir ist das ein Plugin. Meine Frage ist, wie das die großen Frameworks machen. MFG

[Christian Kruse]

Hallo pl,

Authorization: Basic spielt heutzutage höchstens noch auf API-Ebene eine Rolle

API's im Sinne von Webservices betrachte ich als Komponenten die selbstverständlich auch zu einem Framework gehören.

Du hast entscheidende Teile meiner Antwort weg gekürzt.

Das sollte durch den Entwickler und/oder ein Plugin gelöst werden.

Ja natürlich, bei mir ist das ein Plugin. Meine Frage ist, wie das die großen Frameworks machen. MFG

Mit Plugins.

Freundliche Grüße,
Christian Kruse

[pl]

s. Thema. Also ich würde mir das gerne mal angucken wie das geht, daß bei einem POST (z.B. Forum) eine Passwortabfrage kommt. Also nur beim POST und das soll auch über AJAX funktionieren. Unter Passwortabfrage soll der übliche Prompt für eine Authorization Basic verstanden werden.

MFG

Also bei asp.net hab ich mittlerweile gesehen wie die das machen: Nach demselben Prinzip. Auch in asp.net ist es möglich AuthBasic für bestimmte Aktionen einzubauen oder auch für die gesamte Anwendung.

MFG