Hallo und guten Abend,
die Frage ist fast ein wenig ketzerisch: Gibt es eine Lösung, Comments_XH ohne Cookies zu betreiben? Ich habe den einen oder anderen Nutzer in mächtig gesicherten Netzen sitzen. Und von denen kann leider kein Beitrag eingestellt werden.
Gruß Frank
Comments XH v3.0 - Beiträge ohne Cookies
Re: Comments XH v3.0 - Beiträge ohne Cookies
Hallo Frank,
ich vermute, dass Comments_XH die Cookies nur für das CAPTCHA braucht. Hast Du's mal ohne CAPTCHA probiert?
Christoph
ich vermute, dass Comments_XH die Cookies nur für das CAPTCHA braucht. Hast Du's mal ohne CAPTCHA probiert?
Christoph
Christoph M. Becker – Plugins for CMSimple_XH
Re: Comments XH v3.0 - Beiträge ohne Cookies
Ja, tatsächlich: wenn "use captcha" leer ist, dann sind keine Cookies nötig. Allerdings könnte der Spam ohne CAPTCHA bald überhand nehmen. Und eigentlich braucht ein CAPTCHA Cookies (am besten wie bei Comments in Form eines PHP-Session-Cookie).
Die einfachste Lösung wäre es die PHP-Ini-Settings von session.cookies, session.only_cookies und session.transid entsprechend anzupassen. Ich halte von der Session-ID in der URL nicht viel, aber wenn in der Session keine empfindlichen Daten gespeichert werden (wie z.B. das Login von Register) dann ist's schon okay. Wenn das aber doch so ist: vergiß den Vorschlag.
Eine theoretische Alternative wäre ein CAPTCHA-Plugin, das keine Cookies braucht. Allerdings gibt es weder ein solches CAPTCHA-Plugin (wäre aber leicht zu programmieren), noch können die CAPTCHA-Plugins bei Comments_XH genutzt werden.
Da müsste also eine Anpassung an Comments_XH erfolgen. Wie ein CAPTCHA auch ohne Cookies auskommen kann, demonstriert das built-in Mailform von CMSimple_XH (eigentlich verrückt, aber es scheint zu funktionieren). Und es gibt wohl auch andere recht wirkungsvolle Anti-Spam-Maßnahmen, die nicht mal ein CAPTCHA erfordern (z.B. http://www.christosoft.de/Tutorials/Antispam und http://playground.ebiene.de/antispam-be ... ss-plugin/). Vielleicht reicht es sogar schon, den Namen des E-Mail-Inputs zu ändern, so dass der Spam-Bot dort keine E-Mail-Adresse einträgt, und dann bei der Gültigkeitsprüfung dieser der Spam gestoppt wird.
Die einfachste Lösung wäre es die PHP-Ini-Settings von session.cookies, session.only_cookies und session.transid entsprechend anzupassen. Ich halte von der Session-ID in der URL nicht viel, aber wenn in der Session keine empfindlichen Daten gespeichert werden (wie z.B. das Login von Register) dann ist's schon okay. Wenn das aber doch so ist: vergiß den Vorschlag.
Eine theoretische Alternative wäre ein CAPTCHA-Plugin, das keine Cookies braucht. Allerdings gibt es weder ein solches CAPTCHA-Plugin (wäre aber leicht zu programmieren), noch können die CAPTCHA-Plugins bei Comments_XH genutzt werden.
Da müsste also eine Anpassung an Comments_XH erfolgen. Wie ein CAPTCHA auch ohne Cookies auskommen kann, demonstriert das built-in Mailform von CMSimple_XH (eigentlich verrückt, aber es scheint zu funktionieren). Und es gibt wohl auch andere recht wirkungsvolle Anti-Spam-Maßnahmen, die nicht mal ein CAPTCHA erfordern (z.B. http://www.christosoft.de/Tutorials/Antispam und http://playground.ebiene.de/antispam-be ... ss-plugin/). Vielleicht reicht es sogar schon, den Namen des E-Mail-Inputs zu ändern, so dass der Spam-Bot dort keine E-Mail-Adresse einträgt, und dann bei der Gültigkeitsprüfung dieser der Spam gestoppt wird.
Christoph M. Becker – Plugins for CMSimple_XH
Re: Comments XH v3.0 - Beiträge ohne Cookies
Hi,
Danke für die Hinweise.
Captcha habe ich bereits ausgeschaltet, ich nutze comments nur im Memberbereich, da bin ich vor Spam hoffentlich schon von vornherein ein wenig sicherer. Nur halt das die Nutzer X und Y trotzdem keine Kommentare loswerden können.
Spannend ist der Verweis auf mailfrom.php, denn das funktioniert bei den beiden Nutzern, so dass ich mir schon mal beinahe sicher bin, dass es tatsächlich an den Cookies liegt und nicht am Javascript - aber dann würden ja andere PlugIns wie HI_fancybox sicherlich auch Sorgen bereiten.
Prinzipiell könnte wohl aber auch der iFrame vom mce die Ursache sein - man lässt mich aber logischerweise nicht in das Netz gucken, wo die Probleme auftreten.
Gruß Frank
Danke für die Hinweise.
Captcha habe ich bereits ausgeschaltet, ich nutze comments nur im Memberbereich, da bin ich vor Spam hoffentlich schon von vornherein ein wenig sicherer. Nur halt das die Nutzer X und Y trotzdem keine Kommentare loswerden können.
Spannend ist der Verweis auf mailfrom.php, denn das funktioniert bei den beiden Nutzern, so dass ich mir schon mal beinahe sicher bin, dass es tatsächlich an den Cookies liegt und nicht am Javascript - aber dann würden ja andere PlugIns wie HI_fancybox sicherlich auch Sorgen bereiten.
Prinzipiell könnte wohl aber auch der iFrame vom mce die Ursache sein - man lässt mich aber logischerweise nicht in das Netz gucken, wo die Probleme auftreten.
Gruß Frank
Re: Comments XH v3.0 - Beiträge ohne Cookies
Hallo Frank,
ich hatte es bei mir mit im Browser deaktivierten Cookies ausprobiert, und da hat's funktioniert. Ich glaube also eher nicht, dass es an den Cookies liegt.
Dann können diese User mal http://www.example.com/?&&COOKIE_AND_JS_TEST aufrufen. Wenn ein leerer Content-Bereich erscheint, sind Cookies und JS okay; ansonsten gibt's einen entsprechenden Hinweis. Das Script funktioniert nur im ausgeloggten Zustand (also nicht im Admin-Mode).
Christoph
ich hatte es bei mir mit im Browser deaktivierten Cookies ausprobiert, und da hat's funktioniert. Ich glaube also eher nicht, dass es an den Cookies liegt.
mailform.php braucht ja nicht nur keine Cookies, sondern auch kein JS, IFrames oder sonst was, was vielleicht Probleme machen könnte. Wenn bei diesen Usern die Fancybox funktioniert, dann kann's eigentlich nicht an JS liegen -- aber: ist das sicher? Denn wenn JS deaktiviert ist, dann kann man die Fancybox-Thumbnails immer noch anklicken, und sieht dann das eigentliche Bild; nur eben nicht in einem Overlay, sondern im normalen Browserfenster.kmsmei wrote:Spannend ist der Verweis auf mailfrom.php, denn das funktioniert bei den beiden Nutzern, so dass ich mir schon mal beinahe sicher bin, dass es tatsächlich an den Cookies liegt und nicht am Javascript - aber dann würden ja andere PlugIns wie HI_fancybox sicherlich auch Sorgen bereiten.
Und vermutlich haben diese User auch nicht die Möglichkeit, an den Einstellungen des Browsers etwas zu ändern. Zum Überprüfen, was nun los ist, kannst Du einfach mal folgendes in cmsimple/userfuncs.php schreiben:kmsmei wrote:man lässt mich aber logischerweise nicht in das Netz gucken, wo die Probleme auftreten.
Code: Select all
function cookieAndJSTest()
{
setcookie('cookie_and_js_test', '1');
return '<script type="text/javascript">/* <![CDATA[ */'
. 'if (document.cookie.indexOf(\'cookie_and_js_test\') == -1)'
. ' document.write(\'\u003cdiv\u003eCookies sind deaktiviert!\u003c/div\u003e\')'
. '/* ]]> */</script>'
. '<noscript><div>Javascript ist deaktiviert!</div></noscript>';
}
if (isset($_GET['COOKIE_AND_JS_TEST'])) {
$o .= cookieAndJSTest();
}
Christoph
Christoph M. Becker – Plugins for CMSimple_XH
Re: Comments XH v3.0 - Beiträge ohne Cookies
Hallo Christoph,
auch zu dem Thema hat sich eine Lösung gefunden - nicht Javascript oder Cookies waren schuld, sondern ein Filter, der alle iFrames und noch so einiges "killt".
Habe nun eine per Schaltfläche schaltbare Alternative mit einfachem <textarea> in comments ergänzt. Die beiden betroffenen User müssen jetzt immer erst den Modus wechseln, wenn sie was schreiben wollen. Nach dem Absenden geht es zurück zur Standard-Lösung.
Gruß Frank
auch zu dem Thema hat sich eine Lösung gefunden - nicht Javascript oder Cookies waren schuld, sondern ein Filter, der alle iFrames und noch so einiges "killt".
Habe nun eine per Schaltfläche schaltbare Alternative mit einfachem <textarea> in comments ergänzt. Die beiden betroffenen User müssen jetzt immer erst den Modus wechseln, wenn sie was schreiben wollen. Nach dem Absenden geht es zurück zur Standard-Lösung.
Gruß Frank
Re: Comments XH v3.0 - Beiträge ohne Cookies
Hallo Frank,
danke für die Info. Es ist immer gut zu wissen, was die Ursache eines Problems war, und ob und wie es gelöst werden konnte. In diesem Fall scheint der Workaround ja akzeptabel.
Und ja, die "bösen" IFrames. Da wird ja viel geschimpft, und aus dem HTML5-Standard wollte man sie zwischenzeitlich sogar entfernen. Zum Glück sieht es so aus, als ob uns die IFrames erhalten bleiben. Immerhin machen sie vieles erst vernünftig möglich, wie zum Beispiel die Verwendung von Gadgets. Natürlich bieten sie auch "Bösewichten" eine gute Gelegenheit, ihre Machenschaften auszuleben. Aber da muss eben an anderer Stelle dafür gesorgt werden, dass sich unerwünschte IFrames nicht einschleichen.
Christoph
danke für die Info. Es ist immer gut zu wissen, was die Ursache eines Problems war, und ob und wie es gelöst werden konnte. In diesem Fall scheint der Workaround ja akzeptabel.
Hoffentlich dann auch Javascripte, die IFrames dynamisch erzeugen -- sonst wäre die Maßnahme vermutlich wenig hilfreich.kmsmei wrote:sondern ein Filter, der alle iFrames und noch so einiges "killt".
Und ja, die "bösen" IFrames. Da wird ja viel geschimpft, und aus dem HTML5-Standard wollte man sie zwischenzeitlich sogar entfernen. Zum Glück sieht es so aus, als ob uns die IFrames erhalten bleiben. Immerhin machen sie vieles erst vernünftig möglich, wie zum Beispiel die Verwendung von Gadgets. Natürlich bieten sie auch "Bösewichten" eine gute Gelegenheit, ihre Machenschaften auszuleben. Aber da muss eben an anderer Stelle dafür gesorgt werden, dass sich unerwünschte IFrames nicht einschleichen.
Christoph
Christoph M. Becker – Plugins for CMSimple_XH