Used OAuth2 Library

[anagromataf]

Is there a reason, why ejabberd uses a fork of oauth2? It seams, that there are no differences in the implementation. I'm currently working on a project, where I want to integrate ejabberd in an other project (where ejabberd is just one component/app). This project is already using the original oauth2 project. With this fork, the dependencies are getting a bit messed up.

[mremond]

Reason is that we need to rely on hex.pm version.

[bowlofeggs]

Since the fork is called p1_oauth2 and the app name corresponds to that name, would that make it possible to have both installed on the same system?

[anagromataf]

But what happens if I call the function oauth2:authorize_password/4 for example. There are then two applications with the same modules (or at least the same names) in the project.

[mremond]

Yes, for now it will conflict. We need to think how we can best solve that issue. We will be probably iterating again on oauth2 in 16.04, so we keep that in mind for that release.

[cromain]

we won't have time to address this for now, I postpone this again ...

[badlop]

p1_oauth2 was forked from kivra/oauth2 in this commit: https://github.com/kivra/oauth2/commit/8d129fbf8866930b4ffa6dd84e65bd2b32b9acb8

Since then, p1_oauth2 only got updates to compile with recent Erlang, rebar, work with hex.pm, Travis and Github Actions.

During that time, oauth2 got several improvements, I recently applied them to p1_oauth2: https://github.com/processone/p1_oauth2/issues/4

The main reason for ejabberd to use p1_oauth2 instead of oauth2 is this: https://hex.pm/packages/p1_oauth2

If the module name conflict would be a problem, I can see two solutions:

• A) Rename this forks' module names, so they don't conflict
• B) Contact Kivra and provide PRs to get its upstream project up-to-date, and help publish in hex.pm, and hope they are interested in keeping upstream up-to-date