I am happy you got it running.
As this project evolves, we might want to make this script available to others. So I am still a bit confused about what the requirements are for a callback_url. Does it just have to be a live address on the public web for non-interactive access by the Mapillary servers?
The “Callback URL” is where a HTTP client (often a browser) is redirected to with an authorization token (some call it access token). In other words, this is the mechanism by which your client (or app) gets the authorization token. The reason this token retrieval mechanism has been designed this way was because the designers could not or were unable to think of any other consumer for access tokens than web browsers and websites. This is really some bad design of standards at its best.
Websites usually specify simply a URL pointing to some restricted access content on their website. For example, when you login with Facebook on Mapillary’s website, you enter your credentials on a Facebook authentication page and then you are redirected back to Mapillary while having access to you user data, like your feed, dashboard, editing capabilities etc. Mapillary has registered their website with Facebook and have specified
https://www.mapillary.com/app (because this is where Mapillary wants users to continue after authentication and authorization) for the callback URL in Facebook’s OAuth implementation. So, if you want to authorize your app (or script, or whatever) to have access to restricted data or functionality on Mapillary, you must register your app on Mapillary and your app must be able to handle a HTTP redirect, because this is how your app gets an authorization token. Now, since your app is not a website but runs locally, you can specify
http://localhost) for the callback URL. As a matter of fact, you can specify any existing or non-existing syntactically correct URL in “Callback URL” on Mapillary to get a
client_id assigned. So, you do not need a website to create a
client_id. However, if you want to be able to retrieve authorization tokens you either have to run a website or your app must be able to handle HTTP redirects.
By the way, imho Mapillary should handle authorization token validity more strictly. Currently, tokens are valid indefinitely, unless of course they are explicitly revoked. One could argue that any damage that could be done with a stolen token is limited; the worst things that could happen would be that all of a victim’s images could be deleted or images could be vandalized with blurrs. So, yes the impact on the web service as a whole would be limited but some contributors have contributed millions of images without having backups. On the other hand, Mapillary does keep backups. However, I am not sure if or for how long Mapillary keeps backups of images explicitly blurred with the blur editor. Anyhow, imho even though any damages would be limited tokens should be valid for no longer than 24 hours because you usually want to have a cascade of measures to limit damage.
Get well soon!