Beiträge von MicNC

Zitat von ThomasChr

Also für das was du vorhast klingt das mit Dateien problemlos machbar. flock() brauchst du auch nur fürs Schreiben.

Das mit dem Lesen, da habe ich auch überlegt, ob "flock()" nötig ist. Die KI hat's halt hinzugefügt. Aber die entsprechenden Dateien, werden ja NUR gelesen. Ich könnte mir vorstellen, dass man hier "flock()" nutzen muss, wenn an anderer Stelle (anderer Prozess/Besucher) auch ein Schreibzugriff erfolgt. Damit in beiden Situationen (Lesen und Schreiben) es nicht kompliziert wird, wird dann wohl beim Lesen und Schreiben "flock()" eingesetzt.

Danke für die Infos.

Also es geht ja nur um den Blog bei mir.
Derzeit ist das so:

URL = /blog/hugoistbauarbeiter
URL = /blog/supermankannfliegen

Entsprechend wird "hugoistbauarbeiter.dat" oder "supermankannfliegen.dat" gelesen. Diese Dateien erstelle ich manuell. Im Grunde nur ein HTML-Code mit dem Text über Hugo oder über den tollen Superman *lach. Eine Seite mit dem Blog-Artikel ist ja nicht immer gleich, sprich es werden Design-Elemente genutzt und für neue Artikel dann auch mal etwas in der eigenen Blog CSS-Datei hinzugefügt. So bin ich hier sehr flexibel, kann das alles vorab Lokal testen, bevor ich diese Datendateien per FTP hochlade.

Die Kommentare werden durch ein Formular erst mal in einer extra Datei gespeichert. Wie schon erwähnt, entweder für ein Besucher-Kommentar oder für die Spam-Bots. Kommentare werden vor Veröffentlichung erst geprüft und manuell zu der Datendatei dann hinzugefügt. Also wenn jemand einen Kommentar über unseren tollen Superman hinterlassen möchte, kommt dieser später in die "supermankannfliegen.dat" rein. Als Marker, wo die Kommentare beginnen nutze ich einfach sowas wie "---kommentare---". Alles was darunter steht, sind die Kommentare und diese kann ich dann ebenfalls leicht mit HTML-Code anpassen, damit alles schön ausschaut. Wie gesagt, alles wird vorher Lokal getestet (wegen Design). Gerade dieser Test finde ich sehr vorteilhaft. Ok, mit einer Datenbank kann man das dann auch (wenn man es entsprechend programmiert) aber ich finde das in meinem Fall sehr gut gelungen. Die Artikel haben nämlich auch manchmal sehr anspruchsvolle Design-Bereiche, sprich Texte die per klick eingerollt werden oder eine Art Ebene über ein Bild, welches Text beinhaltet. Da muss ich schauen, dass alles passt. Und das geht halt recht gut, so wie ich es habe. Alles ohne CMS. Ich arbeite nur mit dem Notepad++. Das ist so meine Arbeitsweise.

Aber die technische Seite wegen dem Lese, Schreibzugriff sagt ja, eine Datenbank wäre besser. Und bevor ich das alles etwas ändere, kam mir die Idee mit dem "flock" und was mir dir KI da ausgespuckt hat, schaut ja ganz positiv aus. Also das mit den 12 versuchen, max. 3 Sekunden. So wäre (wenn es technisch so ist) ja ein wenig Sicherheit dabei, wenn zufällig mehrere Besucher auf meiner Webseite sind. Die Datendateien werden nur von mir beschrieben, also der Besucher hat hier nur ein Lesezugriff. Somit sollte das erst mal sehr gut gehen. Aber auch der Schreibzugriff für die Kommentare, die erst in einer extra Datei gespeichert werden, ist mit diesen "flock" versehen. Ich kann mir das eher nur alles in der Theorie vorstellen. Wie es letztendlich wirklich ist, wenn mehrere Schreibzugriffe zeitgleich stattfinden und wie hier "flock" gut oder schlecht arbeitet, dazu kann ich selbst nichts sagen. Aber der Code schaut ja recht vernünftig aus.

Letztendlich werden meist nur Lesezugriffe stattfinden und wenn es um Kommentare geht, sind es wohl mehr Spam-Bots, als echte Besucher. Bei den Spam-Bots wären Schreibfehler sowieso egal. Ich will die nur etwas protokolieren, um sie etwas zu filtern, ggf. sie per ".htaccess" zu sperren, wenn das überhaupt heute noch Sinn macht? Ich kenne das von früher so. Und wenn dann mal ein echter Besucher ein Kommentar hinterlassen möchte wird der Fall eher selten bis gar nicht eintreten, dass hier mehrere gleichzeitig was abschicken wollen. Aber wenn doch, diese paar Besucher... ich denke da müsste doch das "flock" gut arbeiten mit diesem KI generierten Code mit den 12 Schreibversuchen.

Deswegen frage ich mich halt, ob ich mir deswegen SQL reinziehen muss. Und ich hasse neue Benutzernamen und Passwörter *lach. Braucht man ja wieder bei SQL. Weiterhin kann SQL auch Probleme verursachen. Dort gibt es auch mal Verbindungsfehler. Also warum der ganze Stress, wenn es jetzt nur um ein paar Kilobyte an Blogdaten geht. Nur diese Schreibzugriffs Geschichte sollte dann doch etwas funktionieren, wenn zufällig jeder meiner Besucher gleichzeitig über Superman einen Kommentar abschicken will.

Natürlich bietet SQL viele Vorteile aber die Blogdaten müssen nicht sortiert werden. Auch eine Blogsuche benötige ich nicht. Also die schönen Funktionen, die SQL bereitstellt, brauche ich eigentlich gar nicht für meinen Zweck.

Eine Sache noch, wegen Datenbank vs. Datendatei.

Ich hatte mich an etwas erinnert. Thema "flock" und schnell mal die KI gefragt. Geht schneller als es selbst zu machen

Speichern:

$dateiname = 'datei.txt';
$max_retries = 12; // 3 Sekunden / 250 Millisekunden = 12 Versuche
$retry_count = 0;
$locked = false;

while ($retry_count < $max_retries && !$locked) {
    $handle = fopen($dateiname, 'a');
    if (flock($handle, LOCK_EX)) {
        fputs($handle, "Neue Zeile\n");
        flock($handle, LOCK_UN);
        $locked = true;
    } else {
        $retry_count++;
        usleep(250000); // 250 Millisekunden warten, bevor erneut versucht wird
    }
    fclose($handle);
}

if (!$locked) {
    echo "Kann die Datei nach $max_retries Versuchen nicht sperren.";
}

Lesen:

$dateiname = 'datei.txt';
$max_retries = 12; // 3 Sekunden / 250 Millisekunden = 12 Versuche
$retry_count = 0;
$locked = false;

while ($retry_count < $max_retries && !$locked) {
    $handle = fopen($dateiname, 'r');
    if (flock($handle, LOCK_SH)) { // Gemeinsame Sperre setzen
        $list = file($dateiname);
        flock($handle, LOCK_UN); // Sperre lösen
        $locked = true;
    } else {
        $retry_count++;
        usleep(250000); // 250 Millisekunden warten, bevor erneut versucht wird
    }
    fclose($handle);
}

if (!$locked) {
    echo "Kann die Datei nach $max_retries Versuchen nicht sperren.";
}

Ob nun für ein Blog (Kommentare speichern) oder ggf. auch für eine LOG-Schreiberei. Wäre das denn so in Ordnung? Das müsste doch ausreichen für eine normale Webseite? So wäre dann wenigstens etwas Prüfung und Wiederholungen dabei, damit die Chance des Schreibens und Lesens in einer Datei erhöht wird.

Klar, ich versteh schon. SQL-Datenbank ist letztendlich wenn man alles richtig macht, viel angenehmer. Man hat halt viele Möglichkeiten. Würde ich jetzt auch ganz klar nutzen, wenn die Daten zu wichtig wären. In meinem Fall ist das halt nur ein Kommentarsystem. Mit gewissen Tricks versuche ich dann auf der einen Seite (normaler Besucher), den Kommentar zu speichern und auf der anderen Seite (Spam Bots) die Daten in eine LOG-Datei zu speichern. Es werden wohl mehr Bots vorbeikommen, als Besucher *lach aber ich wollte noch mal nachfragen, ob das mit diesem Code (also das mit flock um zu sperren) ausreichend wäre. Ich betreibe ja auch kein Facebook, Instagram etc. wo tausende von User gleichzeitig auf meiner Webseite sind. Das würde mit diesem kleinen Netcup Paket wohl sowieso nicht gehen.

Aber die KI ist schon Cool. Sie hatte mir einen einfachen Code geschrieben und ich bat die KI noch, dass ich gerne mehrere Versuche haben möchte, bevor letztendlich die entsprechende Fehlermeldung ausgespuckt wird. Und Ruckzuck hat die KI es mit 1 Sekunde (10x100ms) mit angeboten. Ich schrieb dann noch, ich hätte lieber 250ms und 3 Sekunden. Ruckzuck wurde der Code angepasst

Ok, Danke für die Infos.

Noch kann ich ja das ändern. Der PHP-Code ist noch nicht so groß. Wenn ich das erst mal angefangen habe, werde ich SQL natürlich selbst schätzen. Letztendlich wird es aber wohl so sein, dass sehr selten jemand einen Kommentar abgibt, da jeder auf Facebook und Co. seine Meinung der Welt unbedingt mitteilen möchte und kein nerv mehr frei hat, auf einer Webseite zu kommentieren. *lach

Zitat

...nach Jahren versuchst, Deinen Code bzw. die damaligen Gedankengänge nachzuvollziehen.

Ja, dass kenne ich mit Delphi. Ein ehemaliges Projekt mit sehr vielen Codezeilen. Hatte mal ca. 2 Jahre pausiert und trotz eigenen Kommentaren im Code, brauchte ich eine Weile, bis ich mein Salat selbst wieder verstanden hatte

Ist das nicht Aufwärtskompatibel?
Das frage ich mich gerade, ob man stets bei neuen PHP-Versionen seine PHP-Scripts immer erneut überprüfen muss

Was spricht eigentlich für eine Datenbank in meinem Fall?
Natürlich kenne ich die Vorzüge einer SQL Datenbank. Auch wenn ich noch nicht so viel damit gemacht habe. Eher war ich zu faul und nutze z.B. für die Kommentarfunktion einfach eine Text-Datei, die auf meinem Server erstellt wird. Die ist nämlich sowieso schon vorhanden, sprich jeder Blog-Artikel besteht aus einer Text-Datei. Die habe ich so aufgebaut, dass ich einfach mit HTML drauf los schreiben kann. Ich nutze nur Notepad++. Also ich habe kein Wordpress oder was anderes. Die ganze Webseite ist eigenes HTML, CSS, PHP usw.

Unterhalb der HTML-Daten habe ich nun ein Marker gesetzt (z.B. "---kommentare---") und mit PHP entsprechend meine Seite aufgebaut, damit der Blogartikel erscheint und die Kommentare dazu. So kann ich die Kommentare (die sowieso erst einer Prüfung unterliegen) auch gleich mit HTML verarbeiten. Ich finde, dass geht dann alles Ruck-Zuck, so ganz ohne CMS. Einfach in den FTP-Server einloggen, die Daten verarbeiten und fertig.

Da es sich hier ja nicht um Megabytes von Daten handelt, eher wohl max. 10-20kb pro Datei (+Kommentare ein paar Bytes mehr), verzichtete ich gleich am Anfang, mich mit SQL zu beschäftigen. Eher sehe ich ein Vorteil, da mit SQL wieder neue Verbindungen aufgebaut werden (kann ja dann auch mal nicht funktionieren), ich sie erstellen muss, neues Passwort usw. benötige und bei Änderung (neue Felder oder der Typ von einem Feld etc.) ich eigentlich viel mehr Zeit benötige. So wie ich das habe, kann ich schnell eingreifen und weil ich alles selber gemacht habe, sind irgendwelche Änderungen auch schnell erledigt.

Also was spricht für eine SQL-Datenbank für ein paar Kilobytes an Daten oder was spricht dagegen, wenn ich mit PHP meine Daten-Dateien auf meinem Webserver erstelle, lösche, ändere?

Info: Noch kann man im Browser manuell eingeben (.z.B. https://domain.de/daten/blog/artikel-dsgvoistdoof.gtl) und auf die Datendateien zugreifen. Der Inhalt wird dann clean im Browser angezeigt. Das sollte natürlich noch vermieden werden. Die sollen ja nur mit PHP gelesen werden. Muss noch schauen, wie ich das mache. Geht wohl irgendwie mit ".htaccess".

Zitat von MyMattes

Die Frage ist nur, was Dir das hilft? Die IP ist ein personenbezogenes Datum und dazu - auch aus Log-Dateien - müsstest Du auskunftsfähig sein. Wenn (oder besser: falls) jemand das einklagen würde, wäre „andere machen es auch nicht“ eine schlechte Verteidigung.

Man beachte den Konjunktiv: Ich glaube nicht, dass irgendjemand wegen der Auskunftspflicht von Accesslogs klagt. Aber man sollte sich der Möglichkeit bewusst sein und im Zweifelsfall mit dem Risiko leben. Oder eben bei Anfragen einen Auszug der Log - so noch nicht weg rotiert - bereitstellen. Ich habe noch keine entsprechenden Aufforderungen erlebt…

Man muss sich halt irgendwie schlau machen. Das will Thomas ja auch. Deshalb meine Idee. Ich glaube alles einen Anwalt zu überlassen, kostet viel Geld. Bei mir ist's z.B. so, dass ich mir die ganzen Erklärungen, AGB etc. selber schreiben muss. Einfach kein Geld dazu. Erstelle ja auch kein Konzern, sondern nur ein freiberufliches Mini Einzelunternehmen *lach

Wie "aRaphael" schrieb:

Zitat

Dann müsste er dir aber auch die ip angeben, für die er Auskunft haben will und nachweisen, dass es seine ist.

Ansonsten kannst du die Auskunft ja aus Datenschutzgründen nicht geben.

ist's ja wohl am einfachsten. Aber wie du sagtest "keine entsprechenden Aufforderungen erlebt", wird es wohl dann auch bei den meisten so sein.

Es gibt wohl andere Stellen in der Rechtswelt, die wichtiger sind, diese zu verstehen und entsprechend zu handeln. Aber verrückt sind die Erfinder der DSGVO etc. ja schon irgendwie *lach

Zitat von ThomasG.

Dann kann man abschließend annehmen, dass diese "Pflichtangaben" nicht ganz zutreffend sind, wenn es sich nur um Serverlogdaten handelt und man sonst nichts speichert. Ich nehme an sowas wie "Recht auf Auskunft, Berichtigung, Sperrung, Löschung" ist nur eine Pflichtangabe die in dem Datenschutz stehen muss, aber nicht praktikabel umsetzbar ist in meinem Fall und daher mit einer Antwort wie die von NaN entgegnet werden muss.

Ich kämpfe gerade auch an solchen Dingen, wie Datenschutz, AGB, Widerruf usw. Also ich leide mal ein wenig mit dir

Meine Idee wäre (vielleicht mache ich das noch selbst), auf eine IT-Anwalt-Webseite, 2-3 Tage mal etwas herum zu surfen und dann einfach mal sein Recht auf Auskunft einholen lassen. Die Antwort von denen, wäre dann wohl interessant Ich denke mal, die schreiben dann nur, dass sie keine personenbezogenen Daten haben denn dieses Thema bezieht sich dann wohl nur auf Kundendaten die eine Firma verwaltet, ggf. eine Kommentarfunktion (wenn Email abgefragt wurde) oder vergleichbares. Wenn Du nur in den Logs mit der IP bist, schreiben die sicherlich das sie keine Daten über dich haben.

Zitat von fvbor

Problem ist nur: Damit grenzt du Leute mit einer Sehbehinderung aus, welche genau auf solche Tools setzen und dich via Impressum kontaktieren wollen. 🤔

Ne, eben nicht. Das will ich ja beachten. Weiter oben schrieb ich ja schon, dass so gewisse einfache CSS Hacks gar nicht genutzt werden können, weil einfach der Screenreader nicht mehr funktioniert. Schon alleine ein Zeichensalat in der Mitte der Mail-Adresse (welches man mit CSS ausblendet), mach der Screenreader wieder sichtbar. Toll wäre gewesen wenn man mit "content:"text" in der CSS arbeiten könnte, sprich hier ein Buchstabe, dort ein HTML Entitie... aber das stört auch einen Screenreader. HTML Entities gehen nur direkt. Da lacht nur der Spambot drüber, denke ich mal.

Also es bleibt wenig übrig und ich bin hier immer noch im <noscript> Bereich.

Jedenfalls habe ich im "herf" für die Mailadresse das "mailto:" entfernt und es wird eine index.php in "/impressum/mail" aufgerufen. Dort dann:

<?php
header("Location: mailto:info@domain.de");
exit();
?>

Zumindest gibt es dann kein "mailto:" für die Spambots. Frage mich aber ob ich in dieser PHP noch die normalen Suchmaschinen ausschließen muss?
Denn der Pfad zu "/impressum/mail" wäre ja erst mal ein normales Ziel. Da wird Google und Co. auch vorbeischauen wollen. Denke aber mal, die checken das schon und wissen dann, dass hier keine HTML-Seite dahintersteckt. Der ganze HTML-Kopf Bereich fehlt ja.

Wegen Spam. Ich glaube es gibt aber noch einen anderen Ansatz für die .htaccess. Kenne ich von früher, da sperrt man IP-Adressen und gewissen User-Agents aus. Nur kann man die wohl auch nicht so extrem befüllen (denke ich mal), da diese ja stets gelesen werden muss. Ob das heute noch geht? Spambots entwickeln sich ja auch weiter und suchen Gegenmaßnahmen. Die sind leider nicht so lieb und nicht alle sagen in ihrem Useragent "Hallo, ich bin ein böser Bot"

Man könnte aber ggf. auf der entsprechenden Impressum Seite auch mit PHP gewisse IP-Nummern und User-Agents aussperren und die Mail-Adresse gar nicht anzeigen lassen. Aber da müsste man wie gesagt, einen Spam genau identifizieren können.

Zitat von MyMattes

Ich meine, Du verkomplizierst unnötig: Einfach eine Kontakt-Adresse (auch als Link) angeben und den Spam-Filter so optimieren, dass der offensichtliche Schrott direkt aussortiert wird: Alles wirst Du eh nicht vermeiden können und bei einer regelmäßigen Sichtung erkennt man Spam sofort.

Ohne Werbung für "Männerarztnei", Bürostühle, Solaranlagen, App-Entwicklung und SEO-Optimierung wäre mein Leben richtig eintönig

Ja, hast schon recht aber man kann ja versuchen, ein wenig auszuprobieren und ggf. dabei die perfekte neue Anti-Spam-Idee zu erfinden *lach
Habe mal versucht das "@" Zeichen zu drehen. Das wäre Optisch noch in Ordnung für die Besucher aber OCR-Tools finden dennoch ein normales "@". Also wird so ein Spambot mit OCR dann auch schlau daraus

So ein Screenreader (ich nutzte den von Edge) arbeitet aber auch nicht korrekt.

In meiner "impressum/index.php" wird bei dem a-Tag ein normales "mailto:name@domain.de" im Screenreader als "/impressum/mailto:name@domain.de" umgewandelt. So wird ja dann im Screenreader kein Email-Programm geöffnet.

Ich wollte aber sowieso beim a-Tag eine falsche Email mit Schrägstrich angeben. Also "/mailto:falschemail@domain.de" und mittels ".htaccess" auf eine PHP-Datei umleiten, damit ich dort intern ein richtiges "mailto:" (also ohne Schrägstrich) ausführen kann. Aber das mit dem "Doppelpunkt" in der URI macht irgendwie Probleme. Immer ein 403er Fehler. So war aber meine Idee, die Spambots etwas zu verwirren

Aber die Textform der richtigen Email-Adresse bleibt ja. Das muss so und wie gesagt, die paar CSS Tricks für den <noscript> Bereich um intern die Adresse zu verschleiern kann man fast nicht anwenden. Zumindest nicht alle. Da spuckt der Screenreader was falsches aus. Also wird so ein Spambot die einfachen Tricks leicht erkennen und er hat die richtige Email-Adresse schnell ausgewertet.

Ich mache jedenfalls dann mal "mailto" ganz raus. Die Email gibt es nur als Textform aber optisch als normaler Link und wenn man draufklickt, bekommt man eine Info, dass man die Adresse manuell in seinem Mail-Programm eingeben muss. Diese Klick-Simulation geht noch mit einer versteckten Checkbox + Label & CSS im <noscript> Bereich.

Zitat von KB19

Es würde mich wundern, wenn Screenreader mit diversen CSS-Tricks (ohne JavaScript-Tricksereien!) nicht klar kommen. Eine HTML-Website ohne jegliches CSS entspricht jedenfalls nicht dem Stand der Technik und wäre mehr als unüblich.

Ich habe das zumindest mit diesem Umdreh-Trick ausprobiert. Also die Buchstaben verkehrt rum. Dafür gibt es ja ein CSS-Trick. Der ScreenReader (oder das vorlesen vom Browser) hat da jedenfalls versagt.

Zitat von Win98SE4ever

Als Privatanwender stelle ich mir die Frage (hab nicht recherchiert) ob es auch eine Pflicht zum Lesen/Bearbeiten/Beantworten der E-Mails gibt und was denn eine verhältnismäßige Ordnungsbuße für einen zu scharfen Spamfilter sein könnte, durch den leider genau die streitgegenständliche Mail aussortiert wurde...

Wichtig: Es dürfte keine rechtliche Regelung geben die fordert, dass die Impressum-Zwangskontakt-Mail dieselbe sein muss wie die Bestellungs- oder Support-Mail des Unternehmens...

spam@domain.tld würde ich sie zwar nicht nennen, aber ein separates Postfach wäre logisch...

Dass man regelmäßig (evtl. mit innerbetrieblicher Organisationsregel) durch den Spam scrollen sollte, versteht sich selbst und dürfte unter betriebliche Nebenkosten fallen (wie das Putzpersonal, Geschäftswagen zur HU und Kundendienst fahren, ...).

Ob nun bei der Kontrolle menschliche Fehler (sinnvolle Mail in Unmengen Spam übersehen) überhaupt bestraft werden kann, sehe ich kritisch.

Kannst Du bitte noch Deine Quellen nachreichen?

Hast die vielleicht noch im Browser geöffnet. Das erleichtert einem die Suche.

Alles anzeigen

Alles im Browser schon geschlossen.
Aber...
EMail-Pflichtangabe:

Das Problem, jeder schreib was ab. Ein wenig hier ein wenig da. Nichts ist genau. Die Hauptquelle sagt nur:

(1) Diensteanbieter haben für geschäftsmäßige, in der Regel gegen Entgelt angebotene digitale Dienste folgende Informationen, die leicht erkennbar und unmittelbar erreichbar sein müssen, ständig verfügbar zu halten:
§ 5 I Nr. 2 DDG

"Angaben, die eine schnelle elektronische Kontaktaufnahme und eine unmittelbare Kommunikation

mit ihnen ermöglichen, einschließlich der Adresse für die elektronische Post,"

Aber es gibt dann auch "§ 18 MStV".

Irgendwo macht es dann auch einen Unterschied ob man TV+Radio anbietet oder im Shop irgendwas verkauft.

Aber wegen Email gibt es auch ein Gerichtsverfahren (Az. 5 U 32/12) :

Jedenfalls hört sich im allg. alles so an:
Man braucht eine Email-Adresse in Textform + eine andere Form der Kontaktmöglichkeit
Nummer 2 kann dann eine Telefonnummer sein oder ein Kontaktformular. Also entweder oder.

Viele schreiben dann wegen der Barrierefreiheit. So genau ist mir das anhand einer Hauptquelle nicht gerade klar... ich habe so viele Seiten gelesen. Mein Kopf ist voll Aber es macht ja Sinn denn es geht ja im Grunde um alle Menschen, die ein Recht auf diese Informationen haben. Deswegen muss das mittels ScreenReader oder Texte vorlesen auch funktionieren.

Natürlich kann man eine extra Email nehmen, damit man seine gepflegte Email-Adresse nicht irgendwann wegen zu viel Spam in den Müll schmeißen muss. Aber man muss diese ja dann auch prüfen und bei vielen Spams und schlechten Filter... alles kostet Zeit. Aber besser so, als nur die Haupt-Email.

Und wegen "eine Pflicht zum Lesen/Bearbeiten/Beantworten"... irgendwo habe ich auch etwas gelesen, dass man im kurzer Zeit auch darauf reagieren muss (z.B. wenn man einen Shop hat). Manche schreiben von 1 Stunde, manche von 3 Stunden. Alles schon gelesen.

Ich dachte ja die ganze Zeit, die Email kann man weglassen und ein Kontaktformular einsetzen.

Aber nee, gerade gelesen, eine Email in Textform ist verpflichtend.

Na gut dachte ich, dann wenigstens ein paar CSS Hacks. Jedoch kann man z.B. das umdrehen eines Wortes mit CSS dann auch schon vergessen. Es schaut nämlich so aus, dass die Email sogar Barrierefrei sein muss und "laut vorlesen" sowie "Screen Reader" funktionieren dann nicht mit diesem "umdreh"-Trick einzelner Wörter. Da bleibt dann echt nicht viel übrig um seine Email-Adresse verschleiern zu können.

Auch denke ich, dass im <noscript> Bereich rechtlich gesehen, die Email auch vorhanden sein muss. Deshalb bleiben die wenigen CSS Möglichkeiten. Um Javascript wollte ich mich eigentlich danach kümmern. Aber das ist sowieso alles schwierig geworden, da OCR recht gut funktioniert und Spam Bots das auch schon einsetzen. Also bringen die ganzen Tricks dann eigentlich auch nichts mehr und wegen dem Thema "Barrierefrei" ist man sozusagen gegen Spam machtlos geworden.

Also doof gelaufen

Hallo,

ich benötige persönlich keine Web-Statistiken. Also ich habe diesbezüglich die Sache deaktiviert. Kann zwar sein, dass ich das mal wieder ändere, um Probleme zu lösen aber ich gehe erst mal davon aus, dass ich solches nicht benötige. Mir geht es gerade um die Datenschutzerklärung. Es gibt ja nun auch diese Server-Logs, die ich selbst nicht deaktivieren kann. Ich habe mal geschaut, was dort so gespeichert wird (unter Protokolle).

Das wäre dann:

Datum und Uhrzeit

IP-Adresse

Browser-Agent

ggf. Dateigröße wäre für die Datenschutzerklärung noch erwähnenswert.

Die anderen Abschnitte "Typ" (z.B. Access), "Code" (z.B. 200), "Nachricht (z.B. GET / HTTP/1.0)", "Referrer" (z.B. https://...) und "Quelle" (z.B. SSL/TLS-Zugriff für Apache) scheinen wohl für eine Datenschutzerklärung dann nicht von Bedeutung zu sein. Aber die oberen genannten schon. Meine Frage dazu, ob dies dann alles ist, was so "automatisch" gespeichert wird von Netcup oder habe ich evtl. etwas übersehen? Ich benötige die Infos halt erst mal nur, damit die Datenschutzerklärung vollständig geschrieben werden kann.

Schön wäre gewesen, wenn es von Netcup irgendwo eine Art Informations-Datei/Seite gäbe, wo solches erwähnt wird. Habe ich aber nicht gefunden. Auch noch keine FAQ Seite entdeckt. Vieles (fast alles) ist für mich hier halt noch recht neu.

Zitat von ArtCore7

Ist eben immer eine Abwägung wie sehr die Daten die dort angezeigt werden geschützt werden müssen. Aber sehe wenn es im Backend passiert erstmal kein Problem. Besser geht immer 😉

Alles klar. Merci. Das nutze ich dann erst mal für "normale" Dinge und womit Hacker nicht viel mit anfangen können.

Zitat von aRaphael

Da hat wohl jemand mal "Das Netz" gesehen.

Ja, u.a. auch "Das Netz"

Ja, im "Backend" wenn ich das richtig verstehe. Also wie gesagt, das Cookie gibt es nur bei mir auf der Festplatte und wird auch nur dort erstellt. Im PHP Code findet nur ein Lesezugriff statt. Dachte nur, durch gewisse Browser Plugins kann man dann etwas rausfinden. Aber auch wenn man das Cookie (also den Namen) rausfindet, braucht man ja dann auch noch den richtigen Wert dazu. Das geht dann ja nur, wenn ich sozusagen ein Virus auf Festplatte habe (dann wäre das das kleinste Problem mit dem Cookie *lach) oder ggf. eine neue Sicherheitslücke im Browser entdeckt wird und der Hacker einen neuen Spaß-Bereich gefunden hat. So erspare ich mir eigentlich eine richtige Login-Seite und muss mich nicht um eine Passworteingabe bemühen. Auf meiner Webseite gibt es dann (wenn Cookie da und richtiger Wert) ein kleines Pi-Symbol in der Ecke und je nach Status einer gewissen Log-Datei sehe ich anhand der Farbe, ob ich reagieren muss (Div-Box generieren, anzeigen und Dinge erledigen).

Hallo,

ich möchte mir ein Status-Fenster machen, um schnell mal in ein paar LOGS nachzuschauen. Also ein Status-Fenster mit einer DIV-Box. Evtl. dort auch ein paar Funktionen einbauen. Im Grunde genommen wie eine Login-Seite für Admins. Jedoch dachte ich an ein Cookie, diesen ich nur auslese und wenn vorhanden und der Inhalt stimmt, wird die DIV-Box erstellt, die Daten dort eingefügt und angezeigt. Das Cookie erstelle ich dann manuell mit dem Browser in der Entwicklungsumgebung. Frage mich hier bezüglich der Sicherheit meiner DIV-Box bzw. dem Cookie. Die DIV-Box soll ja nur für mich sein. Ich lese diesen Cookie auf der Webseite ja nur aus und somit kann wohl niemand herausfinden, dass ich ein Cookie auslesen möchte. Müsste doch so gehen oder gibt es hier Sicherheitsbedenken, ggf. durch erweiterte Browser-Tools?

Zitat von MicNC

Merci . Mit 587 geht es. Jetzt kann ich endlich weiter machen
Aber eine Sache verstehe ich noch nicht. Ich habe ja diesen try "catch (Exception $e){}" Bereich. Kommen da überhaupt Fehler an? Der besagte Timeout Fehler kam ja dort nicht an. Aber das war ja ein Timeout Fehler und wenn ich da so drüber nachdenke... das lokale PHP reagierte wohl darauf und unterbrach die Warteschleife. Ich hoffe, die normalen Fehler, die ein EMail-Server ausspuckt, kommen im "catch" Bereich dann an. Ach, kann ich ja gleich ausprobieren (z.B. falsches Passwort" hinterlegen) Schönes Wochenende@all

Ach, das geht ja anders. try/catch sind glaube ich nur PHP Fehler und ich muss eher "if(!$mail->Send()) {..." machen