Bei einem Auftragsimport (zwei Kundenbestellungen aus Gambio 3.4.0.0) zu Amicron 12 erhalte eine Fehlermeldung. Siehe html-Datei im Anhang. Die Shopschnittstelle wir in Amicron als funktionsfähig erkannt. Die log-Datei aus dem Shop habe ich auch beigefügt. Liegt der Fehler an der Amicron Scriptdatei oder an an anderen Dingen?
Vielleicht hat jeman das gleiche Problem - das in der RAST-API begründet ist. Lösung: In der Regel liegt es an einer fehlenden Weiterleitung des HTTP BasicAuth Headers innerhalb des WebServers. Abhilfe schafft meistens ein Eintrag in der .htaccess Datei im Hauptverzeichnis des Gambio Shops: RewriteRule ^(.*)api.php - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] Diese Zeile sollte in der .htaccess Datei unmittelbar nach Aktivierung des mod_rewrite, also direkt unter der Zeile "RewriteEngine on" eingefügt werden.
Hallo, ich habe das Problem mit GX 3.6.0.2 Weder Amicron Faktura 11.0, noch 12.0 funktioniert mit GX3.6.0.2 Die Antwort von Amicron: Es gibt in Gambio 3.6 einen Bug bei der REST-API, der dazu führt, dass die Anmeldung an der REST-API fehlschlägt. Damit ist es für Amicron-Faktura 12 unmöglich, die Schnittstelle zu nutzen. Dieser Bug tritt unter bestimmten Server-Umgebungen auf, z.B. wenn PHP unter FastCGI läuft. Ich soll den Hoster wechseln, (gleich mit der Empfehlung auf die Firma www.mittwald.de) oder auf eine neue Amicron Version warten???!!! Toll Mein Hoster ist Estugo und die waren sehr sauer auf diese Antwort von Amicron.
Hallo, ich habe von Amicron auch folgende Antwort bekommen: Es gibt in Gambio 3.6 einen Bug bei der REST-API, der dazu führt, dass die Anmeldung an der REST-API fehlschlägt, siehe https://tracker.gambio-server.net/issues/52767 Damit ist es für Amicron-Faktura 12 unmöglich, die Schnittstelle zu nutzen. Dieser Bug tritt dann auf, wenn PHP unter FastCGI läuft, so wie auf Ihren Servern: When Apache speaks via FastCGI with PHP, the authorization header is available as REDIRECT_HTTP_AUTHORIZATION. There is no way to get rid of the REDIRECT_ in front; you code has to check both variants. siehe https://cweiske.de/tagebuch/php-apache-authorization.htm und https://www.gambio.de/forum/threads/rest-api-schnittstelle-401-unauthorized.24441/#post-211348 Sie können jetzt entweder auf eine neue Gambio-Version warten oder evtl. ein anderes Hosting wählen. Empfehlenswert: - Apache Webserver (kein NGINX-Server!) - PHP wahlweise umstellbar von CGI auf FPM Beispiel: www.Mittwald.de
Guten Morgen, die folgende Antwort auf diesen Fehler habe ich von Gambio bekommen: Guten Tag, wir haben uns die Fehlermeldung noch einmal genauer angeschaut und können Ihnen mitteilen, dass Ihre Amicron Version noch nicht die neue Rest API nutz, sondern eine angepasste XML Schnittstelle. Hier kontaktieren Sie bitte noch einmal den Support von Amicron um diese Schnittstelle prüfen zu lassen und ggf. zu aktualisieren. Amicron antwortet mir, dass sie nichts machen können und man sich an Gambio wenden soll.
Guten Morgen, nun gut, damit ist für mich entschieden das ich beide Systeme in die Tonne klopfe. Auf Ping-Pong-Spiele habe ich keinen Bock. Anscheinend ist diese Kombination unbrauchbar für berufliche Zwecke. Mir ist auch vollkommen egal wer da jetzt "Schuld" hat oder nicht. Beide erzählen, dass es geht, aber so ist es nicht. Ich werde die Hersteller auch mal rechtlich auf Ihre Versprechen untersuchen lassen, schließlich war die Schnittstelle für mich das Kaufargument.
Ich hab mir meine Schnittstelle selbst gebaut. Die funktioniert wenigstens in allen Bereichen richtig ...
@ Christian Mueller Hallo, meine Importdefinition: Code: <?xml version="1.0" encoding="iso-8859-1"?> <!-- Importdefinition für AF12 <=> Gambio GX3 Sep 2016 --> <ORDERS> <DEFINES> <!-- Dokumentation dieser Einstellungen: siehe Kapitel "Datenimport > Auftragsimport > Definitionsdatei: Aufbau und Inhalt"--> <DATESEPARATOR>-</DATESEPARATOR> <TIMESEPARATOR>:</TIMESEPARATOR> <DATEFORMAT>yyyy-mm-dd</DATEFORMAT> <DECIMALSEPARATOR>.</DECIMALSEPARATOR> <!-- Konvertierung der Landeskürzel ist für Amicron-Faktura notwendig für die korrekte Ermittlung der Steuerkürzel bei Auslandsrechnungen. --> <!-- Importierte Landeskürzel für Inland und EU-Länder müssen übereinstimmen mit denen, die in der Faktura in --> <!-- den Programmoptionen unter "System > Einstellungen 2/2" eingetragen wurden --> <INLAND>D,DE,DEU,DEUTSCHLAND,GER,GERMANY</INLAND> <CONVERTLAND>AUT=A,AUS=A,Austria=A,AU=A,GERMANY=DE,GER=DE,Netherlands=NL,France=FR,Slovenia=SL,Switzerland=CH,Spain=E,Greece=GR</CONVERTLAND> <CONVERTVERSANDKOSTEN>0</CONVERTVERSANDKOSTEN> <CONVERTNACHNAHMEKOSTEN>0</CONVERTNACHNAHMEKOSTEN> <CONVERTLIEFERART>"dp_dp=DHL","DP=Deutsche Post","free_free=Versandkostenfrei","flat_flat=Pauschale Versandkosten"</CONVERTLIEFERART> <CONVERTZAHLWEISE>"paypalng=PayPal","invoice=Rechnung","cod=Nachnahme","MONEYORDER=Vorkasse","CC=Kreditkarte","sepa=SEPA-Lastschrift"</CONVERTZAHLWEISE> </DEFINES> <ORDER NewData="AUFTRAG"> <id>#AUFTRAGNR</id> <purchaseDate>#DATUM</purchaseDate> <currencyCode>#WAEHRUNG</currencyCode> <comment>#BEMERKUNG</comment> <paymentType> <!-- <title>#AUFTRAG.ZAHLWEISE</title> --> <module>#AUFTRAG.ZAHLWEISE</module> <sepa_owner>#KUNADRESSE.KONTOINHABER</sepa_owner> <sepa_iban>#KUNADRESSE.IBAN</sepa_iban> <sepa_bic>#KUNADRESSE.BIC</sepa_bic> <sepa_bankname>#KUNADRESSE.BANK</sepa_bankname> </paymentType> <shippingType> <!-- <title>#AUFTRAG.LIEFERART</title> --> <module>#AUFTRAG.LIEFERART</module> <tax>#AUFTRAG.VERSANDKOSTENSTEUER</tax> </shippingType> <customer> <id/> <number>#KUNADRESSE.NR</number> <email>#KUNADRESSE.EMAIL</email> <phone>#KUNADRESSE.TELEFON1</phone> <vatId>#KUNADRESSE.USTIDNR</vatId> </customer> <addresses> <customer NewData="KUNADRESSE"> <gender>#ANREDE</gender> <firstname>#VORNAME</firstname> <lastname>#NAME</lastname> <company>#NAME2</company> <street>#STRASSE</street> <suburb>#GEBURSTAG</suburb> <postcode>#PLZ</postcode> <city>#ORT</city> <b2bStatus/> <country>#LAND</country> </customer> <delivery NewData="LFRADRESSE"> <gender>#ANREDE</gender> <firstname>#VORNAME</firstname> <lastname>#NAME</lastname> <company>#NAME2</company> <street>#STRASSE</street> <suburb>#GEBURTSTAG</suburb> <postcode>#PLZ</postcode> <city>#ORT</city> <country>#LAND</country> </delivery> </addresses> <items> <pos NewData="ATRPOS"> <model>#ARTIKELNR</model> <quantity>#MENGE</quantity> <name>#BEZEICHNUNG</name> <price>#EPREIS</price> <tax>#STEUER</tax> <attributes> <pos NewData="ATRPOSDATA"> <name>#NAME</name> <value>#VALUES</value> <price>#PRICE</price> </pos> </attributes> </pos> </items> <totals> <pos> <title>#AUFTRAG.TOTAL_TITLE</title> <value>#AUFTRAG.TOTAL_VALUE</value> <class>@AUFTRAG.TOTAL_CLASS</class> <!-- <prefix>@AUFTRAG.TOTAL_PREFIX</prefix> --> <tax>@AUFTRAG.TOTAL_TAX</tax> </pos> </totals> <number>#AUFTRAG.FREIFELD1</number> <tax_flag>#AUFTRAG.STEUERINKL</tax_flag> <parcel_service> <tracking_code>#AUFTRAG.SENDUNGSNUMMER</tracking_code> <parcel_service_name>#AUFTRAG.SENDUNGSART</parcel_service_name> </parcel_service> </ORDER> </ORDERS> Das ist die Vorgabe von Amicron
Das ist Fehlverhalten, dass für alle bisherigen Shopversionen mit REST-API gilt und nur bei einigen, wenigen Hostern zu Problemem führt. Das Problem wird für die wenigen betroffenen im kommendem Update beseitigt. Bei Estugo war das nie ein Problem, bei 1&1 aber zum Beispiel bei manchen 1&1 Kunden. Das hängt auch nur sekundär damit zusammen ob PHP per FastCGI/CGI eingebunden ist, das kann auch damit wundervoll funktionieren und tuts bei vielen Hostern. Wenn jetzt jemand von euch an dem Problem klemmen sollte, können wir das auch bevor das nächste Update kommt bei EIngang eines Supporttickets schon bei euch patchen. Das sollte damit beantwortet sein. Wir finden Pingpong übrigens auch blöd.
@HPH Du benutzt die Amicron XML/Amicron Skriptbasierte Lösung oder? Ich hab mir dein Ticket angeschaut, die Fehlermeldung ist zumindest XML formatiert. Wenn das so ist, ist die Erklärung von Amicron, die sich allein auf die REST-API bezieht raus, wegen Nichtnutzung raus. Wenn Amicron Nutzername und Passwort nicht validiert bekommt, steckt da irgendwas im Amicron Skript was nicht tut. Eine Vermutung: hast du die Passwortverschlüsselungsstärke im Shop per Option erhöht? Dann speichert der Shop Passwörter anders. Ich könnte mir vorstellen, dass Amicron das dann nicht checken kann.
@Wilken (Gambio) ich habe alles so gemacht wie Amicron das vorgibt. Die Importdefinition ist von Amicron vorgegeben. Meinst Du die Länge des Passwortes? Eine Passwortverschlüsselungsstärke habe ich nicht angepasst.??
Siehe Shop Einstellungen -> System Einstellungen > Sicherheitscenter -> Standardverschlüsselung für Kundenpasswörter Alt, weniger sicher: md5 Neu, besser: password_hash Letzteres könnte wenn aktiv ein Problem sein.
@Wilken (Gambio) Hallo und guten Morgen, die Standardverschlüsselung für Kundenpasswörter war tatsächlich auf hash eigestellt. Nachdem ich md5 eingestellt habe funktioniert Amicron mit deren Vorgaben. Warum wurde mir dieser Tipp nicht in meinen Tickets mitgeteilt? Das hätte den ganzen Ärger erspart. Vieleicht sollte man sich bei solchen Sachen mit dem Hersteller absprechen, dann würde die Behauptung, Faktura 12.0 würde nicht mit GX 3.6. nicht funktionieren, gar nicht erst entstehen.
Weil wir nicht genau wissen, wie alle Anbindungen aussehen. Das war ein Geistesblitz gestern nachmittag und ins blaue vermutet, aber anscheinend keine schlechte Idee.
Hallo Wiken, toller Blitz, habe gerade folgene Nachricht per Mail von Amicron erhalten: Wir haben das Schnittstellenscript angepasst (siehe Anlage), so dass nun auch die neue Option password_hash unterstützt wird. Habe das neue Script beigefügt. Jetzt habe ich aber noch das Problem, dass beim abrufen der Aufträge als Lieferart immer zones_zones eingetragen ist. Vieleicht noch ein kleiner Blitz? Habe aber auch schon ein neues Ticket eröfnet, aber noch keine Antwort erhalten.