Change default oauth2 token and authorize URLs from /api to /oauth2

[Woazboat]

JOSM is currently using <OSM server API URL>/token and <OSM server API URL>/authorize as the default token access and authorize URLs.
E.g. for the server API URL http://localhost:31500/api the default URLs would be set to http://localhost:31500/api/token and http://localhost:31500/api/authorize

The rails port exposes these endpoints under /oauth2 and not under /api:

​https://github.com/openstreetmap/openstreetmap-website/blob/master/config/routes.rb#L2-L8

The default URLs for the example above should therefore be http://localhost:31500/oauth2/token and http://localhost:31500/oauth2/authorize.

The .well-known oauth file for openstreetmap.org also reflects this:
​https://www.openstreetmap.org/.well-known/oauth-authorization-server

(Of course this is only really an issue when using a custom server that does not expose a .well-known file for oauth)

[mmd]

(Of course this is only really an issue when using a custom server that does not expose a .well-known file for oauth)

I was wondering a bit about this point. Although I have set up a private key for Doorkeper, which enables the .well-known/oauth-authorization-server endpoint on Rails, I don't know how JOSM would use that information for my local instance on ​http://localhost:31500.

I believe @tsmock mentioned in some conversation that this feature is enabled for a few whitelisted servers only, but I don't seem to recall any specifics.

[Woazboat]

I see a request for http://localhost/.well-known/oauth-authorization-server in the josm log output when configuring it to use my local server.

A .well-known/oauth-authorization-server on a non-default HTTP port won't be used by josm in any case.

[mmd]

Thanks, this seems to work indeed. I found a small glitch while testing, please see the step by step description below.

Preferences -> OSM Server
Set OSM server URL to ​http://localhost/api
Use OAuth 2
Initial situation: no OAuth2 token available

Step 1: Check "Display Advanced OAuth Parameters"
Step 2: Uncheck "Use default settings"
Step 3: Enter Client Id (from your own JOSM registration on ​http://localhost/oauth2/applications)
Step 4: Press "Authorize now (Fully automatic)
Step 5: Try "Test Access Token" -> should work
Step 6: Confirm popup by clicking "ok"

If you hit "Ok" after step 3 already, JOSM will show the "Use default settings" flag next time you open the settings dialog, and the previously entered Client Id is no longer available (blank value).

[taylor.smock]

(Of course this is only really an issue when using a custom server that does not expose a .well-known file for oauth)

I'm not really interested in trying to make servers that don't have a .well-known file work with minimal configuration.

I'll take patches if someone makes one though.

I believe @tsmock mentioned in some conversation that this feature is enabled for a few whitelisted servers only, but I don't seem to recall any specifics.

I was probably talking about hard-coding client ids. I'm really only interested in hard-coding client ids from servers that match the following criteria:

• intended for public use (no, I won't add client ids for private/dev servers; we already have a dev client id for unit tests)
• significant usage (I'm not interested in adding a client id for a server with few users)
• doesn't require any significant code changes in JOSM (at most an additional statement for selecting the correct client id)

Anyway, it sounds like the primary issue is that JOSM is losing the port when making the .well-known call.