Tracking service ideas

[ZeiP]

Support for the following tracking services has been previously requested. Add a comment if you need one of these or another one. Including support for a service usually requires at least a test tracking code, so be prepared to provide one.

• DHL
• FedEx
• DPD
• Hermes
• TNT
• La Poste / Chronopost
• DB Schenker
• Inpost: https://docs.inpost24.com/display/PL/API+ShipX+ENG+Documentation

[ZeiP]

Chronopost doesn't seem to provide a public API. The API itself seems reasonable, but requires some kind of authentication (probably cookies from the site.)

[Thaodan]

DHL API here: https://developer.dhl.com/api-reference/shipment-tracking#reference-docs-section

[adelnoureddine]

Chronopost doesn't seem to provide a public API. The API itself seems reasonable, but requires some kind of authentication (probably cookies from the site.)

I've integrated LaPoste/Colissimo/Chronopost API (from here). It, indeed, requires an authorization key to send with each request header. The authorization key is immediate to generate after a free registration at their developer website.

A working version (without pushing the key) is in my fork repo. I also modified the app to integrate the courier name, and proper handling of response and dates. I can create a pull request to merge the changes here.

Though not sure how you would like to handle the auth key (use keys from my LaPoste dev account, or another one for paketti? And whether to add the key publicly in the source code or if there are alternatives).

[ZeiP]

Great, thanks!

An API key is usually required so that access can be easily denied for misbehaving users. If the API key is added to the Sailfish package, then it's always public and therefore a separate API key should be used.

I tried to interpret the terms and conditions of La Poste via Google Translate to figure out if they allow or deny sharing the API key to the users. It says something like ”The User agrees to implement all necessary means to ensure the confidentiality of his username and password as well as the security of access to his User Account.”, which can mean that sharing the API key is not allowed; this could of course be checked from La Poste.

There are a few ways to store the API key:

1. With the software package
   • Either plaintext in the QML/JS code (very easy to extract), or
   • In a compiled C++ binary (easy to extract AFAIK)
2. Creating a proxy server which queries the actual API. This would allow keeping the API key secret but on the other hand all the queries made by users go through this server, which could be a privacy issue for the users.

I think the best approach here would be to ask La Poste if it's ok to deploy an API key in the software package in either of the two ways and do as they suggest.

I'd be happy to merge in the new tracker provider if it's ok with them. Maybe it's easier for you to ask them as you speak French?

[Thaodan]

Hey,

If they work like other projects that gave API keys to FOSS project like Google this key can be public, but better ask them. You can set and read the key just fine from QML. If we decide to force the user to provide his own key that would be best. Depending on how high the limit on the API key is, this is needed anyway.

If the API key would be stored as secret in the app then it could be also set during build avoiding to store it in source tree if not allowed.

[adelnoureddine]

Yes, I’ll check with them and see what they propose. Adding it in secret during build is probably better, avoiding users to register for their own key.

[adelnoureddine]

I asked on their forum, but the initial responses is to better keep the key in an out-of-tree config file. I also agree that a proxy isn't the right solution. I think as you both said, we can create such file to hold all auth keys (I check DHL API too, and they also require an auth key), which we read in the compiled C++ binary and pass it to QML on runtime. Even on Android/iOS, such keys can be extracted by monitoring HTTP requests. As this app and SFOS have low usage (the entire SFOS user base is low compared to Android/iOS), the risks are low for the auth key to filter out, and can easily be replaced with an new key. What do you think ?

[adelnoureddine]

I've added the C++ bindings with the auth key in the headers. It's in my fork repo. The actual key would then be added for the build then removed before pushing to git.

[ZeiP]

Awesome! Could you please make a pull request so I can review and merge the changes?

[ZeiP]

I released version 0.7 to OpenRepos and here in GitHub featuring La Poste tracking along with some other minor bug fixes.

[adelnoureddine]

That's great, thanks a lot!

[atlochowski]

DPD and FedEx would be nice to have. I will request Inpost. https://docs.inpost24.com/display/PL/API+ShipX+ENG+Documentation

[ZeiP]

@Thaodan, DHL support has been added to the most recent version (0.7.1), thanks for the API link!

[ZeiP]

Regarding DPD tracking: I can't really figure out how the DPD tracking works. It seems that there are different codes for different countries and one site doesn't seem to support all the codes. If someone knows how the codes work (which courier selections there should be and which APIs should be implemented) that'd greatly raise the odds of DPD support being implemented.

[ZeiP]

I added all the tracking service suggestions as separate issues to avoid making this issue a mega long one. Closing this.