During development, we often use code written by others, assuming it will function as intended. Yet, even when the third-party software comes from a reliable source, it’s never a guarantee that their code is bug-free.
Recently my team was developing a service extension for Maverics Orchestrator and came across an interesting bug. We had a WordPress server that had to authenticate users via a miniOrange plugin (JWT Login SSO). The plugin accepts a JWT from either the Request URL Parameter, Cookie, or Header. Everything was working fine when we passed the JWT in a query string, but when we made the switch to Headers, authentication never happened, no errors, no logs, nothing.
At this point, we are still convinced it was an issue on our end, so we double checked our code, made sure we used the correct signing keys, switched back to a sandbox WordPress environment to make sure it wasn’t the load balancer stripping headers. Still, the problem persists.
We looked further into the miniOrange setup guide to confirm it was not a configuration issue. Interestingly, header authentication wasn’t even an option in their documentation.
After some back and forth with miniOrange support, we scheduled a session to troubleshoot the issue. To confirm the JWT token was received by the plugin, we added error logs to print out a few variables in their JWTFlowHandler:
Then, we looked into class-jwtlogin.php to investigate what went wrong with the login handler:
Apparently, they never checked if request header is enabled or not, instead, the code block get_jwt_from_url() is used to handle jwt from headers.
To test this theory, we only enabled request URL parameter in the admin console:
We passed the JWT through the request header and was able to authenticate to WordPress.
The next day, miniOrange came back with a bug fix and the check boxes are working as intended.
Note that the patched plugin still has the same version number as the old one.
