Fehlermeldung von PayPal: Callback URL is wrong type; you must use the HTTPS

Hallo zusammen,

ich habe das PayPal-Modul aktiviert und ausgefüllt, der Button wird angezeigt, allerdings erhalte ich beim Klick darauf o.a. Fehlermeldung.
Dieses Problem scheinen viele zu haben und ich habe herausgelesen dass für den Express-Button eine SSL Verbindung (von Pp vorgeschrieben) zwingend ist, die Basis-PP-Grafik wird angezeigt und lässt sich problemlos aufrufen.
Ist dem so oder gibt es eine andere Möglichkeit den Express-Button zu nutzen ohne bei meinem Provider eine SSL-Option zuzubuchen?

Danke für Eure Antworten :slight_smile:

P.S. ich habe die neueste Version des Shops und PayPal-Modul 3.2.1

Hallo,

im zum Installationspaket gehörenden Benutzerhandbuch steht unter Systemvoraussetzungen: “Darüber hinaus funktioniert das Modul PayPal nur, wenn der OXID eShop für den SSL-Modus konfiguriert wurde.”.

Gruß,
Jürgen

Da hast du Recht: Das Problem, dass Benutzerhandbücher nicht gelesen werden, ist tatsächlich sehr weit verbreitet.

Hallo Ihr beiden und danke für Eure schnellen Antworten.

Der Shop ist eine one-Klick-install Lösung meines Providers und ein Handbuch war nicht ersichtlich, finde aber Antworten auf diese oder jene Frage immer auch über die Recherche im Internet und/oder ausprobieren, ist ja super dokumentiert alles :slight_smile:

Nur bei dem Modul war es jetzt eben unklar wie es zu dieser Fehlermeldung kam.

Verstehe ich es also richtig dass ich in jedem Fall einen SSL-Option bei meinem Provider zubuchen muss? d.h. die Domain liefe dann grundsätzlich unter https? Ich kenne mich mit SSL leider überhaupt nicht aus.

“(…)wenn der OXID eShop für den SSL-Modus konfiguriert wurde.”

Wenn ich die SSL-Option also zubuche (Provider schaltet das um und ich muss da glücklicherweise nix mehr zutun), muss ich dann im Shop selbst noch irgendwas gesondert konfigurieren?

Wo finde ich das Handbuch eigentlich?

Du musst in der config.inc die ssl-URL eintragen und ab dann läuft der Checkout über ssl. Artikelseiten, Kategorie-Seiten etc. laufen wie gehabt über http

[QUOTE=Maxxxximlian;160851]
Wo finde ich das Handbuch eigentlich?[/QUOTE]

scrolle ganz an den oberen Rand dieser Seite. Unterhalb des OXID-Logos ist eine horizontale Navigation. Bewege deinen Mauszeiger über den Punkt Support & Services. Das Sub-Menü öffnet sich dann automatisch. Dort findest Du einen Link DOCUMENTATION AND HELP

Hallo,

wenn Du Zugriff auf die Shopdateien hast, findest Du das Benutzerhandbuch für PayPal im Ordner /documentation/OEPAYPALSTANDALONE. Willst Du Dich zum OXID eShop generell schlau machen, nutze dieses wunderbare Forum oder lies nach unter doku.oxid-esales.com.

Gruß,
Jürgen

Danke Euch, die Dokumentationen und hilfreichen Links habe ich jetzt gefunden.

@Jürgen, ja ich habe Vollzugriff auf alles, so kann und konnte ich auch problemlos konfigurieren etc…

Im Benutzerhandbuch habe ich auf Seite 6, Punkt 2 Systemvoraussetzungen gefunden, bin da aber jetzt nicht so mit dem SSL-Prozedere vertraut und habe auch gleich eine/mehrere Frage/n hierzu:

"Für die Verwendung des Moduls PayPal sind unten stehende Systemvoraussetzungen notwendig. Darüber
hinaus
funktioniert das Modul PayPal nur, wenn der OXID eShop für den SSL
-Php 5 und höher

  • cURL
    -openSSL …etc."

Ich bin jetzt unsicher wie ich mit dem SSL vorgehen soll, mein Provider bietet wie gesagt eine kostenpflichtige Option SSL an, weiss aber nicht ob das OpenSSL ist oder kompatibel und benötige vorab Informationen/Hinweise hierzu, und wie Meister Yoda schon sagte: “(…)config.inc die ssl-URL eintragen”.

Meine Frage nun wo ich diese SSL-URL herbekomme bzw. ob es da eine empfehlenswerte und natürlich vertrauenswürdige, erprobte kostenlose Möglichkeit gibt eine solche URL zu erhalten?

Was bitte ist cURL und wie komme ich dazu, baue das ein?

Wo genau wäre diese SSL-URL in die config.inc.php einzutragen ist, ein Blick in die Datei gibt mir keinen Aufschluss, über PayPal steht da zumindest nichts bzw. habe da jetzt ausser allgemeine Erklärungen nichts gefunden.

Vielen Dank, Maxxx

Hallo Maxxx,

cURL und openSSL sind Systemkomponenten, die normalerweise vorhanden sein sollten. Du kannst das in Deinem OXID eShop überprüfen, indem Du im Administrationsbereich unter [B]Service[/B] -> [B]Systeminfo[/B] nach den Einträgen suchst. Sind sie vorhanden, ist alles vorbereitet.

Der Provider schaltet meines Wissens die SSL-Option nur zu, so dass Dein Shop auch über diese Adresse erreichbar ist: https://meinoxidshop.de. Dazu müssten unsere Profis mal kurz etwas sagen bzw. ergänzen.

In der config.inc.php musst Du also folgendes eintragen:

$this->sSSLShopURL = https://meinoxidshop.de; // eShop SSL url, optional
$this->sAdminSSLURL = https://meinoxidshop.de/admin; // eShop Admin SSL url, optional

Fertig! Gruß,
Jürgen

[QUOTE=juergen.busch;160882]
Der Provider schaltet meines Wissens die SSL-Option nur zu[/QUOTE]

Jupp, es wird in der Serverconfig lediglich ergänzt, dass nun auch auf Port 443 gehorcht werden soll (Standard ist ja Port 80 für “reines” http). In der Regel wird auch kein domaineigenes Zertifikat installiert - Großanbieter arbeiten hier mit Wildcard-Zertifikaten.

Also: Option beim Provider zubuchen, Config vom Shop entsprechend anpassen und damit sollte es in aller Regel schon gewesen sein.

Hallo zusammen,

ich habe jetzt bei meinem Provider das SSL-Paket zugebucht, der shop ist jetzt zwar auch unter https zu erreichen, allerdings blockiert firefox “einige unsichere Inhalte der Webseite” die ich erst manuell freigeben muss, dann wird der shop aber normal angezeigt.
Das ist jetzt nicht wirklich schlimm, aber kann man das irgendwie beheben?

Dann erhalte ich plötzlich im AdminPanel eine Sicherheitsmeldung:

Die Systemgesundheit dieses Shops ist gefährdet. Möglicherweise verhält sich Ihr OXID eShop in einigen Bereichen unerwartet. Bitte stellen Sie sicher, dass die Servereinstellungen korrekt vorgenommen werden. Unterstützung finden Sie in der Systemgesundheitsprüfung.

Ein rascher Blick in die Systemgesundheit offenbart einen rot gekennzeichneten Eintrag unter

Server-Konfiguration: Apache mod_rewrite Modul

Dazu erhalte ich beim upload der config.inc.php via filezilla die Fehlermeldung:

553 Can’t open that file: Permission denied
Fehler: Kritischer Dateiübertragungsfehler

Wie es aussieht fehlen mir jetzt die Schreibrechte, kann ich da selbst was regeln oder muss der Provider ran?

Kann man, ja, aber ohne einen Link zum Shop kann man schwer sagen, was genau und wo berichtigt werden muss.

Die Meldung von Firefox ist eine Folge davon, dass du nun innerhalb einer SSL-verschlüsselten Verbindung Elemente der Webseite (Bilder, Scripte, usw.) über einen unverschlüsselten HTTP-Stream holen willst.

Das passiert dann, wenn man Bilder usw. statisch einbindet (also mit Angabe der kompletten URL INCL. des führenden “http://”). Dazu müsste man aber in der Tat mal einen Link zum Shop bekommen - dann kann man mal gucken, wo das Problem speziell liegt.

Hallo zusammen,

das mit dem link geht leider nicht, da die Freundin mit der ich den Shop aufsetze strikt auf ihr Marketingkonzept beharrt, dazu gehört bis zum Tag X absolutes stillschweigen über Idee, Domainnamen, URL oder sonstigen Informationen, nicht mal ihre beste Freundin weiss davon.
Dass muss ich respektieren und bitte um Nachsicht, werde aber gern den link einstellen sobald wir online gehen :slight_smile:

Ich hoffe Ihr könnt mir auch ohne link weiterhelfen, es scheint ja ein Problem zu sein das öfter mal vorkommt wenn man mal so googelt.

Ich habe den support angeschrieben, dieser hat mir erst die Schreibrechte für die .htaccess wiederhergestellt, das mod_rewrite Modul war aber auf on und ich fand nichts zum ändern, es sei denn es gibt eine spezielle Zeile die ich editieren müsste?

Dann hat er mir die Schreibrechte für die config.inc.php hergestellt, und ab da wirds seltsam.

Ich konnte die https wie empfohlen eintragen und PayPal xpress funktionierte auf anhieb, d.h. ich konnte einen Testartikel auswählen und den PP-Button klicken, wurde dann mit Warenkorb auf die PP-Seite weitergeleitet, hätte mich dann anmelden können etc…

Bei einem zweiten Versuch funktionierte dies jedoch nicht und ich wurde nach Klick auf den Button auf die Hauptseite des Shops, aber mit https-Verbindung weitergeleitet staun. Auch wurde das ganze elendig langsam, was ja ein Stück weit nachvollziehbar ist, aber auf anderen SSL-Seiten die ich so kenne nicht in dem Masse auffällig war. Habe die config jetzt erstmal in den Urzustand versetzt und der shop läuft geschmeidig wie eh und je.

Nachdem der support mir dann die Schreibrechte für die config gegeben hatte, erhielt ich im Backend einen weiteren Hinweis:
[B]“WICHTIG: Aus Sicherheitsgründen setzen Sie Ihre config.inc.php Datei auf read-only-Modus!”, damit haben wir bereits die zweite Fehlermeldung.[/B]

Auch antwortete der support dass es nicht an der SSL-Aktivierung liegen könnte, allerdings traten alle Fehler ja erst nachdem auf. Ich mein wenn es um Schreibrechte geht die kann ich ja via filezilla wiederherstellen, aber es wird ja auch in der ersten Fehlermeldung gesagt dass der shop sich unerwartet verhalten könnte, was er dann auch tat.

Sind das bekannte Probleme bei der Einbindung von PP in den Oxid-eshop die sich beheben lassen oder liegt es ggf. am Provider selbst? (falsche Installationsroutine o.ä.?)

@Wolkenkrieger, kann es sein dass der shop so langsam wurde weil nach dem Problem wie o.a. über https die hochgeladenen Bilder alle mit http geladen wurden? Wenn dem so ist wie kann ich das denn vermeiden, der shop soll ja eigentlich auch nur für das PayPal-xpress mit SSL laufen, ansonsten nicht.

Um deine an mich gerichtete Frage zu beantworten: nein, daran kann es nicht gelegen haben. Ob der Server http oder https ausliefert, sollte man im Normalfall nicht an der Geschwindigkeit merken.

Und: der Shop läuft nicht für PPX im SSL, sondern immer (also auch, wenn du PP komplett deaktivierst) … bzw. einige Seiten (Checkout usw. - also im Grunde die Seiten deines Shops, die vertrauliche Daten zwischen Server und Client hin und her reichen).

Und genau DA liegt der Hase im Pfeffer: gehen wir mal als Beispiel davon aus, dass du ein JavaScript von Google nachlädst (jQuery zum Beispiel). Der Aufruf im Header erfolgt standardmäßig über die http-Adresse von Google. Sobald aber dein Shop auf die SSL-Seiten (Checkout, Konto, etc.) wechselt, erwartet das Sicherheitskonzept der Browser (btw. nicht nur der FF hat damit ein Problem), dass das Script auch über eine verschlüsselte Leitung kommt - alles andere stellt ein Sicherheitsrisiko dar.

Es könnte (wir können ja leider nur glaskugeln) also sein, dass du im Header (oder auch im Footer - kommt auf das Template an) eine harte (statische) Einbindung von Scripten oder auch Stylesheets hast oder zum Beispiel Bilder statisch verlinkt sind … usw.

Am einfachsten wäre es, mit der Entwicklerkonsole des Chrome mal zu gucken, was da wann und woher geladen wird bzw. werden soll. Ich fürchte allerdings - und nimm mir das bitte nicht übel - dass dich das überfordern würde … täte es das nicht, müsstest du die Fragen hier nicht stellen.

[QUOTE=Maxxxximlian;160909] aber es wird ja auch in der ersten Fehlermeldung gesagt dass der shop sich unerwartet verhalten könnte[/QUOTE]

Der Shop sagt das immer, wenn eine oder mehrere Bedingungen für den Betrieb nicht/teilweise erfüllt sind.

Gelbe Ampel: Shop [B]kann[/B] sich unerwartet verhalten
Rote Ampel: Shop [B]wird[/B] sich unerwartet verhalten

Schau einfach in der Systemgesundheit was nicht, oder nur teilweise passt.

Alternativ, wenn für für Euer Geschäftskonzept pp Express nicht zwingend erforderlich ist, nimm das d3 modul http://www.oxidmodule.com/OXID-Professional-Community/Module-PE/Heidelpay-Integrator-fuer-Oxid-PE-Basic-ab-4-7.html und mach einen Vertrag mit Heidelpay. Das Modul ist auch von einem Laien einfach zu installieren, oder Du kannst Installationsservice für kleines Geld dazu buchen. Und Du brauchst dafür kein SSL. Dann hast Du alle Probleme beseitigt

@wolkenkrieger, Ne da hast du schon recht, das wäre jetzt eine Nummer zuviel, kenne mich ohnehin mit Chrome nicht aus da ich nur Firefox nutze, könnte mich zwar grundsätzlich einarbeiten, aber das stünde jetzt m.E. nicht wirklich im Verhältnis. Mein Template ist azure. Sehr viel wichtiger ist ja jetzt diese Zahlungssache und ich will vermeiden dass mir da jetzt graue Haare wachsen. Ich danke dir aber für deine gute Erklärung :slight_smile:

@MeisterYoda, in der Systemgesundheit ist alles im grünen Bereich, ausser eben tiefrot bei "Apache mod_rewrite Modul"
und “Dateizugriffsrechte”, letzteres kam hinzu als der support die Dateirechte für die config freigegeben hat, das unerwartete Verhalten fand ja offenbar auch direkt statt, mal abwarten was die mir antworten, ich werde berichten.

PP-xpress ist halt Standard bei vielen und deshalb wollten wir das ebenfalls nutzen, zwingend jetzt nicht wenn es eine gute Alternative gibt, dein Modulvorschlag klingt aber grad ideal, insbesondere weil da ja auch weitere Zahlmöglichkeiten integriert sind und man sich diese ganze SSL-Nummer sparen kann. Leider finde ich keine Erläuterung was da letztendlich für Kosten auf uns zukommen bzw. was Heidelpay sich pro Transaktion einverleibt bzw. ob es da feste Summen o.ä. gibt, hast du Erfahrungen mit denen und kannst mir weitere Informationen geben?

Dann bring das mit dem Apache mod_rewrite in Ordnung. Wenn Du auf die Serverconfig keinen Zugriff hast wende Dich an deinen Provider.

Dateizugriffsrechte kannst Du ignorieren. Deine config ist nicht Schreibgeschützt. Das hat aber keinen Einfluss auf die Funktion.

Wegen der Kosten wende Dich direkt an heidelpay und lass Dir ein Angebot machen. Ich empfinde sie aber für den gebotenen Service für absolut OK.

Guten Morgen,

ich habe jetzt mal das PP-Modul deaktiviert, tmp gelöscht, config wie folgt neu beschrieben

 $this->sShopURL = 'http://www.domain.de'; // eShop base url, required
     $this->sSSLShopURL = 'https://www.domain.de'; // eShop SSL url, optional

PP-Modul wieder aktiviert (Deaktivierung gibt übrigens die Startseite ohne Formatierung aus staun), dreifach getestet und alles läuft geschmeidig.

Das PP-Modul war aktiviert als SSL aufgespielt und die config angepasst wurde, kann das irgendwie zusammenhängen? Oder lag das Problem am nicht gelöschten tmp nach Konfiguration? Oder tatsächlich am Provider und der hat da seit gestern noch was geschraubt? DIe Fehlermeldungen sind übrigens noch da.

Was meint Ihr?

Jedenfalls läuft wieder alles wie es soll, trotz angezeigter Fehlermeldung im Backen.
Nochmals danke für Eure Unterstützung :slight_smile: