mpemburn

Hi Paul,

Thanks! After more testing, I discovered that my methodology was flawed. I was using a plugin that switches between users, and that doesn’t fire the WP parse_request hook that you use call the Authorization->restrict_access() method. It does work with a new login, however, so whatever problem I’m having is not with Authorizer per se.

Regards,

Mark

Hi Paul,

Thank you! I’ve installed 3.8.5 on our test instance, and it looks good so far. I’ve asked my team to give it a workout, and I’ll be monitoring New Relic to make sure no further spikes show up.

I really appreciate your help with this! Through our travails with server crashes over these past few weeks, you are the only plugin vendor out of a handful to respond quickly and appropriately.

Best regards,

Mark

Hi Paul,

Thanks, that works. I realized that I’ve used the same technique for one of my own plugins.

Sad to relate, we discovered another couple of problems with Authorizer this morning. These showed up when we attempted to create a new subsite and got fatal errors. The first of these was in class-options.php on line 45.
if ( ! array_key_exists( $option, $auth_settings ) ) {
return null;
}
…threw the error “Fatal error: Uncaught TypeError: array_key_exists(): Argument #2 ($array) must be of type array, bool given”. I changed it to this:
if ( ! is_array( $auth_settings ) || ! array_key_exists( $option, $auth_settings ) ) {
return null;
}

The second issue was in class-authorization on line 817.
$auth_settings_access_users_approved = array_merge(
$options->get( 'access_users_approved', Helper::SINGLE_CONTEXT ),
$options->get( 'access_users_approved', Helper::NETWORK_CONTEXT )
);
…threw the error: “PHP Fatal error: Uncaught TypeError: array_merge(): Argument #1 must be of type array, bool given”. I changed it to this:
$single = $options->get( 'access_users_approved', Helper::SINGLE_CONTEXT );
$network = $options->get( 'access_users_approved', Helper::NETWORK_CONTEXT );
if ( is_array( $single ) && is_array( $network ) ) {
// Get all site users and all multisite users.
$auth_settings_access_users_approved = array_merge(
$options->get( 'access_users_approved', Helper::SINGLE_CONTEXT ),
$options->get( 'access_users_approved', Helper::NETWORK_CONTEXT )
);
}

You may have a better way of doing this. If you could squeeze this into you next release, I’d be most grateful.

Mark

• This reply was modified 4 months, 3 weeks ago by mpemburn.

Thank you!

Hi Paul,

I believe I’ve found the root of the problem, and it’s very much tied to the fact the we use networks on the Clark University website. The networks organize the subsites into groups for “departments”, “offices”, “schools”, etc.

The problem occurs in Updates::auth_update_check() method when it checks for the value of auth_version for the root subsite. ?In simple multisites, this would be “1”, and it would pull the value from the wp_options table. ?This is currently 20230222, so the code that tests whether updates are needed fails, and processing fall through to the end of the method without taking any action.

In some cases, however, the auth_version check sees the root site as “3” or “5”—the IDs of the “offices” and “departments” network—and returns null, since auth_version isn’t set in wp_3_options or wp_5_options. ?Now, the code thinks that updates are needed, and it runs every one of the 20 blocks of code that test for $update_if_older_than. ?Most of this are harmless as far as we’re concerned, but the one that follows $update_if_older_than = 20221101 contains a foreach that loops over every subsite and runs the Options::set_default_options() method for each one. ?This is where the CPU usage goes through the roof and we get slow performance or, in the worst cases, crashes with fatal errors.

The fix for this is pretty simple, and I don’t think that it will adversely affect the plugin for others. If you add the following after line 34 of class-update.php, it will run the code properly for the root subsite, but bail for ones that don’t return a date value for auth_version:

if (empty($auth_version)) {
return false;
}

Can I request that you incorporate this into your next release of Authorizer?

Regards,

Mark

Hi Paul,

The HTTP 500 errors were happening on all pages, front end and back. The response time is the overall page loading time, and I track it by watching the New Relic dashboard for the site. I wanted to show you a screenshot of New Relic that illustrates what I mean but there doesn’t seem to be a way here. When I added the “return false;” to the set_default_options method, the average page load times dropped from around 7 seconds to less than a second.

This is from the New Relic “slowest transactions” list from one of our worst times:
#Authorizer\Options::set_default_options
Execution count: 969
Duration 16.16 seconds

I can only present the evidence that’s available to me, and it seems to point at this specific method call as the culprit. Let’s work together to figure this out. I’d be happy to do a Zoom call with you if that works best.

Mark

Hi Paul

I had a meeting this morning with a coworker who told me that this behavior is expected, and was dealt with (before my time) by writing a plugin that pulls in Active Directory roles for the user, then creates a custom “Content Administrator” role for them. I did not have this installed on the new site.

Seems I was barking up the wrong tree, but thanks for taking the time!

Mark

Hi Paul,

Since the website is new, we have only used it with version 3.8.1. I had a copy of 3.7.1 hanging around so I installed it on the test site. Unfortunately, it’s still zapping the Administrator role.

Details: this is a multisite, but only has one subsite at the moment. I assigned the role from the subsite’s user page, but have also done so with wp-cli: wp user add-role myuser administrator. In addition, I added the role in the Authorizer “Approved Users” list.?

Mark

Hi Paul,

Yes, we’re on version 3.8.1.

Mark

Hi Paul,

I just updated our test site to 3.7.1 and tested with “wp option get auth_version”. It’s still showing 20230222—shouldn’t this have changed to 2024[something]?

Mark

Thanks! It’s on 20230222.

Hi Paul,

Thanks. We haven’t moved to the current version of Authorizer, so no db migrations have been necessary since the last update. As far as I know, we haven’t experienced any database timeouts.

I’ll try updating to 3.7.1 next week to see if that fixes the problem.

Mark

Thanks @devmich—that was what I needed to know!

Thanks, @pkarjal—I’ll check it out!

Thanks @pkarjala

The reason we use Authorizer is to allow anyone with a Clark University email address to log in and link to these services. We also have a proprietary plugin that serves content related to the individual user. The plugin pulls the user name from the cookie, but it would be preferable to get this info from a more reliable source—such as a hook in Authorize. Is there one that could supply the user’s email address?

Mark