RFC: Two new extensions for the wiki: Log in via openstreetmap.org and vote via a GUI

Hi everybody,

I wrote two small MediaWiki extensions for wiki.openstreetmap.org: one to let you log in via your OSM account and one to provide an easy to use in-wiki GUI for proposal voting.

I also set up a small demo wiki so that you all can try both extensions out:

https://demo-wiki.push-f.com/

You can leave your feedback using both extensions on the demo wiki, or alternatively here on the forum.

Cheers,
Martin

4 Likes

After connecting Wiki account and OSM account, will logging in on one of both websites also log me in on the other one?

Good question. The login uses the same mechanism as this forum, so to log in via openstreetmap.org you need to log in to openstreetmap.org if you aren’t already. But logging into openstreetmap.org does not automatically log you into this forum (or a wiki using my extension) … it just makes it very easy to do so. Technically each website has its own session, so logging out of one of them also doesn’t log you out of the other.

1 Like

FWIW: I already did a proof-of-concept here: Add osm.org authentication to Wiki · Issue #507 · openstreetmap/operations · GitHub

You can watch the demo video here: Add osm.org authentication to Wiki · Issue #507 · openstreetmap/operations · GitHub

I’m using only officially supported extensions, such as OpenID Connect to avoid any long term maintenance issues.

It’s a bit of a pity that you spent some extra time on the topic. Somehow you seem to have missed the discussion on the Wiki discussion page? https://wiki.openstreetmap.org/wiki/Talk:Wiki#Authentication_from_osm.org

3 Likes

Right, I have seen that issue. I do not think that the OpenID Connect extension neatly handles the fact that many users already have wiki accounts with usernames different from their OSM account (and configured email addresses might also be different). I developed my extension specifically to address our scenario by making it easy to link the right accounts together without needing to change any usernames or settings.

Besides openstreetmap.org does not support OIDC yet so implementing that would also add more code that has to be maintained by somebody. Introducing a new feature will always take code that has to be maintained by somebody. I am committed to maintaining my extensions if they are to be adopted by the OSM wiki and I took care to write clean and maintainable code. Sidenotes: 1) my extension does not depend on OAuth 2.0 at all, if OIDC is supported at some point it could be easily used with my extension as well. 2) My extension integrates better with the official MediaWiki API than PluggableAuth, which does not support MediaWiki’s builtin Special:LinkAccounts & Special:UnlinkAccounts pages.

So I do not pity the time I spent writing the RedirectAuth extension, since I think it’s necessary to properly support the linking of already existing accounts in a user-friendly manner.

2 Likes

Mentioning @Firefishy as he might be interested in this topic. He mentioned SSO in his talk at the last SOTM.

1 Like

Different user names are not really an issue here, matching of user names between osm.org and the wiki happens based on email addresses only, like documented in the OpenID Connect extension. Existing Wiki user names also don’t need to change at all.

If users happen to have different email addresses, matching obviously won’t happen. If they match, the integration is completely seemless.

I covered that bit on the Github issue. It’s basically a plugin to the doorkeeper plugin which is already in place. Maintenance would be done in that repo.

That’s great to hear. I’ve also seen that the OpenID Connector extension does not support the Link and UnlinkAccounts. Maybe it would be an option to bring such a feature to the OpenID Connect extension instead, so that you don’t have to maintain your code for years to come.

The main reason why I’m stressing the custom wiki extension topic, is that it’s causing operational issues rather frequently, it’s blocking mediawiki updates, etc. And there’s only limited bandwidth to maintain all that custom code.

Right, I consider matching based on email addresses to be suboptimal. It might work in most cases but in cases where the email addresses do not match it will lead to confusion, especially because as a user you are not really aware that A) the matching happens based on email addresses in the first place and B) which email address you specified several years ago when you created your accounts.

Ironically that very plugin has a note in its README that its looking for maintainers.

That would have to be implemented in the PluggableAuth extension. Note that my extension extension intentionally does not use PluggableAuth because I find its documentation to be lacking and its API design to be questionable (PHP references make for very hard to read code). I think it makes more sense to use the underlying PrimaryAuthenticationProvider MediaWiki API directly.

I think extensions only cause problems when they’re unmaintained. I’d be actively maintaining these extensions, so I don’t think that should be a problem … until I get hit by a bus :laughing: … I’ll look into increasing the bus factor of my extensions.

Can we reply on votes directly? That’s nearly as important. Ideally integrated with Convenient Discussions or Discussion Tools.

1 Like

Yes, I’m well aware of that. It happens somewhat frequently that Gems on Rails are unmaintained. Project maintainers have demonstrated time and again that they can handle such situations, that’s why I’m not that much concerned. Also, there’s definitely much more experience around on Rails compared to Mediawiki. It was one of the main reasons, why I picked some existing Wiki extension, rather than even considering adding yet another custom plugin.

It’s also a question of mindshare. If there’s noone else using a custom plugin, chances are slim, that others already experienced or even solved the issues you’re struggling with.

This is great. Single sign-on for the wiki has been discussed before.

The voting system is still missing {{vote|wat}}:

  • Wat-small I would like to express a degree of incredulity at this proposal.
1 Like

It looks really nice. These two extensions would render my proposal obsolete because the most important issues are resolved.

Maybe 3 things as feedback/questions:

  1. For visual purpose, the green and red icons would be nice so you can have a quick overview of what is being votes.
  2. Is is possible you can make a simple reply system so you don’t have to use the source text anymore
  3. How does it handle edits conflicts? I noticed on the current vote that it is very easy to have an edit conflict. How does this plugin solve that?
1 Like

Note that Vote is the name of an old existing extension: Extension:Vote - MediaWiki — not that it matters too much, and probably you could even take over that page to document this new one.

2 Likes

Thank you for bringing these extensions to my attention! Integrating with them would indeed be a very good idea. I think integrating with Discussion Tools should take priority since it’s developed by the MediaWiki project and will probably be bundled with MediaWiki in the future.

I experimented with getting DiscussionTools to work within the <vote> tag but ran into some issues, so I have asked the DiscussionTools developers about it. Let’s see what they have to say :slight_smile:

Right, I happen to have much experience with MediaWiki :slight_smile:

My extension is passing through any line that doesn’t start with *␣, so if you omit the space you can add *{{vote|wat}} :wink:

Good idea, I’ll look into adding icons.

I certainly don’t want to implement a reply system, but integrating with an existing reply system would be awesome and might be possible, see ⚓ T320777 Discussions within tag extensions?.

Edit conflicts are mostly a problem because when you start editing the page you essentially copy its current version into the editor. Since that doesn’t happen with my extension edit conflicts aren’t such a problem.

Thanks for the notice :slight_smile: Since the old extension page was already archived and the extension isn’t even available for download anymore I have moved the old page out of the way and documented my extension at Extension:Vote - MediaWiki.

1 Like

I had noticed the old page as well, and agree it made sense to take over the archived page for the new extension. I have cleaned up the links to the page, since almost all of the existing links referred to the older extension.

I actually was concerned about something slightly different: I noticed that the extension sort of breaks down a bit if one tries to nest a vote inside another, like @lectrician1 did here. Of course, that is not the extension’s responsibility to handle deliberate or accidental syntax errors, but perhaps it should fail more loudly in such cases, because the voting widget is still visible and it may lead to confusing results.

On a separate note, I find it telling that, even though I was the one to suggest greying out superseded votes in the first place, it took me a few looks at the page in the test wiki to actually notice that was what was happening there. I think it may be better to strike-through superseded votes, either in addition to the greying out, or instead of it (I also suspect the mere graying out of votes may pose accessibility issues).

Another thing that might help figuring out such superseded votes is nesting the new vote as a child of the previous one; this would of course be more complex to implement, and would lose the chronological order, but I’d argue that’s the latter is already not the primary concern in these discussions, since we do want (and use) threading to represent scoped discussions under a vote anyway.

1 Like