Closed extinctPencil closed 2 years ago
Hello, @extinctPencil. For authorization, the latest IDeditor uses OSM OAUTH2, whereas tasking-manager uses OAUTH1. During the update of IDeditor to OAUTH2, there were some changes in passing auth parameters, such as the osm url used to be sent as urlroot
on IDeditor with OAUTH1, but it was changed to url
on the latest ID. That is why you are getting the error seen in the screenshot above.
We are now working on implementing OAUTH2 on tasking-manager, which will also bring the most recent IDeditor here: #5029.
As a part of OAUTH2 implementation on TM, hotosm/id was updated to latest IDeditor recently.
Many thanks @Aadesh-Baral that explains things , however not the easiest thing to debug , or understand for a project newbie .... I guess it will be resolved once the OAuth2 branch is merged , until such time anyone like myself who comes to the party is gonna struggle to get a working version from the develop , named release, or master branch... and probably feel put off.
I don't really feel qualified or competent to make changes in a project and languages that I am so unfamiliar with , even if its only removing a ^ from packages.json .. If the community thinks the change I propose is a sensible one , then I will create a branch and a PR ....
Also would have been nice if @hotosm/id emitted some debug logging to the browser console - which showed 0 Issues / warnings / Info Error - The IdEditor has not been initialised would have saved a couple of hrs !
@extinctPencil Thanks for feedback. Yes i think this will be resolved once OAuth2 branch is merged.
Please feel free to send a PR once you feel familiar with the project and then we can discuss about it together with the community.
There is a slack channel #tasking-manager on hotosm slack where you can ask any queries regarding tasking-manager and you can easily reach out to maintainers in case.
Describe the bug Latest Docker Build [once backend python package issue resolved see #5300 runs , however the ID Editor fails to Initialise correctly, when opening a mapping task... See screen Shot
Unable to reach the OpenStreetMap API. Your edits are safe locally, Check your network connection. Retry
The frontend will not work with any deployed backend including the HotOSM deployed back end.
To Reproduce Steps to reproduce the behaviour:
Expected behaviour The Id editor will open and download OSM data using teh users OSM credentials
Screenshots
Desktop (please complete the following information):
Additional context So I Spent quite a few hour on this because I had deployed a working version on 12th July , I then deployed on AKS with Https certificates an Nginx Ingress and was convinced it was my Issue. I tried multiple code versions of varying ages against various HOT OSM backends... Using fiddler I Observed that the REACT front end router seemed to be the issue .. it was issuing requests to
https:///projects/1/map/undefined/api/0.6/map.json?bbox=-77.0361328125,38.98503278695909,-77.03063964843749,38.989302551359515
not a JavaScript fan but I know enough to know undefined is not a good string ! and looking at an old working container I can see that https:///projects/1/map/undefined should really be https://openstreetmap.org
I searched the codebase and couldn't find the code for this url construction , however I confirmed that all other OpenStreetMap URLS were being formed and fired correctly eg: Login and hyperlinks , proving the Environment variables were correctly set.... I could see that the frontend/components/editor initialised the IDEditor .. I tried debugging REACT and think I proved the IDContext.Connection[] was null (or the string undefined !).
After much head scratching , I decided to look at the release history of hotosm/id , which is a ReAct Wrapper around IdEditor ? .. Id editor last changed in June .. not that then as I had a working version on 12th July ... but look the wrapper was built on 15th July !!! so there it was .....
Whenever I build any front end old or new code it picks up the newest @hotosm/id package (2.21.1).. which wraps a broken Id ??
so looking in packages.json there we are "@hotosm/id": "^2.20.2",
which means take highest version < 3.0.0 remove the ^ build deploy ... hoorah! three days pain over !!
So why do all your tests work all the developers working on this not noticed ??? , Maybe you aren't using npm install like the docker container ? or like me when testing locally ... perhaps you are using Yarn ?? and there it is a Yarn.lock file checked in ?? having at one point fixed the @hotosm/id at 2.20.2
Somehow we need to consider how we can normalise the dev , release and docker build tests and builds ?? Had I not got a working version on 12th July by chance I would have given up on getting a working deployed copy long ago ... deploying the first time so easily in docker impressed me enough and subsequently it annoyed me just enough to be persistent ....
I now have a productionised version deployed on Azure AKS and will share scripts and thoughts once I have had a rest !!!