Remote Authentication Broken?

2025-01-28 15:31:07

adminsforum@hubzilla.org

Frank Casa wrote the following post Tue, 28 Jan 2025 15:31:18 +0530

Remote Authentication Broken?

I have tried to log into several Hubzilla servers using Remote Authentication and it results in a blank screen. Is remote authentication broken?

show all 12 comments

2025-01-28 21:43:49

Der Pepe (Hubzilla) ⁂ ⚝

pepecyb@hub.hubzilla.hu

@Frank Casa

I've been digging through my connections on various hubs. I noticed that the problem I described only occurs on hubs operated by @Scott M. Stolz .

It does not depend on the Hubzilla version. Magic-Auth even worked on a channel on an 8.8 hub.

I noticed this for the first time with you, Scott.

When I open Scott's Code Journal (from the links), I see

https://hub.hubzilla.hu/chanview?amp%3Bhash=azJl5YQ3EJGTwRm9-B518HpvQOkDQ_OGKD7x7aY7MUqbRTaa7jJ69pWkAVgGKQw3WO4rn4eZxt-FPMdfwQsjPA

in the address bar for a moment, which is then

redirected to

https://hub.hubzilla.hu/magic?amp%3Brev=1&amp%3Bowa=1&amp%3Bbdest=68747470733a2f2f636f64656a6f75726e616c2e6465762f6368616e6e656c2f73636f74743f663d

and then leads to a blank page.

Even if I access your page directly via the URL (I then end up on your hub) and want to log in via ‘remote authentication’, I end up back on my hub with the blank page.

This is the case with nearly all the pages you operate. It has not happened to me with other hubs (yet).

Magic-Auth works at loves.tech!

2025-01-28 21:47:11

sk@hub.utsukta.org

@Der Pepe (Hubzilla) ⁂ ⚝ this also breaks when your channel is given admin perm from another account and you try to visit that channel from /manage and clicking on the particular 'delegated channel'

2025-01-28 22:24:34

Scott M. Stolz

scott@loves.tech

I have not tested it for all sites on the server, but enabling Apache PHP-FPM seems to solve the problem on ones I have tested.

If anyone can confirm it works for them, that would be appreciated.

2025-01-28 23:52:19

Harald Eilertsen

harald@hub.volse.no

@Scott M. Stolz I tested the link to the connections info page you posted previously, which used to fail. It worked as it should now.

Wild guess is that the reverse proxy previously filtered out the Authorization header from the HTTP request.

2025-01-29 01:38:31

Der Pepe (Hubzilla) ⁂ ⚝

pepecyb@hub.hubzilla.hu

@Scott M. Stolz Yes, it works now.

2025-01-29 03:36:51

Frank Casa

frank@frank.casa

@Scott M. Stolz Yes, it works again. Thank you.

2025-01-29 12:36:43

Scott M. Stolz

scott@loves.tech

@Harald Eilertsen We have different servers running different configurations and different software.

All new client sites wind up on their own VPS with no control panel. None of these servers were affected. But we still have many sites on a dedicated server with cPanel.

I'm not sure why, but it appears that a recent update of WHM turned off PHP-FPM on all websites in cPanel. Some sites crashed immediately, but others continued to work, except for some errors like OpenWebAuth not working.

Turning Apache PHP-FPM back on seemed to fix the issue. We are not sure why the WHM update disabled it. Apparently this isn't the first time they did this. Same thing happened four years ago.

2025-01-29 12:57:06

Harald Eilertsen

harald@hub.volse.no

@Scott M. Stolz Don't know anything about your infrastructure, but just looking at the Hubzilla code, the behaviour suggested that the Auhtorization header was missing (or incorrect.) Without having logs from both sides it's just a guess, though :)

2025-01-29 16:44:12

Scott M. Stolz

scott@loves.tech

@Harald Eilertsen I'm guessing that the different PHP configurations have different security setups. We can choose from CGI, suPHP, FastCGI Process Manager (FPM), and I think some others. FastCGI Process Manager (FPM) is the one we have always used and is the one that is set up correctly for Hubzilla. Setting it back to PHP-FPM fixed it because it restored the setup that worked before.

2025-01-29 17:43:50

Harald Eilertsen

harald@hub.volse.no

@Scott M. Stolz Regardless of stack used, it could be easier to determine the cause with a bit better error handling and logging. There's nothing that would inherently make this not work in any of the above stacks, but I can imagine that straight CGI may not forward all the headers, and that this could be the cause of this. But until we know for sure, it's just speculation anyways :)

2025-01-29 21:40:40

Scott M. Stolz

scott@loves.tech

@Harald Eilertsen These are the only issues I am seeing in the logs.

PHP Deprecated: preg_match(): Passing null to parameter #1 ($pattern) of type string is deprecated in /redacted/extend/addon/hzaddons/hilite/Text_Highlighter/Text/Highlighter.php on line 260

PHP Warning: Version warning: Imagick was compiled against ImageMagick version 1692 but version 1693 is loaded. Imagick will run but may behave surprisingly in Unknown on line 0

Is there anywhere else I need to check? I can do some testing with a test installation. But I would need to know what to look for.

2025-01-29 23:19:52 Last edited 1 month ago

Harald Eilertsen

harald@hub.volse.no

@Scott M. Stolz Currently I don't think you will get any useful logs, as the owa endpoint just silently skips all processing and returns the informative json payload {"success": false}.

I just now submitted a PR that will at least return a reason with the json message sent back to the client trying to authenticate. You should be able to see it on that end by enabling debug logging and the LOG_DATA setting in the admin settings. We should probably log something on the authenticating side too, but one step at the time.