Multisite Compatibility

[pmgarman]

First attempt putting Fortress on Multisite lead to

NOTICE: PHP message: PHP Fatal error:  Uncaught mysqli_sql_exception: Table 'garman_dev_staging.wp_3_snicco_fortress_sessions' doesn't exist in /var/task/web/app/mu-plugins/snicco-fortress/vendor/snicco/better-wpdb/src/BetterWPDB.php:619

One possible fix...
Using base_prefix instead of prefix will get you global tables instead of the single subsite tables.

Example
/snicco-fortress/src/Session/SessionModule.php:142

This code...

$table_name = $GLOBALS['wpdb']->prefix . $config->getString('fortress.session.' . \Snicco\Enterprise\Fortress\Session\SessionOption::DB_TABLE_BASENAME);

becomes this code...

$table_name = $GLOBALS['wpdb']->base_prefix . $config->getString('fortress.session.' . \Snicco\Enterprise\Fortress\Session\SessionOption::DB_TABLE_BASENAME);

Looks like there are four uses of $wpdb->prefix based on a search of the code.

/snicco-fortress/src/Session/SessionModule.php:142
/snicco-fortress/src/Shared/SharedModule.php:220
/snicco-fortress/src/Auth/AuthModule.php:209
/snicco-fortress/src/FortressModule.php:121

I did test this on a non-multisite site, and it seemed to work just fine in my 2 minutes of testing..

[calvinalkan]

Multisite is best-effort support right now - meaning we don't have a dedicated multisite test suite (yet).

But this looks easy to fix, and I don't think there is much more to it.

But first of all, how would you expect this to work on a conceptual level?

Should each site have its session/totp/etc. table(s) ?

Should each site have unique fortress secrets? Or should they all use the same secrets?

What about all the WP-CLI commands? Should users be expected to always pass the --url flag?

[calvinalkan]

From Codex:

$prefix
The assigned WordPress table prefix for the site.

$base_prefix
The original prefix as defined in wp-config.php. For multi-site: Use if you want to get the prefix without the blog number appended.

I think I used $prefix for that reason, to have it MS compatible.

So what if you just run:

wp snicco/fortress shared:trigger-activation --url=subsite.com

[marktenney]

I have to use the --url: flag all the time in WP-CLI when dealing with multisite. So that's something multisite admins should expect.

[pmgarman]

WP Multisite assumes the users database is shared across all the sites, for example there is only 1 usermeta table.

1 Users table
1 User meta table

So I'd also assume that all user related tables in Fortress would follow that logic, 1 sessions table, etc.

May be different sites, but the username/database/etc is always shared. If the password is set and reset globally for the entire network regardless of domain, shouldn't the session, 2fa, etc all also be shared?

Session I could see being separate, but 2fa definitely should be defined globally not per site.

[calvinalkan]

1 Users table
1 User meta table

Yeah, I know about that.

I haven't used multisite too much in production, so I'm asking how you'd expect it to work.

I think we'd need per-table handling?

• 2FA: shared, since passwords are also shared. Passwords being shared automatically means that the same secrets must be used.
• Rate-Limits: meh, doesn't really matter.
• Sessions: Could be shared or separated, use case for separated would be logging out all users only on one site.
• Challenges: meh, it doesn't really matter, at first glance. But that would mean for example that a magic login link on site a) would work on site b)

[pmgarman]

Depending on the multisite things work differently.

Subdirectory install - all the sessions are shared anyways, login to one site, you're logged into all the sites you can access. Subdomain install or domain mapped - browsers may treat the sites differently because the domain the cookie is on may be different, so you need to login separately.

That said - I'd probably stick to anything user related is shared.

Challenges may be "shared" across subsites... making magic links work across subsites, but like I mentioned since some installs you already are logging into all the sites at once anyways... that probably is preferable.

So my vote - all of them are global based on your notes above and how I personally would expect it to work.

[calvinalkan]

So assuming we were to make the challenges table per-site, for forward-compatability.

Would we also need a root level table?

For super admins doing stuff?

[calvinalkan]

Internal reference:

We'd need to add the Super Admin to the privileged user roles.

[pmgarman]

Fortunately this can be done via the config as well, so it's not breaking that it isn't there :)

[calvinalkan]

Right, you can add it to the priviledged_user_roles option.

But I'll also add it to the baseline if we add proper MS support.

[calvinalkan]

@pmgarman

I finally got around to take a deep dive into this. Please let me know what you think.

Multisite Configuration

We need a per-site cache and log directory.

Before Fortress boots:

$fortress_var_dir = '/tmp/fortress/var';

$site_id = get_current_blog_id();

mkdir(
    $current_site_cache_dir = "$fortress_var_dir/site_$site_id/cache", 
    0755, 
    true
);

mkdir(
    $current_site_log_dir = "$fortress_var_dir/site_$site_id/log", 
    0755, 
    true
);

$_SERVER['SNICCO_FORTRESS_CACHE_DIR'] = $current_site_cache_dir
$_SERVER['SNICCO_FORTRESS_LOG_DIR'] = $current_site_log_dir

Optionally, we can use a per-site config file and a baseline config file.

// This configuration is used for all sites.
$_SERVER['SNICCO_FORTRESS_SERVER_CONFIG_FILE'] = "/path/to/config/fortress-baseline.json"

// And can be merged with configuration per-site.
// The file SNICCO_FORTRESS_SITE_CONFIG_FILE does NOT have to exist.
$site_id = get_current_blog_id();

$_SERVER['SNICCO_FORTRESS_SITE_CONFIG_FILE'] = "/path/to/config/fortress-site-$site_id.json"

Tables

All (current) tables are global.

Reasoning:

• 2FA Secrets => Global because user table and thus user passwords are global.
• Sessions => Global because user sessions on a default installation are stored in usermeta which is global.
• Rate Limits => Global because they are currently only used for auth related stuff which is all global. If site specific is needed later, we can later pass the site id as the rate limit key.
• Challenges => Same reasoning as Rate Limits.

Cookies

We only use two custom cookies currently:

• Device ID Cookie
• Remember Me Cookie

We'll mimic what WordPress does with auth cookies and use the COOKIE_DOMAIN constant to determine access level.

Config Test

Configuration should definitely be tested for ALL sites like so:

See: https://danielbachhuber.com/tip/run-wp-cli-command-wordpress-multisite/

wp site list --field=url | xargs -n1 -I % wp --url=% snicco/fortress shared config:test

CLI Commands

--url should be appended for all CLI commands as a default, especially if per-site configuration is used.

[pmgarman]

One concern I have with the per site configs is many people using multisite are not re-deploying their application or writing any additional code when they add new sites to their network. Whatever the solution is, should be able to work without any engineering intervention (code/config changes, CLI commands, etc).

What's the root need for per site directories exactly? Is it just segregation of the site data? or is it something bigger.

[calvinalkan]

@pmgarman

Per site cache is needed if per site config is used.

And per site config sounds like a very good idea in combination with a baselines ("server/MS") config.

That will definitely be needed by some. I.E you have a vault that should should only be added on one site, not all.

Per site logs just makes sense to separate the logging output of sites.

[calvinalkan]

Also, there are some config options that can probably never be used on a "network level".

Example:

{
  "vaults_and_pillars": {
    "option_vaults": {
      "some_option_that_does_not_exist_by_default": {}
    },
    "strict_option_vaults_and_pillars": true
  }
}

With strict mode turned on, if you add a new site where this option does not exist yet, it will throw an exception by fetching it.

So the configuration should be split up into:

"Server/Network" level:

{
  "vaults_and_pillars": {
    "some_option_that_does_not_exist_by_default": {
      "admin_email": {}
    }
  }
}

Site-level, on a per-need basis:

{
  "vaults_and_pillars": {
    "strict_option_vaults_and_pillars": true
  }
}

[calvinalkan]

Other considerations

Super Admins

The Super Admin role allows a user to perform all possible capabilities. Each of the other roles has a decreasing number of allowed capabilities.

Oddly, there is no role slug for super admins.

Instead, they are fetched from get_super_admins:

function get_super_admins() {
	global $super_admins;

	if ( isset( $super_admins ) ) {
		return $super_admins;
	} else {
		return get_site_option( 'site_admins', array( 'admin' ) );
	}
}

All configuration options that accept user roles will probably not work correctly with super admins.

Unless $wp_user->roles also returns "administrator" for super admins.

This is also risky from a security perspective, IMO. Any unrestricted site option update can make a subscriber a super admin.

Vaults and Pillars don't work for site options either.

So, I'd recommend adding the following code in a mu-plugin:

add_filter("pre_site_option_super_admins", fn () => ["actual_super_admin_username"], PHP_INT_MAX);

Options that accept capabilities

user_can will always return true for super admins, regardless of the capability.

That means that if any per-capability settings are used, the first setting in the array must be a capability that only super admins have, such as manage_network

Otherwise, the super admins will inherit settings for other caps.

{
  "session": {
    "idle_timeout_per_cap" : {
       "manage_network": 1800,
      "subscriber" : 10000
    }
  }
}

[calvinalkan]

Roles & Capabilities

Roles and capabilities are weird on multisite.

I created a new admin on a subsite (user ID 2).

$ wp eval "var_dump((new WP_User(2))->roles);" --url=fortress-ms-test.snicco.io
array(0) {
}

And the new user has no roles&caps on the main site - not even after adding him as a super admin.

This means, that for example password reset restrictions could be bypassed if the action is performed through the main site.

Because roles are stored in a usermeta key that depends on the blogid. Hence on the main blog all other users have no roles&caps.

I'll need to think about how this can be handled.

[calvinalkan]

Let's take this configuration as an example:

{
    "auth": {
        "require_2fa_for_roles_before_login": [
            "administrator"
        ]
    }
}

An admin can not log in without having 2FA already configured.

This would be enforced on the admin's subsite.

But not if the admin logs in on the main site (or another subsite).

I always found it weird that users can log in on any subsite, even if they are not part of that site.

[calvinalkan]

I don't think capability checks help either here.

Right now, we use this code:

UserRoles::hasAny($user, $this->roles_that_are_privileged);

And I think the only way to make this work use code like this:

private function userHasPrivilegedRole(User $user) : bool
{   
    // On current site.
    $has_role_on_current_site = UserRoles::hasAny($user, $this->privileged_roles);
    
    if(!is_multisite() || $has_role_on_current_site){
       return $has_role_on_current_site
    }
    
    $all_site_ids_of_user = array_keys(get_blogs_of_user($user->ID)));
    
    foreach ($all_site_ids_of_user as $site_id) {
        
        try {
            switch_to_blog($site_id);
            
            if(UserRoles::hasAny($user, $this->privileged_roles)){
                return true;
            }
            
        }
        finally {
            restore_current_blog();
        }
        
    }
        
    return false;
}

[calvinalkan]

@pmgarman @marktenney

Initial "it will not blow up support" is released on beta.27

I've spun up a subdomain MS and have not had any problems from a functionality perspective.

What's unclear/undecided still is mainly related to cross-site access.

Stuff like:

• Should user_site1 be able to log in on site2 - Important for functionality like enforcing 2FA (registration) and pre-login 2FA requirements.
• Should auth cookies be cross-domain for all users, some users, or no users (except super admin, maybe).
• Determining capabilities and roles if a user accesses a different site where he's not assigned - Relevant for PW reset restrictions, session timeouts, etc. Many timeouts can be customized per capability. If an admin on site1 goes to site2 to log in, his session timeout is way longer than it should be, because at site2, he's not an admin.
• etc.

This are not mainly code related questions but more so "What is the expected behaviour here"

[calvinalkan]

Application permission checks (2FA edit for another user currently) have been changed from "manage_options" to "edit_user" which is more logical and also MS compatible.