[PATCH] OAuth 2 against a server without a built-in client id: advanced OAuth parameters not used

[wangi]

For an API URL JOSM has no built-in client id for (anything other than openstreetmap.org, its dev server and openhistoricalmap.org), the Authentication preferences offer "Display Advanced OAuth Parameters", where the user can enter the client id and secret of an OAuth 2 application registered on that server. Nothing consumes those values, so OAuth 2 cannot be set up against such a server at all.

What steps will reproduce the problem?

Steps to reproduce, JOSM 19621, against an openstreetmap-website instance (lugus.opengeofiction.net):

1. Preferences, OSM Server: set the API URL, choose OAuth 2.0, tick "Display Advanced OAuth Parameters", untick "Use default settings", enter the client id of an application registered on that server. "Authorize now (Fully automatic)" stays disabled. AuthoriseNowAction.updateEnabledState() takes the client id from OAuthParameters.createFromApiUrl(), which knows only stored tokens and the built-in list, although the wizard is handed the panel's parameters when the button is pressed.
2. Press OK and restart JOSM: the entered parameters are gone and "Use default settings" is ticked again. AdvancedOAuthPropertiesPanel.rememberPreferences() writes them to oauth.access-token.parameters.OAuth20.<apiUrl>, but nothing reads that key back.
3. Get the flow to start anyway (with the patch's first fix) using a confidential application, the default when registering one on openstreetmap-website: the browser round trip completes, then the remote-control callback fails with jakarta.json.stream.JsonParsingException: Invalid token=EOF at (line no=1, column no=0, offset=-1) from OAuth20Token.<init>. OAuth20AuthorizationHandler.handleRequest() never sends client_secret in the token exchange, so the server answers 401 with an empty body, which is then parsed as JSON.

The attached patch fixes all three: the button enables from the panel's client id whenever "Use default settings" is off and re-evaluates as the field or checkbox changes; createFromApiUrl() reads the remembered parameters before falling back to the defaults; the token exchange sends the client secret when the panel has one, and a refused exchange reports the HTTP status and the server's message instead of failing in the JSON parser.

Verification

Tested against lugus.opengeofiction.net with user-registered applications, confidential with id and secret, and public with id alone: the button enables, the automatic flow completes and uploads work, and the parameters survive a restart.

Note: Authorize now (Manually)

One further observation, not addressed by the patch: "Authorize now (Manually)" opens a dialog with an "Advanced OAuth parameters" tab, but the values entered there cannot start any flow; the dialog only accepts a finished access token. Given the UI labels, is that whole dialog an OAuth 1 holdover?

Please provide any additional information below. Attach a screenshot if possible.

Revision:19621
Is-Local-Build:true
Build-Date:2026-09-12 11:17:54

Identification: JOSM/1.5 (19621 SVN en_GB) Linux Ubuntu 26.04.1 LTS
Memory Usage: 440 MB / 3772 MB (291 MB allocated, but free)
Java version: 25.0.4+7-1-26.04-Ubuntu, Ubuntu, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 3840x2400x[Multi depth]@60Hz (scaling 2.00×2.00) :0.1 4608x2592x[Multi depth]@60Hz (scaling 2.00×2.00)
Maximum Screen Size: 4608×2592
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: en_GB.UTF-8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Locale info: en_GB
Numbers with default locale: 1234567890 -> 1234567890
Desktop environment: ubuntu:GNOME
Java package: openjdk-25-jre:amd64-25.0.4+7-1~26.04
Java ATK Wrapper package: libatk-wrapper-java:all-0.44.0-1
libcommons-logging-java: libcommons-logging-java:-
fonts-noto: fonts-noto:all-20201225-2build1

OSM API: https://lugus.opengeofiction.net/api

[wangi]

It would be good if #24889 and/or #24890 could be applied for 26.09. Without them there's no user-facing way to authenticate JOSM against a non-OSM/OHM openstreetmap-website instance which has basic authentication disabled (which is true for a considerable time now).

#24889 streamlines it for OGF, while this one allows it to work for OGF and any other niche site via a more manual flow.

By "no user-facing way" I specifically mean short of running bundle exec rails runner 'puts User.find_by!(:display_name => "username").oauth_token("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx").token' for every user running JOSM and then sharing that token with them individually.