[TPROD-168] Remove OAuth1 support

[dennisameling]

Q	A
Branch?	features
Bug fix?	no
New feature?	no
Deprecations?	no
BC breaks?	yes
Automated tests included?	N/A
Related user documentation PR URL	mautic/mautic-documentation#...
Related developer documentation PR URL	mautic/developer-documentation#202
Issue(s) addressed	Fixes #...

Description:

As discussed in https://mautic.atlassian.net/browse/TPROD-190, this PR removes OAuth1 support from Mautic due to the increasing workload to keep supporting it

Steps to test this PR:

1. Load up this PR
2. In the top right corner of the screen, click the gear icon > API credentials
3. In every dropdown, you will now only have the OAuth2 option left

Ensure OAuth2 is still working by doing the following:

1. Go to the API credentials screen mentioned above
2. Click "new"
3. Enter the following data (we won't use the Redirect URI thanks to TPROD-170: Enabling 2-legged authentication for Mautic #9837, so you can fill out anything there)

4. You will now see a public and secret key that you can use
5. Open Postman
6. Make sure you exactly copy the options below:

7. After you got the token (which is the confirmation that OAuth2 still works), you can execute the API call with "Send"

[codecov]

Codecov Report

Merging #10111 (8782943) into features (4df7500) will increase coverage by 0.05%.
The diff coverage is 41.30%.

@@              Coverage Diff               @@
##             features   #10111      +/-   ##
==============================================
+ Coverage       41.56%   41.62%   +0.05%     
+ Complexity      34581    34469     -112     
==============================================
  Files            2063     2050      -13     
  Lines          111574   111196     -378     
==============================================
- Hits            46378    46281      -97     
+ Misses          65196    64915     -281     

Impacted Files	Coverage Δ
.../bundles/ApiBundle/Controller/ClientController.php	0.00% <0.00%> (ø)
app/bundles/ApiBundle/Event/ClientEvent.php	0.00% <0.00%> (ø)
.../bundles/ApiBundle/EventListener/ApiSubscriber.php	51.38% <ø> (ø)
app/bundles/ApiBundle/MauticApiBundle.php	100.00% <ø> (ø)
app/bundles/ApiBundle/Model/ClientModel.php	10.63% <0.00%> (+0.43%)	⬆️
app/bundles/ApiBundle/Form/Type/ClientType.php	70.58% <65.51%> (+21.60%)	⬆️

[nickveenhof]

Other than this comment I didn't test nor review the rest. But I'm all for removing this and I love seeing the composer.json cleanup. Only thing left is FOSOAuthServerBundle. Can that potentially be tackled in the same PR?

[nickveenhof]

Consistency is key, shouldn't this be OAuth2? :)

[RCheesley]

Only thing left is FOSOAuthServerBundle. Can that potentially be tackled in the same PR?

I think we cannot do that until they merge the PR that was made to reinstate PHP template support. That is why we have the forked repo.

[nickveenhof]

Only thing left is FOSOAuthServerBundle. Can that potentially be tackled in the same PR?

I think we cannot do that until they merge the PR that was made to reinstate PHP template support. That is why we have the forked repo.

Right - although it is confusing, as the branch that is used in Mautic is not the mautic-compat branch but the dev-doctrine-fix branch. I'm not sure if that even has anything to do with the php template thing?

[nickveenhof]

FriendsOfSymfony/FOSOAuthServerBundle@master...dennisameling:doctrine-fix this is the difference afaik, not sure if it has anything to do with oauth1 or not.

[dennisameling]

Hi @nickveenhof - I rebased this PR but am getting an error on composer update --lock:

$ composer update --lock
Loading composer repositories with package information
Updating dependencies                                 
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires mautic/core-lib == 3.3.9999999.9999999-dev, it is found mautic/core-lib[3.3.x-dev] in the lock file and mautic/core-lib[dev-master] from path repo (app) but it does not match your constraint and is therefore not installable. Make sure you either fix the constraint or avoid updating this package to keep the one from the lock file.

Any suggestions?

[dennisameling]

Only thing left is FOSOAuthServerBundle. Can that potentially be tackled in the same PR?

Nope, sorry. TL;DR: we need that until the FOSOAuthServerBundle team releases a new version (which might take months), or for Mautic to fork it and maintain it ourselves.

Let's not confuse two things here:

• FriendsOfSymfony/FOSOAuthServerBundle@master...dennisameling:doctrine-fix was needed for the Symfony 4 update (specifically the Doctrine ORM dependency update) and doesn't have to do anything with PHP 8
• FOSOAuthServerBundle is working on a new major version (v2), which is currently in the alpha stage, but it's the only version that will support PHP 8. Alan asked for a v2 release timeline in 2.0 timeline and next tagged release? FriendsOfSymfony/FOSOAuthServerBundle#682 but hasn't gotten any response yet. It might take months before they get v2 ready, and there hasn't been any activity since April.

An option would be to fork FOSOAuthServerBundle 1.x in the Mautic org, try to see if it's easy to add PHP 8 support to it, then release it to Composer. Would be a workaround for the time being. But I don't have any capacity to look into that now.

[dennisameling]

The folks at Symfony also do it this way. Don't ask me why or how it works 🙈

Here's the official Composer documentation for this setting: https://getcomposer.org/doc/05-repositories.md#path

[dennisameling]

CC @nickveenhof

[RCheesley]

Checked that the dropdowns now only include OAuth2 - no more OAuth1 🎉

Was able to authenticate with OAuth2 per the instructions and was able to retrieve the contacts list!

Thanks for making this PR @dennisameling - just needs another tester and a code review from @mautic/core-team

[ts-navghane]

Reviewed and tested, LGTM! Works as expected. Thank you @dennisameling.