Webanwendung kann sich nicht authentifizieren weil der Header nicht durchgereicht wird. (glaub vorhin im falschen Bereich gefragt)

    Eine Anwendung meldet sich mit Anwendungspasswort bei WordPress an: mit einem Benutzer, das Passwort liegt im Schlüsselbund. Diese Anmeldung kommt bei WordPress nicht an. Selbst ein ausgedachter Benutzer bekommt rest_not_logged_in statt „Benutzer unbekannt“. Daraus folgt für mich, dass WordPress den Anmelde-Header gar nicht erst zu sehen bekommt.

    Was schon versucht wurde, alles ohne Erfolg:

    y) CGIPassAuth in wp/.htaccess
    z) die vorhandene RewriteRule … E=HTTP_AUTHORIZATION im WordPress-Block
    a) SetEnvIf in <IfModule>
    b) alle Cache-Plugins aus
    c) ein Test aus deinem Terminal mit dem echten Passwort (29 Zeichen) und mit falschem Benutzer
    d) Plugins und Snippets geprüft, keins blockiert

    Befund: Nur netcup kann den Authorization-Header an PHP durchreichen.
    Plesk bietet dafür kein Feld „Zusätzliche nginx-Anweisungen“.

    Support sagt: Haben wir nichts mit zu tun (wie immer)

    bash
    curl -i --user "BENUTZERNAME:APPLICATION_PASSWORD" \https://deine-domain.tld/wp-json/wp/v2/users/me

    liefert 401

    Test
    GET https://website.de/wp-json/wp/v2/users/me mit Basic Auth eines nicht vorhandenen Benutzers Antwort: HTTP 401 {"code": "rest_not_logged_in", "message": "Sie sind derzeit nicht angemeldet."]

    Erwartet wäre „invalid_username"; WordPress sieht den Header also gar nicht.

    Ohne Wirkung blieben bereits: CGIPassAuth On, RewriteRule mit E=HTTP_AUTHORIZATION und SetEnvIf in der htaccess.

    In Plesk finde ich kein Feld für zusätzliche Einstellungen ...


    Hat jemand eine Ahnung was man tun kann?

    Also in meiner .htaccess - nicht Wordpress - finde ich einen Abschnitt:

        # Sets the HTTP_AUTHORIZATION header removed by Apache
       RewriteCond %{HTTP:Authorization} .
       RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    Das deutet für mich u.a. schon mal darauf hin, dass es zumindest ein eher verbreitetes Problem ist, dass Apache den Header löscht. Ich kann mir jedenfalls nur schwer vorstellen, dass das nur für netcup gedacht ist.

    Olivetti .htaccess Auszug daraus (alles andere sind Cache und Medienangaben) ...

    1. schreib in in die .htaccess an oberster stelle:

    Code
    CGIPassAuth On
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

    2. lege eine test.php (die du nach den tests wieder löschst) ins selbe verzeichnis:

    PHP
    <?php
header('Content-Type: text/plain');
var_dump(
  $_SERVER['HTTP_AUTHORIZATION'] ?? null,
  $_SERVER['REDIRECT_HTTP_AUTHORIZATION'] ?? null,
  $_SERVER['HTTPS'] ?? null,
  $_SERVER['HTTP_X_FORWARDED_PROTO'] ?? null
);

    3. was zeigt:

    Code
    curl -u test:test https://deine-domain.tld/test.php

    »Hauptsache BogoMIPS!«
    Volksfront DLT #64Ksplit
    Sag' NEIN zu Wordpress

    O.k der Fehler ist gefunden, danke Olivetti für den Anstoß!

    Zu frühe Abfrage: Das Plugin pro-elements fragt beim Laden ab, ob jemand angemeldet ist. Das passiert über is_user_logged_in in seiner Datei plugin.php. Die Anfrage ist da noch nicht als Schnittstellen-Anfrage erkannt (rest_request: false), also prüft WordPress das Anwendungspasswort nicht, und das Ergebnis lautet „niemand“.

    Fehlersuche beginnt: Danach beginnt WordPress die Fehlerprüfung der Schnittstelle. Auf Stufe 90 sucht es nach einem gescheiterten Anwendungspasswort. Da ist noch keins, also meldet es nichts.

    Passwortprüfung zu spät: Erst auf Stufe 100 (rest_cookie_check_errors) fragt WordPress den Benutzer ein zweites Mal ab. Jetzt prüft es das Passwort, und die Prüfung scheitert richtig mit invalid_username.

    Ergebnis: Die Fehlerprüfung ist da aber schon vorbei und endet mit true, also „in Ordnung“. Der Benutzer bleibt 0, und die Schnittstelle antwortet mit rest_not_logged_in.

    Lösung ist ein mu-plugin, das den Benutzer bei jeder Schnittstellen-Anfrage abfrägt bevor Wordpress nach Anmeldefehlern sucht.

    PHP
    <?php
// Fragt den Benutzer bei Schnittstellen-Anfragen vor der Fehlerprüfung ab, damit die Anmeldung
// per Anwendungspasswort greift. Grund: pro-elements fragt beim Laden zu früh ab (C010 J36, 08.10.2026).
add_filter('rest_authentication_errors', function ($r) {
   wp_get_current_user();
   return $r;
}, 1);