PHPSESSID an SubscribeConfirmationLink angehängt>Problem bei

Fragen und Tipps & Tricks zur PHP Mailinglisten-Verwaltung SuperMailingList

Moderator: mirko

Antworten
Benutzeravatar
mirko
Beiträge: 22869
Registriert: 25.11.2001, 15:14
Wohnort: Leipzig
Kontaktdaten:

Beitrag von mirko »

Ja das kann auch mal am Zielserver liegen oder am eigenen Server, das kommt natürlich auch mal vor.
SML-User
Beiträge: 21
Registriert: 03.04.2009, 12:17

Beitrag von SML-User »

Hmm, seltsame Welt des Internets, heute geht es mit GMX wieder. Da steck mal einer dahinter. Ich zerbrech mir den Kopf und setz Scripte neu auf, dabei liegts scheinbar an GMX...
Benutzeravatar
mirko
Beiträge: 22869
Registriert: 25.11.2001, 15:14
Wohnort: Leipzig
Kontaktdaten:

Beitrag von mirko »

SMTP Direct (MX) nicht verwenden, das ist nur für Profis, die genau wissen, wie und ob der eigene Server korrekt konfiguriert ist, so dass vom Zielserver die E-Mail auch akzeptiert wird.

PHP mail() funktioniert normalerweise einfach so. Da die Mail an die VR-Web Adresse geht, muss diese auch an GMX versendet werden. Kommt diese bei GMX nicht an, dann könnte es sein, dass der Server von GMX geblacklistet wurde, weil z.B. irgendwer Spam über den Server versendet hat.
SML-User
Beiträge: 21
Registriert: 03.04.2009, 12:17

Beitrag von SML-User »

Wünsch erst mal frohe Ostern!!!

Ich hab mittlerweilen aus Langeweile sämtliche Tabellen in der Datenbank entfernt, den SML-Ordner gelöscht und SML neu aufgesetzt, eine ältere Version (..164).

Aber nach wie vor habe ich dieses Problem, dass an GMX-Postfächer keine Mails mit Bestätigungslink mehr verschickt werden. Vorher hat das mal funktioniert. Er bringt zwar nach Anmeldung zum Letter die Meldung \"An ihre Adresse wurde Mail mit Bestätigunslink verschickt...\", aber da kommt nie was an, auch nicht im Spam. Hab ich schon mit 3 GMX-Fächern durchprobiert. Mit meiner VR-Web-Mailadresse funktioniert es aber, da krieg ich ne Mail mit Bestätigungslink. Liegt wohl auch nicht an der HTML-Mail, da ich auch mit Textmail probiert habe.

Habe auch schon versucht, die Methode \"Standard PHP mail ()\" auf \"SMTPDirect (MX)\" zu ändern, aber diese Methode klappt überhaupt nicht.

Notfalls mache ich das Opt-In Out, aber auf Dauer kann es das auch nicht sein. Woran könnte das ganze liegen.

Im SML-Admin habe ich als Posteingangsserver den POP3-Stratoserver des Postfachs newsletter@meine-url.de definiert, diese Mailadresse habe ich auch bei E-Mail-Versand angegeben. Postausgangsserver muss man ja nirgends angeben für \"Standard PHP mail ()\", oder?
Benutzeravatar
mirko
Beiträge: 22869
Registriert: 25.11.2001, 15:14
Wohnort: Leipzig
Kontaktdaten:

Beitrag von mirko »

Nachtrag: Zudem funktionierte gestern dass das Editierfeld für die Mail im HTML-Format nicht mehr. War aber nur vorübergehend, geht jetzt wieder. Fehlermeldung des Browsers:
Per FTP das ganze Verzeichnis fckeditor löschen und aus der VOLLVERSION das fckeditor-Verzeichnis nochmals neu übertragen. Es muss die Vollversion sein, weil beim Update ein paar Grafiken fehlen.

Ach ja und den Internet Explorer schließen und neu aufmachen, wenn das Update eingespielt ist, sonst stimmten womöglich die Anmeldedaten nicht mehr.
Zuletzt geändert von mirko am 10.04.2009, 12:35, insgesamt 1-mal geändert.
Benutzeravatar
mirko
Beiträge: 22869
Registriert: 25.11.2001, 15:14
Wohnort: Leipzig
Kontaktdaten:

Beitrag von mirko »

Original von SML-User:
Nachtrag: Beim Einspielen konnte die config.inc.php nicht ersetzt werden, da diese 444 war, also geschützt. Daraufhin hab ich sie zeitweise auf 777 gesetzt, den gescheiterte FTP-Transfer wiederholt und die Datei danach wieder auf 444 gesetzt. Hoffe das passt so?!?
Ich glaube im Kundenbereich steht das doch oder habe ich das vergessen? Muss ich mal hinschauen.

Man muss die Rechte der Datei config.inc.php auf 777 ändern. Die Rechte der Dateien config_paths.inc.php und config_db.inc.php auf keinen Fall ändern.

Jetzt alle Dateien des Updates per FTP übertragen, dabei alle bestehenden Dateien ersetzen lassen ABER auch nichts löschen lassen. Das Löschen machen einige FTP-Programme, es darf auf keinen Fall gelöscht werden.

Ist \"Kind in den Brunnen\" gefallen, d.h. das FTP-Programm hat gelöscht, dann die Vollversion laden und die Dateien alle übertragen lassen. Die Dateien config_paths.inc.php und config_db.inc.php sind dabei nicht überschreibbar und das soll genau so sein. Nach Ãœbertragung der Vollversion die install.php aus Sicherheitsgründen löschen.

Ist alles übertragen die Rechte der Datei config.inc.php wieder auf 444 setzen, dann ist alles super.
SML-User
Beiträge: 21
Registriert: 03.04.2009, 12:17

Beitrag von SML-User »

Jetzt hab ich schon wieder ein Problem, sorry (evtl. in Zusammenhang mit den letzten 2 Postings?). Nach dem Aufspielen des Updates werden an GMX-Postfächer keine Mails mit Bestätitungslink mehr verschickt. Habe auch schon versucht, die Methode \"Standard PHP mail ()\" auf \"SMTPDirect (MX)\" zu ändern, aber da kommt dann direkt beim Eintrag \"Failedtosendmailto:\".

Falls keine (schnelle) Lösung in Sicht:

Die gesicherten Files von der Festplatte von vor dem Update rüberzuspielen, um die Version vor dem Update wieder zu haben, ist bestimmt auch nicht gangbar, eben wegen der vergebenen Benutzerrechte, falls die dann beim Rücktransfer von Platte auf Webspace verloren gehen?!?

Evtl. komplett neu aufsetzen? Wenn ja wie?!? Also sml_voll-Ordner löschen ist klar, aber bzgl. Datenbank... Welche Tabellen löschen, gibts irgendwo ne Ãœbersicht welche Tabellen zu SML gehören? Oder Tabellen belassen und exakt gleiche Angaben bei der Neu-Installation machen - werden sie dann überschrieben? Oder einfach neu installieren und dann Backup der DB einspielen..

Hilfe :-( Warum funkioniert immer alles tadellos und dann wenn man so eine Verlosung startet, ist auf einmal der Wurm drin?!?

--
Nachtrag: Zudem funktionierte gestern dass das Editierfeld für die Mail im HTML-Format nicht mehr. War aber nur vorübergehend, geht jetzt wieder. Fehlermeldung des Browsers:

Details zum Fehler auf der Webseite

Benutzer-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; InfoPath.2; MSN OptimizedIE8;DEDE)
Zeitstempel: Thu, 9 Apr 2009 22:05:17 UTC


Meldung: Syntaxfehler
Zeile: 1
Zeichen: 1
Code: 0
URI: /sml_voll/fckeditor/fckconfig.php


Meldung: Syntaxfehler
Zeile: 1
Zeichen: 1
Code: 0
URI: /sml_voll/fckeditor/fckconfig.php


Meldung: Syntaxfehler
Zeile: 1
Zeichen: 1
Code: 0
URI: /sml_voll/fckeditor/fckconfig.php


Meldung: \'PluginsPath\' ist Null oder kein Objekt
Zeile: 34
Zeichen: 1685
Code: 0
URI: /sml_voll/fckeditor/editor/js/fckeditorcode_ie.js


Meldung: \'PluginsPath\' ist Null oder kein Objekt
Zeile: 34
Zeichen: 1685
Code: 0
URI: /sml_voll/fckeditor/editor/js/fckeditorcode_ie.js


Meldung: \'PluginsPath\' ist Null oder kein Objekt
Zeile: 34
Zeichen: 1685
Code: 0
URI: /sml_voll/fckeditor/editor/js/fckeditorcode_ie.js


Meldung: \'FCKConfig.ContextMenu.length\' ist Null oder kein Objekt
Zeile: 106
Zeichen: 441
Code: 0
URI: /sml_voll/fckeditor/editor/js/fckeditorcode_ie.js


Meldung: \'FCKConfig.ContextMenu.length\' ist Null oder kein Objekt
Zeile: 106
Zeichen: 441
Code: 0
URI: /sml_voll/fckeditor/editor/js/fckeditorcode_ie.js


Meldung: \'FCKConfig.ContextMenu.length\' ist Null oder kein Objekt
Zeile: 106
Zeichen: 441
Code: 0
URI: /sml_voll/fckeditor/editor/js/fckeditorcode_ie.js


Meldung: \'undefined\' ist Null oder kein Objekt
Zeile: 100
Zeichen: 340
Code: 0
URI: /sml_voll/fckeditor/editor/js/fckeditorcode_ie.js


Ein Rückspielen des Backups hat leider auch nix gebracht.
Zuletzt geändert von SML-User am 10.04.2009, 10:54, insgesamt 4-mal geändert.
SML-User
Beiträge: 21
Registriert: 03.04.2009, 12:17

Beitrag von SML-User »

Nachtrag: Beim Einspielen konnte die config.inc.php nicht ersetzt werden, da diese 444 war, also geschützt. Daraufhin hab ich sie zeitweise auf 777 gesetzt, den gescheiterte FTP-Transfer wiederholt und die Datei danach wieder auf 444 gesetzt. Hoffe das passt so?!?
SML-User
Beiträge: 21
Registriert: 03.04.2009, 12:17

Beitrag von SML-User »

Wie ist das nach einem Einspielen des Updates mit den Lese-/Schreibrechten auf dem Webspace. Habe eben geguckt (vor dem Update), Ordner userfiles ist 777, config_db.inc.php und config_paths.inc.php sind 444. Allerdings hatte ja schon mal ein Update gemacht, ohne mich darum zu scheren, also einfach aufgespielt. In der Erstinstallationsanleitung für das Vollpaket steht ja, dass auch config_db.inc.php und config_paths.inc.php auf 777 gesetzt werden müssen. Zur Sicherheit also die Nachfrage: Wird das mit/nach der Installation dann vom Script wieder abgeändert auf 444 und hat das so seine Richtigkeit? Hintergrund der Nachfrage: Könnte ja sein, dass durch einen Upload die vergebenen Verzeichnisrechte tangiert werden.

P.S.: So guten Support erlebt man selten. Da fällt einem ein Problem auf und promt ist ein Software-Update draussen. Dreimal Daumen hoch!!!
SML-User
Beiträge: 21
Registriert: 03.04.2009, 12:17

Beitrag von SML-User »

Echt klasse!
Benutzeravatar
mirko
Beiträge: 22869
Registriert: 25.11.2001, 15:14
Wohnort: Leipzig
Kontaktdaten:

Beitrag von mirko »

Ich habe gerade noch ein Update eingespielt, man kann damit SML auch mit session.use_trans_sid=1 verwenden, es wird einfach beim Speichern der Wert PHPSESSID entfernt.
Benutzeravatar
mirko
Beiträge: 22869
Registriert: 25.11.2001, 15:14
Wohnort: Leipzig
Kontaktdaten:

Beitrag von mirko »

Mhh das habe ich bisher auch noch nicht gemacht, legt die Datei einfach ins SML-Verzeichnis selbst. Testen kann man dann ob es geht, in dem man den Text der Bestätigungs-E-Mail ändert, speichert und dann nochmals ändert. Die Session-ID darf dann nicht bei den Links im Editor auftauchen.
SML-User
Beiträge: 21
Registriert: 03.04.2009, 12:17

Beitrag von SML-User »

Gut zu wissen woran das liegt. Dann kann ich ggf. für die Zukunft vorbauen, damit das nicht noch einmal vorkommt.

Habe mich gleich eimal kundig gemacht: Mein Provider bietet mir die Möglichkeit, eine eigene \"php.ini\" anzulegen, das überschreibt dann scheinbar die PHP-Einstellungen in dem Ordner, in dem sich diese selbst angelegte Datei befindet - allerdings ist es nicht vererbbar, also müsste auch in Unterordner so eine Datei.

FRAGE: In welche (Unter-)Verzeichnisse des SML-Scripts müsste so eine Datei dann sinnvollerweise reinkopiert werden? Inhalt wäre schlicht \"session.use_trans_sid=0\".

P.S.: DANKE, klasse Support bislang!!!
Benutzeravatar
mirko
Beiträge: 22869
Registriert: 25.11.2001, 15:14
Wohnort: Leipzig
Kontaktdaten:

Beitrag von mirko »

Das liegt am PHP, in der php.ini ist session.use_trans_sid=1 eingestellt, obwohl man dies aus Sicherheitsgründen nicht mehr aktivieren sollte. Ist session.use_trans_sid=1, dann schreibt das PHP an jeden Link auf einer Seite das PHPSESSID= hinten dran.
SML-User
Beiträge: 21
Registriert: 03.04.2009, 12:17

Beitrag von SML-User »

Sorry wenn ich bereits den dritten Thread hier aufmache, aber das Folgende hat durchaus akute Relevanz (wir machen ja gerade eine Newsletterverlosung und da ist es blöd, wenn die Anmeldung nicht geht):

Vor einigen Stunden funktionierte nach Klicken des Bestätigungslinks in der HTML-Mail die Aufnahme von neuen Newsletter-Empfängern nicht mehr. Ich habe nichts am Script geändert, vorher hat alles funktioniert. In SML eingeloggt habe ich mir die Maske reingezogen, wo man den Mailtext editieren kann. Beim Betrachten des HTML-Quellcodes viel mir auf, dass hinter [SubscribeConfirmationLink] ein \"?PHPSESSID=...\" angehängt war (wie auch an den Unsubscribe-Link), siehe hier:

<a>[SubscribeConfirmationLink]</a>

Diesen Code habe ich definitiv nicht angehängt. Nach Entfernen des Codes ging dann (bis jetzt eben) alles wieder einwandfrei.

Frage: Ist dieser angehängte Code auf das Update der SML zurückzuführen und an sich nötig (ich habe ihn ja nun entfernt, damit die Aufnahme von neuen Empfängern wieder geht), oder irgendwie durch einen Scriptinterpretationsfehler verursacht oder ist das eine böswillige Manipulation??
Antworten