Modify ↓

Opened 3 weeks ago

Closed 2 weeks ago

Last modified 13 days ago

#24890 closed defect (fixed)

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

Reported by: wangi Owned by: team
Priority: normal Milestone: 26.09
Component: Core Version:
Keywords: template_report oauth Cc:

Description

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

Attachments (1)

0001-OAuth-2-honour-user-supplied-parameters-for-servers-.patch​ (14.4 KB ) - added by wangi 3 weeks ago.

Download all attachments as: .zip

Change History (8)

comment:1 by wangi, 3 weeks ago

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.

comment:2 by wangi, 3 weeks ago

Summary: OAuth 2 against a server without a built-in client id: the advanced OAuth parameters are not honoured → [PATCH] OAuth 2 against a server without a built-in client id: advanced OAuth parameters not used

comment:3 by stoecker, 3 weeks ago

Milestone: → 26.09

comment:4 by anonymous, 2 weeks ago

The refreshed OpenGeofiction, based on current openstreemap-website, is now live. I've added back in support for Basic Auth temporarily so our users can continue to use JOSM. I'll phase that out when this and #24889 are in the 26.09 JOSM release.

Thanks/L

comment:5 by wangi, 2 weeks ago

Apologies, that last comment was me

comment:6 by stoecker, 2 weeks ago

Resolution: → fixed
Status: new → closed

In 19627/josm:

fix #24890 - handle OAuth 2 against a server without a built-in client id - fix #24889 - add OAuthID for OpenGeofiction - patches by wangi

comment:7 by skyper, 13 days ago

Ticket #24417 has been marked as a duplicate of this ticket.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.