[3.2.9&3.3]Viele Probleme nach dem Update

[Crizzo]

Ob Argon2i verfügbar ist, könnt ihr mit folgender Datei argon2itest.php herausfinden:

Code: Alles auswählen

<?php

$echo = password_hash("blablubb", PASSWORD_ARGON2I);

echo "Hier der hash: " . $echo; 

Hinter : nichts kommt, dann eure PHP-Version es nicht, ansonsten schon.

Das wird das Problem hier mit den .lock-Files aber nicht lösen.

[chris1278]

Wenn ich die Datei so abspeichere und aufrufe dann das hier:

https://prnt.sc/qo5pgo

Übrigens dasselbe passiert auch bei Strato. Eben getestet.

Ich gehe mal davon aus das bei beiden das Modul nicht installiert ist. Wenn ich das richtig sehe hätte nach dem hier der hasch dieses blub ding stehen müssen.

Wenn ich das richtig sehe würde ich mal behaupten das liegt nicht an dem Argon2 modul.

[Crizzo]

Dann kann deine PHP-Version kein Argon2i. Zur Kontrolle kannst du PASSWORD_ARGON2I mit PASSWORD_DEFAULT ersetzen

[chris1278]

Also wenn ich das auf defaul setze wie du gesagt hast erscheint das so:

https://prnt.sc/qo5s5f

Dann liefert er ein hashwert.


Und das auch bei strato:

https://prnt.sc/qo5sfw

Das forum ist auf strato gehostet. wobei das forum selber noch 3.2.8 ist.

[BNa]

Es liegt ja scheinbar sowieso nicht daran (Thema: "Intelligente Ausrede").

Frei nach dem Motto: Hauptsache es klingt kompliziert oder wie ein radioaktives Isotop

viewtopic.php?f=145&t=244016

Problem: Failure while aqcuiring locks (Strato-Webhost)

[Dr.Death]

Das Argon2 Modul ist auch nicht zwingend erforderlich, aber phpBB wurde für zukünftigen Gebrauch davon fit gemacht.

Wenn das Modul nicht vorhanden ist, wird einfach das vorhandene Hashing System verwendet... so einfach ist das.

[BNa]

Dachte ich mir auch, daher ... Danke für die Info

[IMC]

Nach dem ich von Strato eine Antwort bekommen hatte die mich leider nicht zufrieden gestellt hat. Habe sie gebeten doch noch mal nach einer Lösung zu suchen.

Gleichzeitig verspürte ich den drang noch ein mal zu testen warum die Dateien bei der Funktion flock() mal ein FALSE und mal TRUE erzeugen.

Den Grund habe ich jetzt herausbekommen. Der Unterschied ist der Modus in dem sie mit fopen() geöfnet werden.

Code: Alles auswählen

-LogFile-Zugriff flock() -
[16.01.2020;20:09:43] ./cache/production/sql_819dc160ed61cca154e8c4eced23fc51.php.lock	TRUE  wb 
[16.01.2020;20:09:44] ./cache/production/data_text_formatter_parser.php.lock		TRUE  wb 
[16.01.2020;20:09:44] ./cache/production/data_text_formatter_renderer.php.lock		TRUE  wb 
[16.01.2020;20:09:44] ./cache/production/data_word_censors.php.lock			TRUE  wb 
[16.01.2020;20:09:44] ./cache/production/sql_3e34796286cb810b99597106afdc2dce.php.lock	TRUE  wb 
[16.01.2020;20:09:45] ./cache/production/data_global.php.lock				FALSE  rb 
[16.01.2020;20:09:48] ./cache/production/data_cron.lock_check.php.lock			TRUE  wb 
[16.01.2020;20:09:48] ./cache/production/data_global.php.lock				FALSE  rb 
[16.01.2020;20:09:51] ./cache/production/sql_b152bea2b86cc301f01da4d7125e73ba.php.lock	TRUE  wb 
[16.01.2020;20:09:51] ./cache/production/data_icons.php.lock				TRUE  wb 
[16.01.2020;20:09:51] ./cache/production/data_global.php.lock				FALSE  rb 

So wie es Ausschaut gibt flock() immer ein FALSE zurück wenn die Dateien im Lesemodus geöffnet werden. Ob das Richtig oder falsch ist und warum dies scheinbar nur bei Strato gehosteten Installationen auftritt. Keine Ahnung.

Hat hier jemand Informatik studiert und kann uns dies erklären?

Grüße
Thorsten

Hier das LogFile meines Localhost. Alles auf TRUE, egal ob schreib oder lese Zugriff.

Code: Alles auswählen

-LogFile-Zugriff flock() -
[16.01.2020;20:44:50] ./cache/production/sql_9dc91161799801b44926b824ccc5cf51.php.lock	TRUE  rb 
[16.01.2020;20:44:51] ./cache/production/sql_7cc96e526b5b15b27599476001c35367.php.lock	TRUE  rb 
[16.01.2020;20:44:52] ./cache/production/sql_819dc160ed61cca154e8c4eced23fc51.php.lock	TRUE  rb 
[16.01.2020;20:54:09] ./cache/production/sql_819dc160ed61cca154e8c4eced23fc51.php.lock	TRUE  wb 
[16.01.2020;20:54:16] ./cache/production/data_text_formatter_parser.php.lock		TRUE  wb 
[16.01.2020;20:54:16] ./cache/production/data_text_formatter_renderer.php.lock		TRUE  wb 
[16.01.2020;20:54:16] ./cache/production/data_word_censors.php.lock			TRUE  wb 
[16.01.2020;20:54:17] ./cache/production/data_global.php.lock				TRUE  rb 
[16.01.2020;20:54:51] ./cache/production/sql_b152bea2b86cc301f01da4d7125e73ba.php.lock	TRUE  wb 
[16.01.2020;20:54:51] ./cache/production/data_icons.php.lock				TRUE  wb 
[16.01.2020;20:54:53] ./cache/production/data_global.php.lock				TRUE  rb 
[16.01.2020;20:55:00] ./cache/production/data_global.php.lock				TRUE  rb 

[Steve Wuppertal]

Könnte es evtl. mit dem von Strato genutzten Betriebssystem der Shared-Hosting Paketen zusammen hängen ?

https://stackoverflow.com/questions/317 ... ot-writing
(vor allem der Antwortpost ist interessant)

[chris1278]

Wenn man schon einen "Workaround" posted, dann bitte "richtig".

Durch Deinen Workaround wird der komplette File Lock Mechanismus ausgehebelt.

Mache es besser so:

Öffne:
phpbb/lock/flock.php

FINDE:

Code: Alles auswählen

			if (!@flock($this->lock_fp, LOCK_EX))
			{
				throw new \phpbb\exception\http_exception(500, 'Failure while aqcuiring locks.');
			}

ERSETZE MIT:

Code: Alles auswählen

			@flock($this->lock_fp, LOCK_EX);

Damit wird der "alte" File Lock mit unterdrückter Fehlermeldung wieder aktiv.

Das vertuscht nach wie vor den Fehler auf den Strato Servern, sollte aber die Ausgabe nicht mehr stoppen.....

... und beim nächsten Update hat man erneut den "Fehler"

Falls ich die Flock.php also so anpasse mit phpbb 3.3.0, wie verhält sich das mit der Sicherheit. Ist das Sicherheitslevel dann genau so wie bei phpbb 3.2.8 bzw. 3.2.9.

Was hat die Variante für Vorteile und Nachteile?

Abgesehen das man als Vorteil nennen könnte das man phpbb installieren kann bzw. Updaten ( speziell auf Strato) und als Nachteil halt das man es beim nächsten update von 3.3.1 dann wieder ändern müsste (sofern von strato oder phpbb dagegen nix gemacht wurde).