Fehler bei Benutzer Bearbeitung im ACP

  • Betroffene Version
    WoltLab Suite 5.4

    Mahlzeit,

    der Fehler scheint mit dem aktuellen Update 5.3.16 zusammenzuhängen, zumindest ist es mir erst jetzt aufgefallen.

    Wenn man im ACP einen Benutzer bearbeiten will und anschließend "Absenden" klickt, öffnet sich ein Download Fenster, anstatt die Änderung(en) zu übernehmen.

    Es wird eine "index.php" heruntergeladen mit folgenden Inhalt:

    HTML
    <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
    <html><head>
    <title>503 Service Unavailable</title>
    </head><body>
    <h1>Service Unavailable</h1>
    <p>The server is temporarily unable to service your
    request due to maintenance downtime or capacity
    problems. Please try again later.</p>
    </body></html>

    Eine Benutzeränderung ist somit nicht mehr möglich.

  • Sehr ungewöhnlich, war die Seite (des ACP) denn komplett geladen?

    Und vor allem:

    due to maintenance downtime

    Ist das denn wirklich ausgeschlossen? Wenn Dein Hoster zu der Zeit gerade tatsächlich Wartungsarbeiten durchgeführt hatte (wird normalerweise angekündigt), wäre es ja bedingt erklärbar.

    Gruß

    Jörg

    (Jaydee)

    • Offizieller Beitrag

    Hallo,

    ein Blick in die Fehlerprotokolle von PHP und/oder dem Webserver sollte die Frage nach der Ursache beantworten. Das seltsame Verhalten bei der Fehlermeldung könnte ein Hinweis auf die Aktivierung von fastcgi_intercept_errors bei nginx sein, diese Einstellung ist in der Praxis leider ziemlich kontraproduktiv.

  • Sehr ungewöhnlich, war die Seite (des ACP) denn komplett geladen?

    Und vor allem:

    Ist das denn wirklich ausgeschlossen? Wenn Dein Hoster zu der Zeit gerade tatsächlich Wartungsarbeiten durchgeführt hatte (wird normalerweise angekündigt), wäre es ja bedingt erklärbar.

    War komplett geladen.

    Ich habe auch zu unterschiedlichen Zeitpunkten einen Test gemacht.

    Der Server ist auch im Betrieb, der Rest des Forums funktioniert einwandfrei.


    Hallo,

    ein Blick in die Fehlerprotokolle von PHP und/oder dem Webserver sollte die Frage nach der Ursache beantworten. Das seltsame Verhalten bei der Fehlermeldung könnte ein Hinweis auf die Aktivierung von fastcgi_intercept_errors bei nginx sein, diese Einstellung ist in der Praxis leider ziemlich kontraproduktiv.

    Ich habe nichts dergleichen geändert.

    Hab auch diesbezüglich keine Optionen bei meinem Provider.

    Im Fehler Protokoll steht ebenfalls nichts drin.

    Weder im Php Protokoll, noch im ACP Fehler Protokoll.

    • Offizieller Beitrag

    Weder im Php Protokoll, noch im ACP Fehler Protokoll.

    Dann hilft nur eine Rückfrage beim Hoster, offenbar ist das Fehlerprotokoll unzureichend konfiguriert. Wenn Server-Fehler (Code 503) generiert werden, dies aber nicht im Log auftaucht (das ACP-Protokoll ist hier ausdrücklich nicht relevant), dann stimmt dort etwas nicht.

  • Was die Sache allerdings noch interessanter macht. Gibt es denn irgendwelche Auffälligkeiten an diesem Account? Ist irgendetwas "anders" als bei den übrigen (bei denen es funktioniert)?

    Gruß

    Jörg

    (Jaydee)

  • Auffälligkeiten nicht, da es ein Test Dummy Account ist, der nur ab und zu gebraucht wird.

    Wenn ich in der Datenbank die Daten des Account mit den anderen funktionierenden Accounts Vergleiche, sehe ich auch keine besonderen Auffälligkeiten.

    Ich könnte den Account zwar einfach löschen und gut, jedoch interessiert mich der Fehler bzw. wie so ein Fehler ausgelöst werden kann.

    Falls es doch noch woanders auftreten sollte.

    Zudem kann ich ja nicht alle Mitglieder durchtesten um zu überprüfen, ob das Phänomen nicht noch bei anderen auftritt.

    Im Profil des Accounts selbst, kann man die Einstellungen problemlos ändern, nur im ACP will es nicht funktionieren. :/

  • Der Grund würde mich in der Tat auch interessieren. Zumal wenn selbst in der Datenbank keinerlei Abweichungen feststellbar sind. Offenbar ist irgendetwas beim (vermutlich manuellen) Erstellen dieses Accounts schief gelaufen, nur was genau, lässt sich aus der Ferne natürlich nicht sagen.

    Eine "nicht optimale" fastcgi-Konfiguration würde ich in dem Zusammenhang eher ausschließen, wenn es NUR diesen einen Account betrifft und zudem das Phänomen recht neu ist. Persönlich tippe ich gerade eher auf einen Zusammenhang mit der manuellen Erzeugung dieses Test-Accounts. .Obwohl sich selbst dann m. E. eine Abweichung auch in der DB zeigen müsste.

    Gruß

    Jörg

    (Jaydee)

  • Hat sich komischerweise von selbst gelöst.

    Da ich gerade von der Arbeit wieder Zuhause und an meinem PC dran bin, habe ich es direkt nochmal ausprobiert.

    jetzt funktioniert es wieder ohne Probleme.

    Aber selbst am Smartphone ging es nicht, von der schließe ich ein Problem mit Browser, Cache, Cookies o.ä. ebenfalls aus.


    Sehr seltsam das Ganze. :whistling:

  • Ja, manchmal gibt es solche "unerklärlichen Phänomene" bei Computern, auch wenn sie natürlich immer einen Grund haben.

    Vielleicht hatte in den Momenten ja tatsächlich der Server jeweils kurz gesponnen. Oder es liegt an der Konfiguration eures Firmen-Netzwerks. Wobei selbst das (für mich) noch nicht erklären würde, warum es NUR bei diesem Testuser auftrat.

    Aber Hauptsache es funktioniert jetzt wieder, dann ist Weihnachten ja gerettet. :)

    In diesem Sinne ein frohes und gesundes Fest.

    Gruß

    Jörg

    (Jaydee)

  • Anscheinend betrifft es nur einen Benutzer in meinem Forum.

    Ich kann alle Benutzer bearbeiten aber bei einem einzigen funktioniert es seltsamerweise nicht. :/

    Genau dies ist bei mir auch aufgetreten: nur ein Benutzer lässt sich nicht bearbeiten, bei mir haut's einen 403-Fehler raus:

    Der Benutzer ist in der Moderatorengruppe, die alle bearbeiten werden können, nur dieser eine Benuzer halt nicht...

    • Offizieller Beitrag

    Genau dies ist bei mir auch aufgetreten: nur ein Benutzer lässt sich nicht bearbeiten, bei mir haut's einen 403-Fehler raus:

    Aus der Meldung geht zu 100% hervor: Der Webserver hat die Anfrage blockiert. Ein Blick in den Error-Log des Webservers wird die Antwort auf das "Warum?" bereithalten :)

  • Ja, das ist die beste Lösung. Falls dort dann doch eine mod_security oder sonstige Filterregel anschlägt: Abschalten lassen, da es sich um ein so genanntes false-positive handelt.

    So was in der Art war es auch. die Firewall in Plesk hatte was blockiert, weil sie die falsche Einstellung hatte ;)

    Nochmals vielen Dank für die Hilfe! <3

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!