Variable $user ist leer bei Login

$_SERVER['REMOTE_USER'] funktioniert bei mir OOTB

Falls es unbedingt $_SERVER['PHP_AUTH_USER'] sein muss, schreib das in eine .htaccess-Datei:

RewriteEngine on
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

Ebenfalls getestet, funktioniert. (Quelle: stackoverflow.com)

Hay,

Quote from Gebby

Wie geschrieben, bei mir eben nicht.

das klingt jetzt so, als ob die Antwort nicht buchstabengenau gelesen worden wäre, deswegen lege ich nochmal den Finger drauf:

Du schreibst von $_SERVER['PHP_AUTH_USER'];

KB19 schreibt $_SERVER['REMOTE_USER'], was bei ihm sofort funktioniert.

CU, Peter

Abhängig von der Art wie PHP verwendet wird (entweder als "mod" im Apache oder als eigenständiger Service als php-fpm) können sich solche Umgebungsvariablen schon mal ändern. Das Problem hab ich auch hin und wieder, wenn ich beim entwickeln nicht aufpasse, was mein Ziel-System verwendet

Hay,

im Allgemeinen...

• macht man schnell mal print_r($_SERVER) oder ruft php_info() auf und dann sucht man einfach nach dem Wert, den man braucht und klärt dann auf php.net, ob das tatsächlich die geeignete Variable ist
• abstrahiert man solche (je nach php Version und Ausführungsart) potenziell ändernden Werte sofort in eine eigene Variable und schleppt diese überall durch, dann braucht man das nur einmal anzupassen. Ich kann mich erinnern als $PHP_SELF verschwunden ist (PHP4 auf 5?). Das war dann einfach, weil man einmal $PHP_SELF = $_SERVER['PHP_SELF'] deklarieren musste (und deswegen steckt diese Zeile noch in vielen, vielen langlaufenden Projekten noch drin). Abgesehen davon, dass man das aus Sicherheitsgründen so auch nicht mehr verwenden sollte, wenn es ums action-target eines Formulars geht...

CU, Peter

Quote from CmdrXay

Abgesehen davon, dass man das aus Sicherheitsgründen so auch nicht mehr verwenden sollte, wenn es ums action-target eines Formulars geht...

Was spricht aktuell dagegen, wenn man es durch htmlspecialchars() o.ä. jagt?

Hay,

Quote from KB19

Was spricht aktuell dagegen, wenn man es durch htmlspecialchars() o.ä. jagt?

es spricht dagegen, dass man Sicherheitsrisiken schon vorher vermeidet (gerade bei PHP) und es einfach nicht tut, wenn es Alternativen gibt. Z.B. durch eine ordentliche Konfiguration und nicht durch das Auslesen von potenziell unsicheren Variablen von außen.

Außerdem ist

$PHP_SELF = filter_input(INPUT_SERVER, 'PHP_SELF', FILTER_SANITIZE_URL);

marginal besser (ersetzt nicht nur Zeichen, sondern validiert zusätzlich auf eine gültige URL). Aber wie bei allem, das ist immer noch nicht 100% safe

Deswegen besser einmal - wie geschrieben - eine feste Definition vorher oder eine eigene Validierung, z.B. ob das Ziel des action Attribut überhaupt plausibel auf Deinen Server zeigt (z.B. selbst mit einem RegEx zerlegen, Domain, Pfad checken, unerwartete Parameter filtern usw.). Wenn das Ziel tatsächlich nur das Script selbst ist, reicht auch nur ein einfaches action ohne echte Parameter... <form action="" method="get" class="form-example"> - damit geht man jedem solchen Streß aus dem Weg...

-> https://html.spec.whatwg.org/m…form-submission-algorithm

Quote

If action is the empty string, let action be the URL of the form document.

(Punkt 12 - im Moment... Doc kann sich jederzeit ändern...)

CU, Peter

Quote from CmdrXay

Aber wie bei allem, das ist immer noch nicht 100% safe

Prinzipiell stimme ich Deinem Beitrag inhaltlich zu. Aber solange PHP nicht irgendwelche komischen Bugs enthält, die an dieser Stelle Angaben wie https:// oder // am Beginn zulassen, sehe ich das Risiko leider noch nicht. Oder übersehe ich da irgendein spezielles Szenario?

Hay,

Quote from KB19

Oder übersehe ich da irgendein spezielles Szenario?

das Dumme ist, dass es immer mehr Szenarien gibt, die man sich nicht vorstellen kann, als die, die man sich vorstellen kann. Cross-Site-Scripter sind schlau.

Ich selbst habe PHP_SELF seit jetzt bestimmt 10 Jahren nicht mehr verwendet, da action="" dassselbe macht und auch noch weniger zu schreiben ist.

CU, Peter