Tracking der Deutschen Post erstmal wieder verfügbar

  • Guten Morgen!


    Christian hat mich wegen des Deutsche Post-Trackings in dieses Forum gescheucht. ;)

    Ich hab jetzt erstmal provisorisch was gebaut, was die alte Sendungsverfolgung der Deutschen Post wiederherstellt.

    Die Datei kann runtergeladen und einfach vom Rechner aus ausgeführt werden, Steffen kann die natürlich aber auch gerne irgendwo auf seinen Server packen und dann einen Link setzen. Da ich hier nur .txt und nicht .html hochladen darf heißt die Datei Posttracking.txt

    Einfach in Posttracking.html umbenennen und aufrufen.

    Der Quelltext ist bewusst simpel gehalten damit jeder nachvollziehen kann, dass da keine Tracker oder irgendein Mist drin ist. Ich hab auch nichts formatiert, die Ausgabe ist so wie sie direkt aus der API kommt.

    Wenn irgendwelche Änderungswünsche bestehen gerne Bescheid sagen.

    Hier eine Trackingnummer zum Testen: LR022265720NL


    Gruß

    Dennis


  • Hab mich gerade entschieden heute Abend noch ein Dropdown-Menü für Parcel, Express und eCommerce hinzuzufügen. Dann ist das erstmal eine All-In-One-Lösung und man kann sich parcello sparen. Momentan wird nur die alte Sendungsverfolgung von deutschepost.de abgefragt, die es so ja auch bei parcello nicht mehr gibt.

  • Was spricht gegen DHL.com? Dort wird auch die API verwendet.


    Gib mal als Test die LR022265720NL bei dhl.com ein. Sobald Sendungen zwischen Brief und Parcel wechseln reißen die Sendungsverfolgungen oftmals komplett ab. Sowohl bei dhl.de, dhl.com als auch in der App. Es gibt auch keine Drittanbieterseite mehr die dann noch anzeigen kann, dass die Sendung mit L oder R am Anfang in einer Filiale liegt. Geschweige denn in welcher Filiale. Auch Rücksendungen sieht man nicht mehr. ^ck hatte das Problem letztens in einem "15-seitigen" Text im Fragen-Antworten-Forum beschrieben. Ist ein technisches Problem, das manche (viele...) Sendungen betrifft und das DHL anscheinend nicht lösen will oder nicht lösen kann.


    Noch ein kleiner Nachtrag: Soweit ich weiß zeigt dhl.com auch nicht die genaue Sendungsart, gebuchte Zusatzservices oder Maße an. Wenn ich da heute Abend nochmal rangehe werd ich das mit abfragen lassen.

  • Problem ist nur das sehr strikte Limit der API bzgl. Anfragen:

    Quote

    {

    "status": 429,

    "title": "Too Many Requests",

    "detail": "Too many requests within defined time period, please try again later."

    }


    Ich habe mal bei meinem Account eine Erhöhung des Limits auf 2000 pro Tag beantragt.

    Evtl. funktionieren dann auch mehr Anfragen pro Minute als jetzt.


    Ich werde dann auch mal etwas mit einem Backend programieren, die jetzige Lösung ist eher supobtimal, da so der API Key öffentlich im Quellcode ist.



    Interessanter weise gibt mir die Unifid Shipment API bei der Sendungnummer LR022265720NL die Sendungsverfolgung einer E-Commerce Sendung in die USA aus. Service war auch post-de, dafür über meinen Account und per w-get.

  • Moin Tuxus und Steffen.


    Das war von mir im wahrsten Sinne des Wortes eine Nacht- und Nebelaktion, nachdem ^ck mich bzgl. API auf dieses Forum hingewiesen hatte.


    Da ich nicht wusste wohin mit dem File hab ich es als Plain-Text hier hochgeladen mit meinem Test-API-Key. Außerdem wollte ich sicherstellen, dass das jeder einfach herunterladen und lokal ausführen und den Quelltext einsehen kann. Ich hasse nichts mehr, als wenn mir irgendwo irgendwer irgendwelche Tracker oder sowas unterschieben will.


    Das in dem File ist wie gesagt nicht mein richtiger API-Key. Ich wollt's erst direkt in PHP wrappen damit das serverseitig läuft und man den Key gar nicht erst sieht, aber dafür hätte mir nur der Firmenserver mit entsprechender Domain zur Verfügung gestanden. Die Firmen-IP wollte ich nun aber auch nicht unbedingt zusammen mit den API-Calls an DHL übermitteln. Und dann hätte halt auch niemand mangels Source Code sehen können, dass ich da keinen Mist eingebaut habe.


    Theoretisch hätte ich Steffen um 3 Uhr in der Nacht wachklingeln und das besprechen können. In der Praxis wär er wahrscheinlich entweder nicht ans Telefon gegangen oder hätte mich gefragt, ob ich noch alle Tassen im Schrank hab und mal auf die Uhr gucken soll.


    Im Nachhinein hatten wir bereits ausgemacht, dass wir das in php wrappen und dann auch noch ne kleine andere Sache mit einbauen, die ich so hier nicht öffentlich kundtun möchte. Ich bin leider bis jetzt nicht dazu gekommen. Hab seit vorgestern (?) Corona und es hat mich ziemlich erwischt. Aber gut, dass Steffen da jetzt schon mal selber was gemacht hat. Danke!


    Der API-Key wird noch ausgewechselt. Ich hatte bereits damit gerechnet, dass den irgendjemand missbrauchen wird und dann die Quota ziemlich schnell erreicht wird. Aber es ist halt auch nur der Test-API-Key. Der eigentliche hat eine höhere Quota und geht exklusiv an Steffen und wird nicht veröffentlicht.


    Wenn du da was mit eCommerce beim Call bekommst hast du wahrscheinlich die falsche API abgefragt. Es gibt eine Test-API und eine Production-API. Der Kampf mit der Production-API ist, dass die (Stichwort CORS) ein Access Denied rausschmeißt, wenn der Call aus dem Nirvana kommt und nicht von einer bei DHL registrierten Domain oder aus dem DHL-Intranet. Das hat mich den letzten Nerv gekostet. Überlicherweise würde man ja den Bearer Token verwenden, aber damit fliegt man dann auf die Nase. Fetch und GET haben dann letztendlich funktioniert. Die eigentlich angedachte Art und Weise wie sie in der API-Dokumentation beschrieben ist funktioniert nicht wenn man das anonym ohne eine Domain zu hinterlegen machen möchte.


    Vergleich einfach mal meine API-Adresse mit der, die du verwendet hast. Bin mir ziemlich sicher, dass bei dir der Test-Server drin steht.


    Am Ende wird die post-de-Abfrage ganz normal in der paketanalyse.php von paketda.de mit vernünftigem Rendering etc. landen. In ein paar Tagen wird es, so Gott (Steffen) will, soweit sein. Ich bin gerad schon dabei, aber Corona vernebelt mir gerade ein wenig mein Gehirn. 10 mal mehr Try & Error als ich sonst von mir gewohnt bin.



    Gruß

    Dennis

  • Habe das Script von ChatGPT umschreiben lassen, so dass der API-Key nicht mehr öffentlich sichtbar ist.

    Liegt der Key in der umgeschriebenen Version auf dem Server (PHP?)? Im Quelltext kann ich nichts mehr finden, falls er doch im Quelltext ist, würde es mich interessieren, wie ChatGPT ihn verborgen hat.


    Ich bin gerad schon dabei, aber Corona vernebelt mir gerade ein wenig mein Gehirn.

    Gute Besserung

    Da ich nicht wusste wohin mit dem File hab ich es als Plain-Text hier hochgeladen mit meinem Test-API-Key. Außerdem wollte ich sicherstellen, dass das jeder einfach herunterladen und lokal ausführen und den Quelltext einsehen kann. Ich hasse nichts mehr, als wenn mir irgendwo irgendwer irgendwelche Tracker oder sowas unterschieben will

    Kann ich sehr nachvollziehen, wenn ich etwas veröffentliche, veröffentliche ich es meist auch mit Quelltext. So können fremde einen auch besser auf Fehler aufmerksam machen.

    Das in dem File ist wie gesagt nicht mein richtiger API-Key. Ich wollt's erst direkt in PHP wrappen damit das serverseitig läuft und man den Key gar nicht erst sieht, aber dafür hätte mir nur der Firmenserver mit entsprechender Domain zur Verfügung gestanden. Die Firmen-IP wollte ich nun aber auch nicht unbedingt zusammen mit den API-Calls an DHL übermitteln. Und dann hätte halt auch niemand mangels Source Code sehen können, dass ich da keinen Mist eingebaut habe.

    Oracle Cloud bietet übrigens dauerhaft kostenfreie VPS an. (Nur als Tipp wenn du öfters mal Server für deine Projekte brauchst)

    Arm-based Ampere A1 cores and 24 GB of memory usable as 1 VM or up to 4 VMs

    und insgsamt 2

    AMD based Compute VMs with 1/8 OCPU and 1 GB memory each


    Wenn du da was mit eCommerce beim Call bekommst hast du wahrscheinlich die falsche API abgefragt. Es gibt eine Test-API und eine Production-API. Der Kampf mit der Production-API ist, dass die (Stichwort CORS) ein Access Denied rausschmeißt, wenn der Call aus dem Nirvana kommt und nicht von einer bei DHL registrierten Domain oder aus dem DHL-Intranet. Das hat mich den letzten Nerv gekostet. Überlicherweise würde man ja den Bearer Token verwenden, aber damit fliegt man dann auf die Nase. Fetch und GET haben dann letztendlich funktioniert. Die eigentlich angedachte Art und Weise wie sie in der API-Dokumentation beschrieben ist funktioniert nicht wenn man das anonym ohne eine Domain zu hinterlegen machen möchte.

    Ich habe die Shipment Tracking - Unified API genutzt (https://developer.dhl.com/api-reference/shipment-tracking/) und habe "post-de" als Sendungsart angegeben. Genutzt habe ich die Test-Api.


    Wie hast du CROS ohne Server umgangen? Kanst du mir dienen Quellcode evtl. per PN senden? Ich löse so etwas sonst immer über eine Proxie (z.B. allorigins.win)


    Meinen Versuch, CROS zu umgehen, kannst du hier sehen: https://shippus.world/tracking/ (z. B. RM436859185DE)

    Der Quellcode, welchen man über den Browser sehen kann, ist der vollständige, welcher für die Abfrage verwendet wird.


    Paketda

    Wäre es nicht evtl. sinnvoll, das Tracking des Weltpostvereins in die Paketanalyse mit einzubauen? Die Einbindung ist sogar recht simpel, da man nicht mal einen API Key braucht. Ressourcen: https://gajdkp.api.post/ u. https://shippus.world/tracking/

  • Liegt der Key in der umgeschriebenen Version auf dem Server (PHP?)? Im Quelltext kann ich nichts mehr finden, falls er doch im Quelltext ist, würde es mich interessieren, wie ChatGPT ihn verborgen hat.


    Geht ja nicht anders. Man könnte ihn natürlich in der PHP auch noch verschlüsseln und dann mit JS oder was auch immer von irgendwoher den Schlüssel holen um ihn wieder zu entschlüsseln. Oder man benutzt obfuscation und baut sich irgendwas zurecht bei dem niemand mehr durchsteigt. Nur was bringt's? Hab ich die PHP guck ich in die Konsole und seh den Header oder wie auch immer der Key übermittelt wird wieder im Klartext. Ist es HTTPS nehm ich das Zertifikat, lad's auf den Raspberry Pi und pack für den Domainnamen die IP des Pis ins hosts-File. Kurz gesagt: Sobald ich die PHP hab ist bei ner API alles sinnlos. Aber das ist ja auch völlig in Ordnung so, da kommt man ja normalerweise nicht ran. Wenn man da doch rankommt ist ja nicht nur diese eine Datei "gekapert" sondern der ganze Server.


    Oracle Cloud bietet übrigens dauerhaft kostenfreie VPS an. (Nur als Tipp wenn du öfters mal Server für deine Projekte brauchst)


    Danke. Für meinen privaten Kleinkram reicht mir mein Raspberry Pi. Wollt's auch erst dadrauf packen und dann den Link hier veröffentlichen, aber da ich ja eh den Quelltext einsehbar machen wollte und das Testen ohne API-Key nunmal nicht funktioniert hab ich's dann gelassen. Ist ja auch alles gut jetzt, Steffen hat das ja alles sehr schnell implementiert. Trotzdem würd ich's beim nächsten Mal anders machen und das direkt Steffen schicken damit er das einbaut. Entweder man vertraut seiner Seite oder eben nicht. Irgendein Witzbold hat nämlich gestern innerhalb weniger Minuten 170 mal die gleiche Sendungsnummer abgefragt. Dadurch war dann die Quota erschöpft. Aber mit sowas hatte ich schon fast gerechnet, gehörte früher selber zu diesen Typen die sich keinen "Spaß" entgehen lassen konnten. :P


    Ich habe die Shipment Tracking - Unified API genutzt (https://developer.dhl.com/api-reference/shipment-tracking/) und habe "post-de" als Sendungsart angegeben. Genutzt habe ich die Test-Api.


    Wenn du da runterblätterst kannst du irgendwo neben dem Authorize-Button zwischen der Test- und der Production-API wählen. Ich hab's nicht ausprobiert, aber ich meine die Test-API wirft nur zufällige eCommerce-Sendungen raus.


    Wie hast du CROS ohne Server umgangen? Kanst du mir dienen Quellcode evtl. per PN senden? Ich löse so etwas sonst immer über eine Proxie (z.B. allorigins.win)


    Meinen Versuch, CROS zu umgehen, kannst du hier sehen: https://shippus.world/tracking/ (z. B. RM436859185DE)

    Der Quellcode, welchen man über den Browser sehen kann, ist der vollständige, welcher für die Abfrage verwendet wird.


    Das hab ich jetzt nicht ganz verstanden. Das Tracking in deinem Link funktioniert ja auch ohne Proxy (siehe Screenshot). Und inwiefern sollte da ein Proxy etwas bringen?


    Eine Gala-Lösung habe ich dafür nicht. Ich hab beim GET-Request einen Header mit http://www.dhl.com als Referrer mitgeschickt. Die API hat das dann klaglos wie eine Art Anfrage von DHL selber hingenommen. Bisschen verwundert hat mich das schon. Eigentlich erschien mir das als zu einfach. ^^


  • Wenn du da runterblätterst kannst du irgendwo neben dem Authorize-Button zwischen der Test- und der Production-API wählen. Ich hab's nicht ausprobiert, aber ich meine die Test-API wirft nur zufällige eCommerce-Sendungen raus.

    Das löst das Problem. Jetzt versteh ich auch endlich den Unterschied zwischen der Test-/Production API ^^

    Das hab ich jetzt nicht ganz verstanden. Das Tracking in deinem Link funktioniert ja auch ohne Proxy (siehe Screenshot). Und inwiefern sollte da ein Proxy etwas bringen?


    Eine Gala-Lösung habe ich dafür nicht. Ich hab beim GET-Request einen Header mit http://www.dhl.com als Referrer mitgeschickt. Die API hat das dann klaglos wie eine Art Anfrage von DHL selber hingenommen. Bisschen verwundert hat mich das schon. Eigentlich erschien mir das als zu einfach. ^^

    Das Problem ist, dass die API genau wie die DHL API keine Cross-Origin-Requests erlaubt. Nur kann man die UPU API nicht austricksen (zumindest wäre es mir nicht bekannt), in dem ich einen falschen Referrer mit sende. Dies liegt auch daran, dass die DHL API CORS verwendet, womit Anfragen bestimmter Domains erlaubt werden können (z. B. dhl.com), bei der UPU API scheint es so, dass alle Anfragen aufgrund der SOP blockiert werden.


    CORS bzw. SOP beschränkt nur Anfragen, welche von z. B. dem JavaScript einer Internetseite gestellt werden. Hier wird das genauer erklärt: https://www.ionos.de/digitalgu…esource-sharing-erklaert/


    Die Proxy hat den Sinn, dass sie die API direkt aufruft, also so verhält, als ob sie als Client direkt die API abruft (so wie du, wenn du direkt https://globaltracktrace.ptc.p…ithTrans/RM436859185DE/de aufrufen würdest) und einen CORS Header hinzufügt, mit dem CORS Header erlaubt der Browser dann den Request.

    SOP ist immer clientseitig.


    Grundsätzlich hat die DHL-API übrigens keine Probleme mit Requests von fremden IPs:

  • Nordlicht

    Ich entschuldige mich für die späte Antwort, ich bin im letzten Monat irgendwie nicht dazugekommen hier einen Beitrag zu verfassen...



    Merkwürdig, dass dein Browser die Requets erlaubt und meiner nicht. Ich werde es aber nicht weiter untersuchen, da es ja eigentlich unwichtig ist.

    PS: Dafür, dass Du laut Profil 14 Jahre alt bist hast Du ganz schön viel Ahnung. :)

    Danke!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!