Serendipity Forums

[Harald Weingaertner]

Hallo,

ich bin nicht sicher, ob das ein Bug in S9y ist... Seit einigen Tagen gibt es auf einem unserer Blogs komische Erscheinungen.

Sobald man einen etwas längeren Kommentar auf einen Beitrag abgibt, meldet das Blog "You don't have permission to access /index.php on this server." und der Kommentar erscheint nicht.

Ich hab nun mal ein Upgrade auf Serendipity 1.7-rc2 und PHP 5.2.17 gemacht und das Blog auch mal komplett ohne Plugins laufen lassen. Keine Chance.

Will ich einen Kommentar löschen, dann erscheint diese Meldung auf dem Bildschirm: The requested URL /spieltage/comment.php was not found on this server.
("spieltage" ist in dem Fall ein geänderter Name in den Permalinks)

Hat jemand eine Idee an was das liegen kann? Im Errorlog steht meiner Ansicht nach auch nichts drin, was auf eine Lösung hindeutet. Das mit den geänderten Permalinks hatte jahrelang funktioniert und ich glaube nicht, dass es daran liegt. PHP 5.3.19 und 5.2.17 habe ich beide probiert und beide ohne Erfolg

Danke für Hilfe, Harald

[Harald Weingaertner]

Und nach dem Ändern des Styles erscheint diese Fehlermeldung:

Fatal error: Uncaught exception 'ErrorException' with message 'Serendipity error: Invalid argument supplied for foreach()' in /home/include/compat.inc.php:119 Stack trace: #0 /home/include/functions_plugins_admin.inc.php(471): errorToExceptionHandler(Object(template_option), Array, 'yellow', 'yellow', Array, true, true, true, true, 'template', NULL) #1 /home/include/admin/templates.inc.php(119): serendipity_plugin_config() #2 /home/serendipity_admin.php(136): include('/home/...') #3 {main} thrown in /home/include/compat.inc.php on line 119

Das wird aber wohl auch mit YellowLed's Template zu tun haben, oder?

[kleinerChemiker]

Benutzt du/dein Hoster suhosin oder ähnliches? So was steht normalerweise auch in der Ausgabe von phpinfo().

[Timbalu]

Dieser error ist ein page unavailable error (ähnlich einer white page of death) oder ist das ein Serendipity error?
Wenn das schon vor dem Upgrade auf die 1.7 geschah, würde ich auch auf einen server-error oder Mißkonfiguration tippen.

PHP 5.3.19 ist den 5.2.x Versionen dringend vorzuziehen!

Sind die Permissions richtig gesetzt?
Ist der Apache reloaded worden?
Hat dein ISP irgendwelche Änderungen durchgeführt?

[Timbalu]

Das wird aber wohl auch mit YellowLed's Template zu tun haben, oder?

Ist dass das Original oder hast du eine kopie verändert?
Meine Testumgebung läuft auf 2k11 und man kann das style beliebig verändern und speichern.

Das mit den geänderten Permalinks hatte jahrelang funktioniert und ich glaube nicht, dass es daran liegt.

Beschreibe bitte mal sehr genau was du warum und wie gemacht hast.

[Harald Weingaertner]

Hi und Danke für die Antworten.

suhosin wird nicht benutzt. Zumindest taucht das in der phpinfo nirgends auf.

Mit dem 2k11 Style kann ich die Settings auch einwandfrei verändern. Mit Yellow Bulletproof v1.2 speichert er sie nicht. Ich werde das Theme aber gleich nochmal neu hochladen und testen. Wenn es mit dem 2k11 geht, dann reicht mir das erstmal.

Die Permissions sind richtig, sonst hätte das nicht 5 Jahre lang funktioniert. Ich werde aber mal beim Hoster fragen, ob die in der letzten Woche etwas geändert haben. Sicher haben die das, nur weiß ich aktuell nicht was.


Ein weiteres Phänomen ist, dass Kommentare mit nur wenigen Zeichen durchgehen. Schreibe ich aber einen langen Kommentar mit einigen Hundert Zeichen, dann kommt der oben beschriebene Fehler. Ein Kommentest á la "Test" funktioniert also einwandfrei. Viele Sätze als Kommentar verursachen den Fehler mit "no permissions".

Ich werde aber den Ball jetzt mal an den Hoster weiterspielen, denn ich hab da 5 Jahre nichts verändert und es lief noch eine uralte s9y Version, also haben die was verändert, befürchte ich.

Besten Dank, Harald

[kleinerChemiker]

Ein weiteres Phänomen ist, dass Kommentare mit nur wenigen Zeichen durchgehen. Schreibe ich aber einen langen Kommentar mit einigen Hundert Zeichen, dann kommt der oben beschriebene Fehler. Ein Kommentest á la "Test" funktioniert also einwandfrei. Viele Sätze als Kommentar verursachen den Fehler mit "no permissions".

Deshlab meine Vermutung, daß es php oder Apache Security Schmafu ist. Da gibts Einstellungen, die die Länge von Eingaben einschränken.

[garvinhicking]

mod_security

[Timbalu]

Treffer! Das ist es aber noch nicht ganz....

Bulletproof 1.2 ist schon etwas sehr outdated und habe ich hier auch nicht mehr vorliegen, aber die aktuell mitgelieferte version BP 1.4 macht tatsächlich denselben Fehler (im quelltext):
in der functions_plugins_admin.inc ~471 (!)
was dann debugmäßig case "ctype: select" ergibt.
Hier wird

Code: Select all

$select mit = $cbag->get('select_values');

erstellt und mit foreach ausgegeben. Leider ist $select leer! Das ist das Farbwahl select.
Warum weiß ich noch nicht... (Garvin?)

Ein schneller workaround ist die foreach Schleife:

Code: Select all

<?php
                foreach($select AS $select_value => $select_desc) {
                    $id = htmlspecialchars($config_item . $select_value);
?>
                        <option value="<?php echo $select_value; ?>" <?php echo ( (in_array($select_value, $selected_options) || in_array($select_value, $pre_selected) ) ? 'selected="selected"' : ''); ?> title="<?php echo htmlspecialchars($select_desc); ?>">
                            <?php echo htmlspecialchars($select_desc); ?>
                        </option>
<?php
                }
?>


mit einem if is_array zu umkleiden...

Code: Select all

<?php
            if( is_array($select) ) {
                foreach($select AS $select_value => $select_desc) {
                    $id = htmlspecialchars($config_item . $select_value);
?>
                        <option value="<?php echo $select_value; ?>" <?php echo ( (in_array($select_value, $selected_options) || in_array($select_value, $pre_selected) ) ? 'selected="selected"' : ''); ?> title="<?php echo htmlspecialchars($select_desc); ?>">
                            <?php echo htmlspecialchars($select_desc); ?>
                        </option>
<?php
                }
            }
?>


Edit:
Und der eigentliche Fehler sitzt hier:
Warum wurde die Bildung des $colorsets array in der BP config.inc mit einem

Code: Select all

if ($serendipity['GET']['adminModule'] == 'templates') { ... }

umschlungen???
Ohne gehts!

Edit2:
Wahrscheinlich sollte verhindert werden, dass die Bildung des colorsets arrays immer - d.h. auch im Frontend - durchlaufen wird, leider wurde aber vergessen, dass ein Wechsel des Templates keinen GET adminModule=templates setzt.

Eigentlich muss das auch schon vor 1.7 zu einem Fehler geführt haben.

Garvin, sollen wir den nun grundsätzlich beim Templatewechsel generieren, oder gäbe es außer der Deaktivierung des if()s noch andere Möglichkeiten?

[yellowled]

Das wird aber wohl auch mit YellowLed's Template zu tun haben, oder?

Warum sollte es? Nicht alles, wo “yellow” drauf steht, ist auf meinem Mist gewachsen.

YL

[Harald Weingaertner]

Moin und Danke für die Antworten. Ich habe das Gefühl, dass es nun wieder funktioniert. Der Hoster hatte mir auf meine Anfrage unter anderem das hier geantwortet:

"As for the error message you receive - we have removed mod_security rule for your account, please try to test it and lat us know whether you experience the same error message."

Garvon, kannst Du kurz erklären was dahinter steckt?

Gruß, Harald

[Harald Weingaertner]

Das wird aber wohl auch mit YellowLed's Template zu tun haben, oder?

Warum sollte es? Nicht alles, wo “yellow” drauf steht, ist auf meinem Mist gewachsen.

YL

Jo Sorry, hatte ich zwischenzeitlich auch gemerkt Sorry...

[yellowled]

Garvon, kannst Du kurz erklären was dahinter steckt?

Mal sehen, ob Garvin das kürzer hinkriegt , aber einstweilen:

http://www.heise.de/security/artikel/Di ... 70782.html

YL

[Timbalu]

Warum sollte es? Nicht alles, wo “yellow” drauf steht, ist auf meinem Mist gewachsen.

Nananana...!

In diesem Fall - siehe meine Erklärung oben - vielleicht schon ... weil yellow, das yellow_style stylesheet von bulletproof meint. Und da warst du ja nicht unwesentlich beteiligt... <flöt...>

Garvin, please read the upper post!

[yellowled]

In diesem Fall - siehe meine Erklärung oben - vielleicht schon ... weil yellow, das yellow_style stylesheet von bulletproof meint. Und da warst du ja nicht unwesentlich beteiligt... <flöt...>

Ich will wirklich nicht pingelig sein, aber es gibt gar kein Stylesheet „yellow“ in Bulletproof.

YL