Request for a new contrib repository for a user and group name formatter and cleaner

Development
1

We have duplicated code for cleaning and formatting user and group names, with patterns like ${username._clean}, ${user._lowerCase} and such.

In OIDC:

In LDAP:

In Confluence-XML:

That last UsernameCleaner class could be moved to a dedicated contrib repository / module that could be reused everywhere. It was designed for eventually being reusable across all those projects. WDYT?

I don’t have a good name for this. username-formatter? name-formatter? username-cleaner?

It’s also for groups, it’s for both cleaning and formatting, but user-and-group-name-formatter-cleaner seems a bit lengthy. I think the “cleaning” part can be implied in “formatting”.

2

Should it be a contrib repo or some utility in xwiki-commons?

3

Eventually having it in xwiki standard would probably be even cleaner indeed

4

I don’t know much this domain so this is just my uninformed and generic opinion :slight_smile:

Some thoughts:

  • It feels a lot of overhead to create a smallish repo just for this.
  • It seems related to authentication
  • If all authenticators require this (is it the case?) then maybe this should be put in xwiki-platform/commons inside the authentication code?
  • If it stays as a contrib extension, then maybe expand the scope for a repo containing authentication-related common code?
  • Last option, put the code in a module in the LDAP code and then have the other extensions depend on that module.
5

I’d be fine with all these outcomes. Note that the confluence one doesn’t do authentication. I agree that a full repo just for that could be a big overhead for not much.

6

Hello,

I would say the issue by adding it in XWiki standard is that it will take a long time to be able to use it in the contrib extension. I mean all extension which will depends on XWiki <17.10 won’t be able to use it. So it could be a limitation to use it in the extensions.

7

I would say the issue by adding it in XWiki standard is that it will take a long time to be able to use it in the contrib extension

Absolutely, and I should definitely have proposed this code grouping already last year or so.

Now, the code is small and the duplication doesn’t hurt too much (still needs to be fixed eventually!), and waiting for the cleanest outcome may be worth it

8

Not xwiki-commons, but it would make sense in xwiki-platform eventually, yes.

But then the problem is timing. Authenticators, even more than other types of extensions, traditionally don’t upgrade their parent very often (LDAP is still using 8.4 as parent) so an xwiki-platform tooling would not be usable for them before a very long time. And honestly, it’s not easy to design this kind of tool when nothing is using it.

I would suggest to start with a contrib extension, and when we are happy with it (i.e. most generic concepts from various user related supported extensions have been moved to it and fit them all), move it to xwiki-platform. That way contrib extensions can use the contrib tools unti they move to the right version of xwiki-platform.

Yes, there is actually a lot that can go in there (a lot of what authenticators do could be made more generic), and to me, it’s about user management in general, not just authentication (as shown by the Confluence imported example).

It works too technically, but not sure it make much sense semantically.

1 Like
9

+1

It works too technically, but not sure it make much sense semantically.

+1

1 Like
10

We also probably want to avoid the module needing to be updated as often as the ldap extension