"Du hast keine Berechtigung, um auf dieses Pad zuzugreifen" ab Version 2018112500

[ksteitz]

Hallo Andreas und ggf. HU-Team,

zur Senkung der Sprachbarriere schreibe ich ausnahmsweise auf deutsch, for english people: please use deepl or similar (if required, further writing in this isse may be in english).
Wie bereits in #40 angedeutet, können wir leider schon seit mehreren Jahren kein Plugin-Update mehr machen. Um die Ursache noch weiter einzugrenzen, habe ich heute nochmal den Vormittag investiert und bin die Änderungen im Repo Schritt für Schritt durchgegangen. Wir haben Probleme ab dem Commit "GEDV moodle-mod_etherpadlite: compatibility to Moodle 35 - usage of core class curl" (0d285f9). Bis einschließlich zum vorherigen commit "Merge pull request #19 from abias/improvement-drop-german-language2 Drop german language pack in favour of AMOS." lief alles sauber, also mit 2.7.0 (Build: 2015021100). Ab Version 2018112500 erhalten wir diesen Fehler:
"Du hast keine Berechtigung, um auf dieses Pad zuzugreifen"

Wenn ein neues Pad angelegt wird, kommt ein "Fehler beim Schreiben der Datenbank".
PHP-Errors:

[19-May-2023 11:09:00 Europe/Berlin] Database transaction aborted automatically in /var/www/html/moodle/hrz-mdl/course/modedit.php
						[19-May-2023 11:09:00 Europe/Berlin] Default exception handler: Fehler beim Schreiben der Datenbank Debug: ERROR:  null value in column "uri" of relation "mdl_etherpadlite" violates not-null constraint
						DETAIL:  Failing row contains (13414, 3566, Pad-KS 10.5.2023 mit 2018112500, <p dir="ltr" style="text-align: left;">Pad-KS 10.5.2023 mit 2018..., 1, 1684487340, 0, null, 0).
						INSERT INTO mdl_etherpadlite (name,course,intro,introformat,uri,timecreated) VALUES($1,$2,$3,$4,$5,$6) RETURNING id
						[array (
						  'name' => 'Pad-KS 10.5.2023 mit 2018112500',
						  'course' => '3566',
						  'intro' => '<p dir="ltr" style="text-align: left;">Pad-KS 10.5.2023 mit 2018112500<br></p>',
						  'introformat' => '1',
						  'uri' => NULL,
						  'timecreated' => 1684487340,
						)]
						Error code: dmlwriteexception
						* line 489 of /lib/dml/moodle_database.php: dml_write_exception thrown
						* line 293 of /lib/dml/moodle_read_slave_trait.php: call to moodle_database->query_end()
						* line 338 of /lib/dml/pgsql_native_moodle_database.php: call to pgsql_native_moodle_database->read_slave_query_end()
						* line 1091 of /lib/dml/pgsql_native_moodle_database.php: call to pgsql_native_moodle_database->query_end()
						* line 1139 of /lib/dml/pgsql_native_moodle_database.php: call to pgsql_native_moodle_database->insert_record_raw()
						* line 82 of /mod/etherpadlite/lib.php: call to pgsql_native_moodle_database->insert_record()
						* line 128 of /course/modlib.php: call to etherpadlite_add_instance()
						* line 168 of /course/modedit.php: call to add_moduleinfo()

Bei schrittweise weiteren Updates bleibt dies zunächst unverändert. Das Fullscreen-Feature wandert sauber dazu, ist ja trotz Fehlermeldung sichtbar. Nach Update auf die neueste 3.11er-Version 2022022509 vom 10. Mai 2023 kommen auch die Neuerungen sauber rein:
Neue Einstellungen

• Sicherheit ignorieren
• API-Version
• Pad-Link kopieren
• Gruppenpads löschen in

Allerdings taucht nach dem Update ein neuer Fehler auf: "Fehler: Could not get api version" (siehe auch #58). Wir haben aber keinerlei Änderung an den Servern vorgenommen und vorm Plugin-Update war der epad-Server normal erreichbar. Oder wurde etwa eine config-Änderung eingeführt und es muss etwas anders als früher eingestellt werden?

						[19-May-2023 11:34:47 Europe/Berlin] Default exception handler: Fehler: Could not get api version Debug: 
						Error code: generalexceptionmessage
						* line 165 of /mod/etherpadlite/classes/client.php: InvalidArgumentException thrown
						* line 172 of /mod/etherpadlite/classes/client.php: call to mod_etherpadlite\client->get_version()
						* line 74 of /mod/etherpadlite/classes/client.php: call to mod_etherpadlite\client->check_version()
						* line 71 of /mod/etherpadlite/view.php: call to mod_etherpadlite\client->__construct()

In den Einstellungen erscheint nun zudem der error "Der momentane Server "mdl-epad-test.hrz.tu-darmstadt.de([IP-Adresse])" ist blockiert." (https://moodle-test.hrz.tu-darmstadt.de/admin/settings.php?section=modsettingetherpadlite)

Diesen Fehler haben wir auch auf unserem dev-System unter Moodle 4.2 und PHP 8 mit der neuesten 4er Plugin-Version v4.2-r3 (2023-05-10) – 2023042702.
In der Konfiguration vom Plugin selbst sowie auf dem Etherpad-Server nahm ich keine Änderungen vor, z.B. weiterhin "requireSession": false, "editOnly": true,

Hier unsere Daten im Überblick:

• Moodle 3.11.14
• PostgreSQL 13
• PHP 7.4
• Etherpad-Server (epad-test): Release v1.8.18 und node -v: v16.14.0 und DB ebenfalls mit pg13
• epad-test-Server nur HRZ-intern erreichbar, nicht öffentlich, im Browser funktioniert https://mdl-epad-test.hrz.tu-darmstadt.de:9009/ sowie curl von den beiden Moodle-Webservern (mdl-test01/02)
• alle Server mit RHEL 8
• funktionierende Plugin-Version: 2.7.0 (Build: 2015021100) – 2015060301 (bis zu commit von Jan 16, 2019: 06934bb)
• error ab 0d285f9

Falls weitere Infos, z.B. aus dem etherpad-Journal, Moodle oder etherpad-DB, helfen, sende ich diese gerne. Wenn es den Standard Community-Support-Rahmen sprengt, können wir uns auch bilateral per Mail o.ä. abstimmen, bei Bedarf kann ich vermutlich auch einen Auftrag vergeben.

Vielen Dank für Unterstützung und Ideen, woran es liegen könnte!

Viele Grüße aus Hessen nach Berlin
Klaus

[grabs]

Hallo Klaus,

danke für die ausführliche Beschreibung!
Wie es aussieht, hast du die Ursache bereits gleich mit geliefert.
Zitat:

In den Einstellungen erscheint nun zudem der error "Der momentane Server "mdl-epad-test.hrz.tu-darmstadt.de([IP-Adresse])" ist blockiert."

Das heißt, Moodle kann den Etherpad-Server nicht erreichen. Das bedeutet nicht, dass der Moodle-Server den Etherpad-Server nicht erreichen kann. Es bedeutet, dass Moodle die IP des Etherpad-Servers geblockt hat.
Prüfe am Besten dazu die Moodle Einstellung: curlsecurityblockedhosts
Möglicherweise ist dort die IP bzw. der IP-Bereich zum Blocken hinterlegt. Wichtig: Gemeint ist die IP, über die der Moodle-Server den Etherpad-Server erreicht und nicht die IP, über die der Anwender den Etherpad-Server erreicht.
Wenn du diese Block-Liste nicht ändern möchtest, kannst du alternativ die Etherpad-Option: etherpadlite | ignoresecurity aktivieren. Dann wird beim Zugriff auf das Etherpad die Block-Liste ignoriert.

Viele Grüße
Andreas

[ksteitz]

Hallo Andreas,

vielen Dank für die schnelle und hilfreiche Antwort!

"Ignoresecurity" ist in der Tat die Hauptursache der Probleme. Nach Setzen des Hakens bleibt die Meldung in den Einstellungen bestehen, ändert lediglich die Schriftfarbe von rot zur orange für "Server blockiert". Die Pads in Moodle funktionieren durch Setzen dieser Checkbox wieder normal, ebenso das Erstellen neuer Pads. Zudem kommt auch die Meldung "Du hast keine Berechtigung, um auf dieses Pad zuzugreifen" nicht mehr, das scheint dann wohl durch irgendein Update zur aktuellen Version zwischendurch für uns behoben worden zu sein. Ignorieren wir also Ignoresecurity (das Wortspiel konnte ich mir nicht verkneifen), ist wieder alles fein.

Wenn ich es richtig sehe, wurde "Ignoresecurity" am 13. März 2022 als neue Einstellung eingeführt (9073d26). Das passt auch, denn seit mehreren Monaten haben wir dieses "Server blockiert" Problem, wenn wir mit aktuellen Plugin-Versionen testeten. Offenbar wurde damit eine neue Server-Prüfung eingeführt, die es bis dato nicht gab. Da wir wie gesagt keine Änderungen an unseren Etherpad-Servern oder -Einstellungen vornahmen, stellte ich mir also noch folgende Fragen:

1. Welche Firewall-Regeln sind nun relevant geworden, die bei uns aktuell ein Ignoresecurity nötig machen? Anders gesagt: was ist der neu eingeführte security-Mechanismus und wie funktioniert er? Oder könnte ich unseren Etherpad-Server noch explizit in eine Whitelist eintragen? Derartiges scheint es ja bisher nicht zu geben? Alex hatte das 2019 mal angeregt: https://tracker.moodle.org/browse/MDL-66909
2. curlsecurityblockedhosts: Diese Einstellung erschließt sich mir nicht vollständig; dunkel erinnere ich mich, sie soll user aus Moodle heraus daran hindern, Port-Scans u.ä. unschöne Dinge zu vollführen? Ich konnte auch in den Docs oder anderen Stellen keine Infos dazu finden. Jedenfalls steht die Adresse unseres Etherpad-Servers nicht drin (dafür localhost und
   moodle.tu-darmstadt.de). Wie gesagt habe ich keine Erfahrungswerte, was hier gute Eintragungen sind?

Viele Grüße
Klaus

[grabs]

Hallo Klaus,

mit der Version "2018112500" habe ich die bis dahin genutzte in php integrierte curl-Implementierung auf die in Moodle implemeniterte curl-API umgestellt. Dadurch greifen automatisch einige Sicherheitsmechanismen von Moodle, die vorher ignoriert wurden.
Das Ganze hat nichts mit den Firewall-Regeln zu tun. Moodle blockt einfach die IP-Bereiche, die in den Settings "curlsecurityblockedhosts" definiert sind.
Du schreibst, ihr habt in der Einstellung die beiden Einträge "localhost" und "moodle.tu-darmstadt.de" zu stehen. Möglicherweise wird einer der beiden Einträge auf die IP-Adresse aufgelöst, auf die auch euer Etherpad-Server aufgelöst wird (server-seitig).
Das heißt, der Moodle-Server bzw. Webserver-Node im Cluster kann den Etherpad-Server nicht mehr über das in Moodle integrierte "curl" erreichen.
Die Einstellung "ignoresecurity" bewirkt lediglich, dass für die Aufrufe zur Etherpad-API die o.g. Block-List ignoriert wird. Die IP wird in diesem Fall nicht geblockt, auch wenn es in den Moodle-Einstellungen eigentlich so definiert ist.

Viele Grüße
Andreas