schau dir mal <we:formToken/> und <we:ifFormToken/> an. Das könnte evtl. bei automatisierten Anfragen helfen. Gibt aber noch ein paar weitere Tricks.
Posts by mokraemer
-
-
die sind mehr oder weniger beide gut zu nutzen.
Es kommen Unterschiede ins Spiel, wenn es um Cache warming geht. Ich meine zumindest redis kann bei einem Serverneustart den Zustand speichern und beim hochfahren wieder lesen. Das kann auf der anderen Seite aber natürlich auch andere Probleme mit sich bringen. Ist in jedem Fall konfigurierbar.
Beide können auf mehreren Servern laufen und so auch für eine bessere Verteilung/Ausfallsicherheit sorgen.
Ich hab mich damals für memcached entschieden, bisher hab ich keine Probleme festgestellt, tut einfach, was es soll.
-
Die Passwörter werden nicht als md5 gespeichert.
Evtl. sind bei deinem PHP ein paar Module nicht mehr dabei (crypt), falls die Passwörter hier noch mit dem veralteten Blowfish gespeichert wurden.
Welchen Präfix haben denn den PWDs die in der DB stehen $2y$ oder $2a$ ?
-
$obj->ParentID = '1729';
Das sollte einen Fatal Error auslösen. Es muß
$obj->ParentID = 1729;
heißen. Und das
$obj->we_save();
solltest du weglassen können, wenn du eh ein Publish machst.
-
die 7 ist so alt, das dort sicher noch http://update.webedition.org aufgerufen wird.
-
macht es denn überhaupt Sinn die Dokumente auszugeben auf die man nicht zugreifen kann?
-
-
hast du denn einen Fehler im (Update) Log?
Ich kann mich erinnern, das es bei der 9.0.2 noch Probleme gab. Afaik lief es erst mit 9.0.4 so richtig sauber durch; da waren noch Probleme mit der untypisierten alten Version und den neuen Typen.
Auf welche Version bist du denn nun gegangen?
-
Puh schwer zu sagen, ob da was falsch übergeben wird - müßte man debuggen. Mir erscheint deine Formel zu kompliziert. Zum einen sprichst du hier von 10km, zum anderen geht es glaube ich nicht um eine ganz exakte Berechnung von wenigen cm. Ich würde daher lat/long als rechtwinklig nähern. Dann müßte es eigentlich reichen die Differenz der beiden Punkte zu errechnen und das mit binomischer Formel zu lösen. Das erscheint mir auch für die DB mal weniger aufwändig. Ob sich das weiter vereinfachen läßt, oder mit geo-db von mysql einfacher geht https://dev.mysql.com/blog-archive/geography-in-mysql-8-0/ weiß ich nicht. Hab den Fall selbst noch nicht gebraucht.
-
-
das sollte doch über die Suche gehen - jetzt nicht getestet. Aber der Tab Inhalt bietet ja auf der Klasse auch einiges an Filter Funktionen
-
bei deinem FR ging es um compressed, was ehrlich gesagt wenig bringt.
das css ist danach unleserlich und muß durch den Debugger restyled werden, wenn man ein Problem hat.
Bei der "Kompression" wird ja nur Kommentare und Leerzeichen gefiltert. Hast du mal die Dateigröße verglichen, wenn du sie durch gzip gejagt hast? Das sollte ja eigentlich jeder webserver mittlerweile aktiv haben. Und bei HTML sollte das mod_brotli die Komprimierung auch noch deutlich anheben.
Bei den Artikeln ging es mehr auch darum ob man überhaupt noch scss braucht, weil css mittlerweile vieles kann, wofür man früher scss brauchte. Das wichtigste ist sicherlich die Schachtelung - und die kann eigentlich jeder Browser jetzt seit einiger Zeit. Und die Schachtelung spart ja jede Menge Platz, weil nicht für alles der ganze zusammengesetzte Pfad ersetzt wird.
-
man kann auch nachdenken, ob scss überhaupt noch nötig ist:
Vanilla-Web: Der Frontend-Trend 2024?Die Entwicklung von Web-UIs erfordert zu viele Frameworks und Tools, die zudem aufwendig und komplex zu integrieren sind. Könnte sich das im Jahr 2024 ändern?www.heise.deCSS/Tutorials/Selektoren/Schachtelung – SELFHTML-Wiki
das dürfte viel mehr sparen als die paar Leerzeichen aus einem komprimierten Datenstrom zu entfernen.
-
HE hat doch scheinbar irgendein DB Problem, weshalb DB-User nicht beendet werden. Da es keine technischen Ansprechpartner gibt um das Problem zu klären können wir da wenig machen - bei keinem anderen Hoster tritt das Problem auf.
Ich denke das du einfach zu viele Verbindungen hast und er es deshalb ablehnt (mit Access Denied)
-
Short-Open Tags sind kein Problem für WE
-
-
Hallo Jürgen,
beides quasi.
Bei bestimmten Queries lösen wir ein flush Statement aus. Damit sichergestellt ist, das die Daten auch sauber gelesen werden können. Dafür braucht der DB Benutzer eben das Recht "Reload" oder "FLUSH_TABLES" (normal hat er das). In deinem Fall hat er das nicht. Vor PHP 8.x wurde der "Fehler" einfach ignoriert und das Flush eben nicht ausgeführt. Seit 8.1 muß man den Fehler behandeln - an der Stelle war uns wohl nicht bewußt das es diesen Fall gibt. Daher bleibt er dann hängen.
Mach dazu bitte einen Bug auf, dann korrigieren wir das umgehend in der nightly
-
ja, das wurde entfernt, weil sich der Sinn dafür nicht ergeben hat.
-
Was genau passiert denn?
Ist die Datei leer oder was? Bekommst du Fehler?
-
Du bist hier natürlich mit einer älteren Version unterwegs. Das ist Sicherheitstechnisch natürlich nie eine gute Idee. Dennoch sind mir keine Lücken im Core von WE bekannt über die ein direkter Zugriff möglich ist.
Du schreibst aber ja auch Vorlagen - der Kode darin können wir natürlich nicht beurteilen. Und ein vorhandenes <we:write birgt sicher auch immer Möglichkeiten - da haben wir ja einige Einstellungen die sowas verhindern sollten - die man aber auch deaktivieren kann....
In der Vergangenheit kamen die meisten Zugriffe, die auf WE geschoben wurden, entweder von schlechten Zugangsdaten, fehlendem TOTP (würde ich bei Admin Accounts auf jeden Fall setzen!!), installierten anderen Anwendungen (Forum, Filebrowser) oder am Ende auch FTP.
Wenn du etwas entdeckst, wäre es ratsam das nicht hier zu posten, sonst sind danach ggf alle WE Installationen mit der Version betroffen.
Bitte erstelle dazu ein Ticket im Bugtracker (ggf auf privat setzen).