Beiträge von CmdrXay

Hay,

"bedingt". Die Herausforderung ist hier, dass Du nicht Prozessoren vergleichst, sondern dedicated Cores von diesen Prozessoren und die Architektur ist schon recht unterschiedlich... der Epyc hat ne Menge Cores & Threads mehr, aber nicht im selben Faktor Cache... dazu kommt, dass Du so mit mehr Leuten (deren Inanspruchnahme von Leistung Du nicht kennst) dieselbe CPU teilst, bei Intel sind es weniger CPU-Kollegen...

Objektiv wäre es der AMD Epyc (https://versus.com/en/amd-epyc-7702-vs-intel-xeon-gold-6230).

Die single thread performance ist beim AMD allerdings leicht schlechter als beim Intel, dafür hat der AMD PCIE 4 statt 3 wie beim Intel. Kann also durchaus sein, dass dies bei der SSD-Performance durchschlägt. Aber auch da teilst Du Dir die PCIE-Lanes mit mehr Nutzern als beim Intel. Spannender Vergleich...

Ungefähr vergleichen kannst Du es, sobald jemand hier seinen geekbench für den Intel postet und ein anderer seinen für AMD ... los, los!

CU, Peter

Hay,

Zitat von KB19

Oder übersehe ich da irgendein spezielles Szenario?

das Dumme ist, dass es immer mehr Szenarien gibt, die man sich nicht vorstellen kann, als die, die man sich vorstellen kann. Cross-Site-Scripter sind schlau.

Ich selbst habe PHP_SELF seit jetzt bestimmt 10 Jahren nicht mehr verwendet, da action="" dassselbe macht und auch noch weniger zu schreiben ist.

CU, Peter

Hay,

Zitat von KB19

Was spricht aktuell dagegen, wenn man es durch htmlspecialchars() o.ä. jagt?

es spricht dagegen, dass man Sicherheitsrisiken schon vorher vermeidet (gerade bei PHP) und es einfach nicht tut, wenn es Alternativen gibt. Z.B. durch eine ordentliche Konfiguration und nicht durch das Auslesen von potenziell unsicheren Variablen von außen.

Außerdem ist

$PHP_SELF = filter_input(INPUT_SERVER, 'PHP_SELF', FILTER_SANITIZE_URL);

marginal besser (ersetzt nicht nur Zeichen, sondern validiert zusätzlich auf eine gültige URL). Aber wie bei allem, das ist immer noch nicht 100% safe

Deswegen besser einmal - wie geschrieben - eine feste Definition vorher oder eine eigene Validierung, z.B. ob das Ziel des action Attribut überhaupt plausibel auf Deinen Server zeigt (z.B. selbst mit einem RegEx zerlegen, Domain, Pfad checken, unerwartete Parameter filtern usw.). Wenn das Ziel tatsächlich nur das Script selbst ist, reicht auch nur ein einfaches action ohne echte Parameter... <form action="" method="get" class="form-example"> - damit geht man jedem solchen Streß aus dem Weg...

-> https://html.spec.whatwg.org/multipage/form…ssion-algorithm

Zitat

If action is the empty string, let action be the URL of the form document.

(Punkt 12 - im Moment... Doc kann sich jederzeit ändern...)

CU, Peter

Hay,

im Allgemeinen...

• macht man schnell mal print_r($_SERVER) oder ruft php_info() auf und dann sucht man einfach nach dem Wert, den man braucht und klärt dann auf php.net, ob das tatsächlich die geeignete Variable ist
• abstrahiert man solche (je nach php Version und Ausführungsart) potenziell ändernden Werte sofort in eine eigene Variable und schleppt diese überall durch, dann braucht man das nur einmal anzupassen. Ich kann mich erinnern als $PHP_SELF verschwunden ist (PHP4 auf 5?). Das war dann einfach, weil man einmal $PHP_SELF = $_SERVER['PHP_SELF'] deklarieren musste (und deswegen steckt diese Zeile noch in vielen, vielen langlaufenden Projekten noch drin). Abgesehen davon, dass man das aus Sicherheitsgründen so auch nicht mehr verwenden sollte, wenn es ums action-target eines Formulars geht...

CU, Peter

Hay,

Zitat von Gebby

Wie geschrieben, bei mir eben nicht.

das klingt jetzt so, als ob die Antwort nicht buchstabengenau gelesen worden wäre, deswegen lege ich nochmal den Finger drauf:

Du schreibst von $_SERVER['PHP_AUTH_USER'];

KB19 schreibt $_SERVER['REMOTE_USER'], was bei ihm sofort funktioniert.

CU, Peter

Hay,

lol, also wenn ich keine Lastschrift hätte, wäre ich ständig im Mahnprozess. Völlig ohne jeden Anlaß, außer dass ich die Zeit vergessen habe. Mein Zeitgefühl ist einfach katastrophal - außer im Projektgeschäft und beim Autofahren.

Eigentlich würde ich mir eher monatliche Sammelrechnungen wünschen...

CU, Peter

Hay,

Diesen Zustand wünscht sich Apache:

1. Es liegt eine Datei der genannten Namen (index.*) im httpdocs-Verzeichnis. Ja oder nein?

2. Wenn eine von diesen Dateien da liegt, hat sie Dateirechte 644 ("-rw-w--r--"). Ja oder nein?

CU, Peter

Hay,

Zitat von cadeyrn

Ein Website-übergreifendes Caching findet nicht mehr statt.

vielen Dank für den Hinweis. Da Fremdladen von Inhalten für mich eh' seit 2018 nicht mehr in Frage kommt, bin ich da nicht auf dem Laufenden geblieben

Heißt also das eigene Caching gut im Auge zu behalten, HSTS Features & Komprimierung zu benutzen und CDN's, die die eigene Domain mitliefern und nicht (wie früher Akamai) die Files einfach nur über die CDN-Server verteilt und mit akamai-Domain nachladen. Gut zu wissen.

CU, Peter

Hay,

Zitat von cadeyrn

da man die Schriften sowieso einfach lokal einbinden kann. Das ist dann sogar nicht gut für den Datenschutz, sondern auch für die Ladegeschwindigkeit der Website.

Rechtlich 100% korrekt, technisch leider nicht ganz so...

Die CDNs - also auch google fonts - sind ja dafür ausgelegt, dass die Chance, dass die Schrift schon im Cache ist, steigt, weil man sie schon von einer anderen Webseite geladen hat. Somit ist es für die Ladezeit eigentlich besser, wenn man sie von einem (virtuellen) zentralen Punkt aus lädt. Dasselbe gilt für jQuery, bootstrap und das ganze Gesocks, dass weltweit den Entwicklern die Arbeit leichter macht. Liegen sie auf einem anderen Server, muss die Dateien zumindest von diesem einmal runtergeladen werden - bei gutem, aktiven Cache-Management, bei keinem oder schlechtem häufiger bis immer.

Dass so viele Schriften insgesamt im Spiel sind, dass die Wahrscheinlichkeit einer vorhanden Schrift (ungleich OpenSans, ungleich Roboto) gegen 0 geht, ist mir dabei allerdings bewußt. In dem Fall muss der eigene Server den Font immer noch schneller liefern als das CDN - das kann man aber im Browser gut messen.

Trotz dieser technischen Einlassung sollte es aber keinen Dritten auf der Welt interessieren, dass Du dessen Dateien einsetzt und dafür eine IP und einen Browserfingerabdruck hinterlässt.

Also ja, alles selbst zur Verfügung stellen.

CU, Peter

Hay,

Zitat von Homwer

(kein Spruch... er hat echt gesagt dass es dafür derzeit keine Hardware gibt....)

errinnert mich an ein amazing EC3 Projekt in 2016/2017. Ich hatte eine Telefonanlage für 50.000 parallele Anrufe konzipiert und wollte die am Standort FFM hochfahren.

Brauchte damals flexibel skalierbar bis zu 160 Kerne und ich dachte in meiner Naivität, das wäre einfach so verfügbar, immerhin hat AWS mit dem flexiblem hoch- und runterfahren von Ressourcen geworben - und für besonders viel hielt ich das auch nicht.

Als ich dann buchen wollte, gabs erstmal ein "Stopp! WTF!" vom amazing consultant. Um die Maschinen zu belegen, musste erst noch Hardware nach FFM gekarrt werden und das hat VIER WOCHEN gedauert.

Gut, dass ich das schon früh im Projekt gemacht habe, "auf den letzten Drücker" wäre es schief gegangen.

CU, Peter

Hay,

Zitat von tab

scheint aber als Warnung gewertet zu werden

Wäre es eine Warnung, wäre es gelb.

Aber selbst das bißchen gibt schon einen Hinweis: Vermutlich schlägt ein fetch fehl - der Datenabruf für die Telemetriewerte? Daraufhin kann das promise-Objekt nicht richtig ausgewertet werden, welches wiederum (ebenso vermutlich) über einen Callback die Grafik zeigt. Klassischerweise ist e eine standardfaule Benennung für das eventobject, welches an den callback übergeben wird.

CU, Peter

Hay,

Zitat von tab

Ich würde ja sagen, das SCP ist kaputt, aber meine anderen Server werden alle korrekt angezeigt. Hatte schon mal jemand so einen Fall? Ich jedenfalls noch nie. Kann das an meiner Installation liegen bzw am installierten Debian 11 Minimal Image?

da wir gerade thematisch viel mit JavaScript vorgeprägt sind, kannst Du mal die dev-Konsole vom Browser öffnen, ob da ein roter JavaScript-Fehler kommt? Ich vermute nämlich irgend ein undefined oder Wert, der außerhalb der Skala liegt, weswegen das Grafiktool bei dem Server einfach mit einem error aufgibt

CU, Peter

Hay,

Zitat von KB19

Aber was man da draußen oft sieht, ist genau das Gegenteil.

Äähm. Ja. Bei solchen Dingen gehe ich davon aus, wie ich es tun würde und denke mir, dass es jeder so handhabt. Aber ich komme ja nicht frisch aus einem Coding Bootcamp...

Viele vermischen halt alles, was normalerweise klar sein sollte. HTML für die Struktur und Semantik der Webseite, CSS fürs Aussehen und JavaScript für die Funktionen, die man zusätzlich braucht.

Bissl ARIA (oder role=), falls ein <div> mit onClick eigentlich ein <button> oder ein <a> ist. Das ist auch so eine Unsitte, aber so etwas handelt man sich leider öfters durch externe libs ein... ich musste mal ARIA-Attribute für eine Anwendung von uns nachpflegen. Bei Elementen, die durch externe Libs aufgebaut wurden (Anordnung der Elemente mit <table> statt mit <div> und entsprechendem CSS!!) musste ich das teilweise per JavaScript der Seite beim domready hinzufügen. Das hilft einem Braillebrowser während des Seitenaufbaus zwar nicht, aber wenigstens sobald alles da ist.

Manchmal fällt die Trennung schon etwas schwer, aber letztlich zählt, wie es zum Schluss repräsentiert ist. Ich schreibe per JavaScript HTML-Elemente in die Seite, ich weise CSS-Klassen zu. Ungern schreibe ich einen Style direkt, lieber lege ich im CSS eine neue Klasse an, dadurch kann jeder Frontendler das Design anpassen.

CU, Peter

Hay,

Zitat von KB19

... wenig bis keinen Mehrwert hat. Wozu muss z.B. eine Auswahlliste mit JS gebaut werden, wenn <select>/<option> ebenfalls reichen würden? ...

Steilvorlage... damit habe ich mich in den letzten Wochen beschäftigt, unter anderem habe ich dieses tagging-Control entwickelt.

Image1.png

Ich möchte sehen, wie man ein solches Control (mit Datenanbindung, Suche, Mehrspaltigkeit, clientbasierter PlausiCheck bei hinzufügen von Tags/Löschen von Tags) per option/select baut... Alternative wären vier multi-select Drop-Downs gewesen und von der UI wäre es dann ... naja... 1994?

CU, Peter

Hay,

Zitat von KB19

JS das moderne Flash und nicht ungefährlich ist

sehe ich nicht so. Flash war eine einzelne Firma, die es verbrochen hat.

Und bei den allgemeinen Sprachgefahren (sei es ein Buffer over/underrun unter C oder log4J) ist JavaScript auch nicht so weit vorne dabei. Unfähige JS Programmierer (nicht die Programmierer der Sprache, sondern die Programmierer, die JavaScript nutzen - oder eine JS Injection ermöglichen - weil aus einem Formular ungeprüft in eine Datenbank und von da ungeprüft wieder zum Client - Backend-Programmiersprache austauschbar) sind die Hauptgefahr, danach die Browserimplementierung. Wir werden ggf. bald noch mehr bei serverseitiger Implementierung (node.js) sehen, dann wirds in der Tat gefährlich.

CU, Peter

Hay,

okeeeeey... so you are using your server as a desktop, not as a webserver?

CU, Peter

Hay,

what I see in the video is some lazy loading of media, which is not very fast. I don't think, that is the server in the first row (except it is a single core with SAS HDs), you should think about an effective cache strategy (Proxy) or a CDN (Cloudflare). You can test this with the load/runtime analysis in the dev mode of a browser, there are some parameters, which can show some information what is lagging (delivering of the first byte, start transmission, speed etc.).

But there are very much answers possible, from hardware over misconfigurations to CDN...

CU, Peter

Hay,

aus der Praxis mit Plesk: Ich habe 2020 einen alten Server gekündigt und mir einen neuen geholt, komplett neu aufgesetzt, Plesk trial installiert, mirgrationstool gestartet, die Lizenznummer in den neuen Server eingetragen und ich weiß nicht mehr, was ich mit dem alten Server diesbezüglich getan habe - kann sein, dass ich bei dem dann die Nummer gegen die vom trial getauscht habe (oder gar nichts, oder gelöscht, weiß nicht mehr, ob das geht). Ich habe beim alten aber die automatischen Updates abgeschaltet, Backups etc. was so an automatischen Prozessen bei Plesk so läuft.

Jedenfalls läuft der neue Server seitdem mit meiner alten Lizenz und es gab nix zu meckern. Die Lizenz ist glaube ich an die Domain gebunden, mit der der Server erstmalig aufgesetzt wurde (also nicht die interne netcup, sondern die echte). Waren auch ca. 80 Domains.

Und da ich Domain-Reseller bin, verwalte ich meine Handles sowieso selbst und da kann ich mich frei entscheiden, ob ich die Daten im Handle anpasse oder neue Handles mit neuen Namen erstelle. Sauberer wäre letzteres, aber die erste Variante geht auch... Jedenfalls ziehe ich keine Domain, die irgendwie unter meiner Kontrolle ist, von einem Account auf den anderen mit einem Auth-Code um. Wäre mir außerdem viel zu teuer

CU, Peter

Hay,

das mit dem Warten haben wir alle schon mal duchgemacht.

Relativ einfache Methode - ohne externe Tools - ist (bei Windows; Linux ist es eher "dig" und Paket muss installiert sein) einfach mal "nslookup meinedomain.de" einzugeben und zu schauen, welche IP-Adresse das anzeigt. Ist es die alte, ist zumindest der DNS Deines Zugangsproviders noch nicht aktualisiert. Sobald da die neue Netcup-IP erscheint, kannst zumindest Du darauf zugreifen.

Die DNS-Server 1.1.1.1 und 8.8.8.8 werden ziemlich schnell aktualisiert, deswegen kannst Du mit "nslookup meinedomain.de 1.1.1.1" mal testen, ob zumindest diese schon Daten haben.

CU, Peter

Hay,

jetzt kommt auch bei mir die statische HTML und nicht mehr das generische "Domain noch nicht zugewiesen".

Da hat sich im Zeitablauf endlich etwas ordentliches durchgesetzt.

Hinweis: Zeitpunkt der Beantragung der Domain spielt dabei keine Rolle, es spielt der Zeitpunkt eine Rolle, bei der zum letzten mal DNS beeinflusst wurde - das KANN bei Beantragung einer Inklusivdomain der Zeitpunkt der Beantragung sein, aber als externe Domain ist das der Zeitpunkt, zu dem sie einem Webhosting zugewiesen wurde.

Außerdem ist das jetzt das plesk-Zertifikat aktiv und nicht mehr "kein Zertifikat", also hat Plesk jetzt die Kontrolle übernommen. Dann sollte jetzt auch ein Beantragen des Lets Encrypts funktionieren (unabhängig von den anderen mittlerweilen aufgelaufenen Fragen).

Da eine statische index.html da ist, kann das auch sofort überprüft werden. Aber bitte daran denken, es mit einem Browser mit frisch gestartetem Incognito/privaten Fenster zu überprüfen, weil ich öfters gemerkt habe, dass Zertifikate (oder nicht bestehende Zertifikate) teilweise ätzend lang gechached werden und selbst mit einem Shift-Reload nicht rauszubekommen sind.

CU, Peter