warum?
1. Unfallgefahr - Keine Lust auf nochmal....
2. Schnee = Klätte + Matsch + Dreck
3. Fahr mal Auto
Beiträge von Syntafin
-
-
Schnee ist doof
-
wenn du VPN benutzt sind diese daten natürlich falsch
Natürlich ist WireGuard immer aktiv
und dennoch werden nur Anfragen an den Server und die anderen dadurch geleitet.
Als Hostname steht da übrigens deine eigene IP bei mir
-
OS falsch, Browser falsch, Hostname falsch
-
Da sind keine Daten die bei einer Datenauskunft gefragt sind dabei.
-
Ja, dafür gehen dann Daten an zb OpenAI
-
Gehen Nutzerdaten an OpenAI muss das zwingend in die Datenschutzerklärung.
Ansonsten: Nein. -
Ich glaube die Idee mit Matheaufgaben werde ich Mal im kleinen Rahmen später testen, Bots zu triggern ist ja einfach
. -
lol was war der Vorwurf?
Illegales Klickverhalten, Konto ist bis heute gesperrt. Müsste also neues Google Konto machen und dort neu beantragen, ist ja normalerweise nicht so einfach, da ja klarnamen Pflicht dabei XD.... Aber zum Glück gibt's Sonderfälle.
-
FriendlyCaptcha - kostet halt
Schaue ich mir später Mal genauer an.
Je nach notwendigkeit ich mache für Formulare meistens ein disable-alle-buttons-und-löse-eine-Rechenaufgabe-mit-JavaScript-um-die-zu-aktivieren. Lässt sich zwar easy selber in der Dev-Console umgehen, hält aber Bots fern.
Wäre ja Mal ein Test wert wie gut das geht, sollte halt nicht zu kompliziert sein
aber die Methode könnte halt in Zeiten von LLMs nun doch Recht einfach zu umgehen sein. -
aber solange man die Einwilligung einholt sollte alles im grünen Bereich sein.
Da fängt es ja schon an, ich würde ohne nervigen Cookie Consent ja auskommen gerne.
-
Da ich schon länger keine Captchas mehr verwendet habe, stehe ich aktuell vor der Frage welche DSGVO konforme Möglichkeiten es da gibt, vor einfachen Frage/Antwort Möglichkeiten will ich absehen, da das ja viel zu einfach über Texterkennung gelöst werden kann und in Zeiten von LLMs für wenig Geld eh nichts mehr bringen wird.
Floodprotection Mal außen vor, die ist eh per Default umgesetzt.
-
Besser sie brauchen länger, als das es dir ergeht wie mir damals, schnelle Prüfung und dann zwei Wochen später (noch nicht Mal im Einsatz dann) gesperrt wegen angeblichen Missbrauch XD.
-
Es ist aktuell auf http Niveau definiert, hab es auch schon auf Server und Location Ebene probiert, jedoch stets das selbe.
client_max_body_size ist ja die Einstellung die du meintest, etwas verzwickt also, vielleicht denke ich Mal daran ein Ticket bei NGINX zu eröffnen um das herauszufinden.
-
Lies Mal den Eingangspost
-
Darfst gerne bei den offenen Fragen dich einbringen
, zB ist:Request Entity To Large
Hallöchen,
gerade beim testen von größeren Uploads (Bild mit 30mb) gesehen, das mein NGINX Server trotz einer erlaubten Body size von 2GB dieses ablehnt mit der Fehlermeldung Request Entity To Large.
Jetzt stehe ich gerade natürlich ein wenig auf dem Schlauch, jemand eine Idee ob das noch von einer anderen Einstellung kommen kann die ich gerade nicht auf dem Schirm habe?
Noch immer ungelöst (wenn auch ich die Lösung nicht als kritisch erachte, dennoch rausfinden will wieso die settings ignoriert werden xP).
-
Weil es ein Shitcoin ist, hab ich doch schon gesagt.
-
Radix ist auch ein Shitcoin, Finger weg davon.
-
Du musst deine Mail noch bestätigen.
SQLUPDATE "public"."users" SET "email_verified_at" = NOW() WHERE "id" = 1; -
Mein neues super sicheres Password
Kleine Edit Info, das ist ein tatsächliches Passwort in einer Staging Instanz