Plugin Conflict With other Plugins that use FireBase

[hanabadler]

Hello All

i faced an issue that the plugin returned "Algorith No supported"

i had both wpdatatables and pods plugins which use firebase jwt .

based on this discussion Tmeister/wp-api-jwt-auth#247 the solution was quite simple

i added a new class that wrap jwt classed e.g. class-jwt-wrapper.php:

namespace JWTWrapAuth\Firebase\JWT;

class JWT extends \Firebase\JWT\JWT {
}
class Key extends \Firebase\JWT\Key {
}

next, in the jwt-auth.php file i added the following line:

require __DIR__ . '/class-jwt-namespace-wrapper.php';

the last modification is on the "class-auth.php" which now need to use a different jwt class, e.g.:

 namespace JWTAuth;

 use Exception;

 use WP_Error;
 use WP_REST_Request;
 use WP_REST_Response;
 use WP_REST_Server;

-use Firebase\JWT\JWT; 
-use Firebase\JWT\Key;
+use JWTWrapAuth\Firebase\JWT\JWT;
+use JWTWrapAuth\Firebase\JWT\Key;

my 2 cent's tribute
hopefully, you decide the push and issue an update for the plugin.

[MichaelSowah]

I actually tried @hanabadler solution and it worked, @usefulteam consider adding this to their update so subsequently, the will be no conflict with other plugins.

[sun]

The problem is that other plugins are also using the JWT library and they are shipping with a different version of it.

The proposed solution does not actually resolve the problem of the Firebase\JWT library being loaded in a different version by another plugin before we are loading it.

I don't see how wrapping the classes into custom ones resolves the actual problem. The wrong code is still called.

The only real way to protect against this is to alias/remap the library's namespace into a custom one, so that PHP will actually interpret the classes as different ones and therefore loads our bundled version instead of reusing the one that has been loaded already.

I believe that is a Composer feature, but not sure what needs to be configured exactly. If I'm not mistaken, plugins like Yoast SEO or WooCommerce are doing it already.

[MichaelSowah]

@sun I was facing the same problem and implemented @hanabadler proposed solution since it was quite simple and it worked. I implemented @hanabadler solution because was quite similar to what the other conflicting plugin I was having the problem with was also proposing. For me, once it worked and others had faced and might face similar issues, I submitted my fix as a PR after talking to one of the plugin maintainers. That's just it.

[sun]

Of course. I'm just saying that we want to understand the root cause better before moving forward with a solution.

Are you perhaps able to share some simple steps to reproduce the issue? (Preferably not requiring commercial plugins)

[MichaelSowah]

Ok so I had this plugin and another plugin called pods framework, apparently, there was a disparity with the versions of firebase both plugins were using and the pods plugin was overriding this plugin's firebase.
I also reported the issue to the other plugin and they acknowledge the issue but they had not released a fix yet, I needed it so I read around and stumbled on this issue and implemented the fix here after a long discord chat with the author of JWT plugin so after reverting back to him with the fix that worked for me.

For me, the fix was easy to implement not touching too much code in the Plugin, and that is why I implemented it.

The main issue resulted from the two plugins not having the same Firebase version and in this instance, the one which was old was overriding JWT's firebase dependency upon both plugins being loaded.

[sun]

Just stumbled over the package that allows wrapping Composer dependencies into a custom namespace, so leaving this here as a potential option:
https://packagist.org/packages/coenjacobs/mozart

[marchrius]

A possible solution, as generic PHP wrapper, could be https://github.com/humbug/php-scoper
Another WP-dependent solution could be https://github.com/wpify/scoper