| @@ -93,8 +93,14 @@ | ||
| 93 | 93 | // Proxy / CDN: forwarded header to trust for the visitor IP. |
| 94 | 94 | // Empty = trust only REMOTE_ADDR (the real connection, unspoofable). |
| 95 | 95 | 'trusted_proxy_header' => '', |
| 96 | 96 | |
| 97 | + // Proxy / CDN: IPs or CIDR ranges the forwarded header is accepted | |
| 98 | + // from. Empty = accept it only from your own network, and, for | |
| 99 | + // CF-Connecting-IP, Cloudflare's own ranges. Since 2.11.9, so a | |
| 100 | + // header cannot be forged by a visitor reaching the origin directly. | |
| 101 | + 'trusted_proxies' => array(), | |
| 102 | + | |
| 97 | 103 | // User-Agent management |
| 98 | 104 | 'ua_whitelist' => array(), |
| 99 | 105 | 'ua_blacklist' => array(), |
| 100 | 106 | |
| @@ -700,9 +706,12 @@ | ||
| 700 | 706 | * @since 2.10.1 |
| 701 | 707 | * @return bool |
| 702 | 708 | */ |
| 703 | 709 | public static function owns_shared_files() { |
| 704 | - return ! is_multisite() || is_main_site(); | |
| 710 | + // One wp-config.php and one root .htaccess per installation, even with | |
| 711 | + // several networks in it: is_main_site() alone is true on the main site | |
| 712 | + // of every network. Since 2.11.8, found by the audit of the network. | |
| 713 | + return ! is_multisite() || ( is_main_site() && is_main_network() ); | |
| 705 | 714 | } |
| 706 | 715 | |
| 707 | 716 | public static function can_write_shared_files() { |
| 708 | 717 | if ( ! is_multisite() ) { |
| @@ -708,9 +717,11 @@ | ||
| 708 | 717 | if ( ! is_multisite() ) { |
| 709 | 718 | return true; |
| 710 | 719 | } |
| 711 | 720 | |
| 712 | - if ( ! is_main_site() ) { | |
| 721 | + // See owns_shared_files(): the main site of a secondary network, and | |
| 722 | + // its network administrator, do not own the installation's files. | |
| 723 | + if ( ! is_main_site() || ! is_main_network() ) { | |
| 713 | 724 | return false; |
| 714 | 725 | } |
| 715 | 726 | |
| 716 | 727 | // WP-CLI with nobody logged in: there is no user to ask, and the site is |
| @@ -779,8 +790,15 @@ | ||
| 779 | 790 | * addresses that receive the alerts is another, and nobody presses a button |
| 780 | 791 | * called "restore defaults" expecting that. Both the Standard preset and the |
| 781 | 792 | * two reset buttons leave these alone. |
| 782 | 793 | * |
| 794 | + * Read from outside the plugin: the third-party network plugin Vigilante | |
| 795 | + * Network Sync calls this from its 2.0.3 to decide what NOT to copy between | |
| 796 | + * the sites of a network, so a key it does not know about is preserved per | |
| 797 | + * site instead of overwritten. Adding keys here is safe and helps it; | |
| 798 | + * renaming or removing the method, or changing the shape of what it returns, | |
| 799 | + * silently changes what that plugin replicates across a whole network. | |
| 800 | + * | |
| 783 | 801 | * @since 2.9.8 |
| 784 | 802 | * |
| 785 | 803 | * @return array<string,string[]> |
| 786 | 804 | */ |
| @@ -785,9 +803,9 @@ | ||
| 785 | 803 | * @return array<string,string[]> |
| 786 | 804 | */ |
| 787 | 805 | public static function get_user_data_keys() { |
| 788 | 806 | return array( |
| 789 | - 'firewall' => array( 'ip_whitelist', 'ip_blacklist', 'ua_whitelist', 'ua_blacklist', 'trusted_proxy_header' ), | |
| 807 | + 'firewall' => array( 'ip_whitelist', 'ip_blacklist', 'ua_whitelist', 'ua_blacklist', 'trusted_proxy_header', 'trusted_proxies' ), | |
| 790 | 808 | 'login_security' => array( 'ip_whitelist', 'custom_login_url', 'two_factor' ), |
| 791 | 809 | 'user_security' => array( 'insecure_usernames' ), |
| 792 | 810 | 'file_integrity' => array( 'excluded_paths', 'excluded_extensions' ), |
| 793 | 811 | 'email' => array( 'additional_recipients' ), |
| @@ -804,10 +822,15 @@ | ||
| 804 | 822 | * |
| 805 | 823 | * Note this is not every setting that reaches .htaccess. Blocking bad bots |
| 806 | 824 | * or empty user agents also runs in PHP, per site, so those stay editable on |
| 807 | 825 | * a subsite: the PHP half protects that site and the .htaccess half is |
| 808 | - * refused, leaving the main site's rules standing. | |
| 826 | + * refused, leaving the main site's rules standing. On the main site they | |
| 827 | + * are locked too, see get_main_site_file_settings(). | |
| 809 | 828 | * |
| 829 | + * The PHP blocks for plugins and themes have no field on the settings | |
| 830 | + * screen, but an imported file carries them, and readme.html and | |
| 831 | + * license.txt are removed from the root the whole network shares. | |
| 832 | + * | |
| 810 | 833 | * @since 2.9.8 |
| 811 | 834 | * |
| 812 | 835 | * @return array<string,true|string[]> |
| 813 | 836 | */ |
| @@ -814,13 +837,483 @@ | ||
| 814 | 837 | public static function get_shared_file_settings() { |
| 815 | 838 | return array( |
| 816 | 839 | 'security_headers' => true, |
| 817 | 840 | 'wp_hardening' => array( 'disallow_file_edit', 'disallow_file_mods', 'force_ssl_admin', 'force_ssl_login', 'wp_debug', 'disable_wp_cron' ), |
| 818 | - 'firewall' => array( 'disable_directory_browsing', 'protect_wp_config', 'protect_wp_includes', 'protect_uploads_php', 'protect_sensitive_files', 'protect_wp_cron', 'limit_http_methods' ), | |
| 841 | + 'firewall' => array( 'disable_directory_browsing', 'protect_wp_config', 'protect_wp_includes', 'protect_uploads_php', 'protect_sensitive_files', 'protect_wp_cron', 'limit_http_methods', 'block_php_in_plugins', 'block_php_in_themes' ), | |
| 842 | + 'advanced' => array( 'remove_readme', 'remove_license' ), | |
| 819 | 843 | ); |
| 820 | 844 | } |
| 821 | 845 | |
| 822 | 846 | /** |
| 847 | + * Settings the shared files are built from that also act on the site storing them | |
| 848 | + * | |
| 849 | + * get_shared_file_settings() lists what does nothing but end up in a shared | |
| 850 | + * file. These do both: blocking bad bots and bad query strings, the visitor | |
| 851 | + * IP detection and the two whitelists run in PHP for the site that stores | |
| 852 | + * them, and on the main site of a network they are also what the .htaccess | |
| 853 | + * rules of every site are generated from; the three writing module switches | |
| 854 | + * (firewall, security_headers, wp_hardening) decide whether the .htaccess | |
| 855 | + * blocks and the wp-config.php constants exist at all. | |
| 856 | + * | |
| 857 | + * Since 2.11.8 it also locks what decides whether the shared files are | |
| 858 | + * WATCHED, not built: the File Integrity module and its scan_critical_config | |
| 859 | + * switch. On the main site the critical-file scan is the network's canary | |
| 860 | + * for a change to wp-config.php or the root .htaccess, which only a network | |
| 861 | + * administrator can approve, so a main-site administrator without network | |
| 862 | + * rights must not be able to silence it by turning either one off. Closing | |
| 863 | + * the ignore list and the clear-results button in 2.11.8 left these two as | |
| 864 | + * the remaining routes; found by the audit of the admin surface. | |
| 865 | + * | |
| 866 | + * Since 3.0.0 the self-check has no setting at all, so there is nothing to lock: Vigilant's own | |
| 867 | + * files are shared by every site, and on the main site the self-check is | |
| 868 | + * the one that reports a change to them for the whole network. | |
| 869 | + * | |
| 870 | + * On a subsite all of them only act on that site, so they stay editable | |
| 871 | + * there (get_locked_file_settings() adds this set only when owns_shared_files()). | |
| 872 | + * | |
| 873 | + * Until 2.11.6 an administrator of the main site without network rights | |
| 874 | + * could change any of them, and the file-only ones too: the write to the | |
| 875 | + * file was refused at that moment, but the value stayed stored, and the | |
| 876 | + * refresh after the next update, or the next save by a network | |
| 877 | + * administrator, published it to the whole network. | |
| 878 | + * | |
| 879 | + * @since 2.11.6 | |
| 880 | + * @since 2.11.8 The file_integrity module and scan_critical_config. | |
| 881 | + * | |
| 882 | + * @return array<string,string[]> | |
| 883 | + */ | |
| 884 | + /** | |
| 885 | + * The two factor policy that governs this installation | |
| 886 | + * | |
| 887 | + * On a network the answer must not depend on which site the login happens to | |
| 888 | + * arrive at, because the cookie WordPress issues does not: COOKIEHASH comes | |
| 889 | + * from the network siteurl (wp-includes/default-constants.php) and | |
| 890 | + * COOKIE_DOMAIN covers every host of the network | |
| 891 | + * (wp-includes/ms-default-constants.php). Until 2.11.10 the settings, the | |
| 892 | + * enforced roles and the TOTP table were all read per site, so somebody | |
| 893 | + * holding the password of an administrator protected by 2FA on the main site | |
| 894 | + * posted the login to a subsite where that account has no role, was never | |
| 895 | + * asked for a code, and came out with a session valid across the network. | |
| 896 | + * Measured on the Multisite install on 12 sep 2026 (user_requires_2fa true on | |
| 897 | + * the main site, false on demo2 for the same account) and found by the | |
| 898 | + * file-by-file review of 2.11.10. | |
| 899 | + * | |
| 900 | + * So the policy of the main site governs the whole network. On a single site | |
| 901 | + * this is the site's own configuration and nothing changes. | |
| 902 | + * | |
| 903 | + * @since 2.11.10 | |
| 904 | + * | |
| 905 | + * @return array The two_factor section that applies. | |
| 906 | + */ | |
| 907 | + public static function two_factor_policy() { | |
| 908 | + $options = is_multisite() | |
| 909 | + ? get_blog_option( get_main_site_id(), self::OPTION_NAME, array() ) | |
| 910 | + : get_option( self::OPTION_NAME, array() ); | |
| 911 | + | |
| 912 | + if ( ! is_array( $options ) ) { | |
| 913 | + return array(); | |
| 914 | + } | |
| 915 | + | |
| 916 | + $login = isset( $options['login_security'] ) && is_array( $options['login_security'] ) | |
| 917 | + ? $options['login_security'] | |
| 918 | + : array(); | |
| 919 | + | |
| 920 | + return ( isset( $login['two_factor'] ) && is_array( $login['two_factor'] ) ) ? $login['two_factor'] : array(); | |
| 921 | + } | |
| 922 | + | |
| 923 | + /** | |
| 924 | + * Whether two factor is required for this account, anywhere in the network | |
| 925 | + * | |
| 926 | + * Union, and deliberately so. Reading the policy only from the main site, | |
| 927 | + * which is what this release did at first, would have switched two factor off | |
| 928 | + * for every network that has it configured per subsite, which until now was | |
| 929 | + * the only way it could be configured at all: a silent downgrade of the very | |
| 930 | + * protection being fixed. Found by the cross review of 2.11.10. So the | |
| 931 | + * question is asked of every site the account belongs to, plus the main site, | |
| 932 | + * each with its own enforced roles and exclusions, and one yes is enough. | |
| 933 | + * | |
| 934 | + * That also closes the bypass: the settings, the roles and the enrolment used | |
| 935 | + * to be read from whichever site the login arrived at, while the cookie | |
| 936 | + * WordPress issues is valid across the whole network (COOKIEHASH comes from | |
| 937 | + * the network siteurl and COOKIE_DOMAIN covers every host of it), so an | |
| 938 | + * account protected on one site could log in through another and come out | |
| 939 | + * with a session valid everywhere. | |
| 940 | + * | |
| 941 | + * @since 2.11.10 | |
| 942 | + * | |
| 943 | + * @param WP_User $user User being authenticated. | |
| 944 | + * @return bool | |
| 945 | + */ | |
| 946 | + public static function two_factor_required_for( $user ) { | |
| 947 | + return array() !== self::two_factor_demands_for( $user ); | |
| 948 | + } | |
| 949 | + | |
| 950 | + /** | |
| 951 | + * Which second factor methods this account is asked for, across the network | |
| 952 | + * | |
| 953 | + * Empty when nothing asks. On a network there can be more than one, because | |
| 954 | + * each site keeps its own settings and the requirement is the union of them. | |
| 955 | + * | |
| 956 | + * @since 2.11.10 | |
| 957 | + * | |
| 958 | + * @param WP_User $user User being authenticated. | |
| 959 | + * @return string[] Methods asked for, without repeats. | |
| 960 | + */ | |
| 961 | + public static function two_factor_methods_for( $user ) { | |
| 962 | + $methods = array(); | |
| 963 | + | |
| 964 | + foreach ( self::two_factor_demands_for( $user ) as $settings ) { | |
| 965 | + $method = isset( $settings['method'] ) ? (string) $settings['method'] : 'email'; | |
| 966 | + | |
| 967 | + // A method this version does not know is read as the default rather | |
| 968 | + // than left to fall through. Registering nothing at all is how the | |
| 969 | + // second factor of a whole network went quiet in silence: a saved | |
| 970 | + // value of '' (which validate_section() lets through on an import, | |
| 971 | + // since only the tab has an allowlist) matched neither class, so no | |
| 972 | + // filter was registered anywhere while every screen still said two | |
| 973 | + // factor was on. Found by the third cross review of 2.11.10. | |
| 974 | + $methods[] = in_array( $method, array( 'email', 'totp' ), true ) ? $method : 'email'; | |
| 975 | + } | |
| 976 | + | |
| 977 | + return array_values( array_unique( $methods ) ); | |
| 978 | + } | |
| 979 | + | |
| 980 | + /** | |
| 981 | + * Which of the two second factor classes handles this login | |
| 982 | + * | |
| 983 | + * The method cannot be read from one site's settings, and reading it from the | |
| 984 | + * main site was the hole the third cross review of 2.11.10 found: with the | |
| 985 | + * main site on totp and a subsite asking for a code by email, the class that | |
| 986 | + * registered was TOTP, the account had no enrolment, and the "not set up yet" | |
| 987 | + * branch let the login through. In 2.11.9 that same login was asked for its | |
| 988 | + * emailed code. So the question is asked per account, not per site. | |
| 989 | + * | |
| 990 | + * The order is what keeps it closed at both ends: | |
| 991 | + * | |
| 992 | + * 1. An enrolment already made wins while some site asking for a second | |
| 993 | + * factor asks for an authenticator app. It is the strongest factor the | |
| 994 | + * account has and it is ready to use, wherever in the network it was set | |
| 995 | + * up. | |
| 996 | + * 2. Otherwise, if any site asking for a second factor asks for email, email | |
| 997 | + * handles it. Email needs no enrolment, so it can never fall into the | |
| 998 | + * branch that lets a login through for lack of one. | |
| 999 | + * 3. Only when every site asking wants an authenticator app does TOTP handle | |
| 1000 | + * it, which is the case the grace period was written for. | |
| 1001 | + * | |
| 1002 | + * The condition on the first step came in 2.11.11. Without it an enrolment | |
| 1003 | + * left from a time when the site asked for an app outranked the method the | |
| 1004 | + * site asks for now: a single site set to email asked those accounts for an | |
| 1005 | + * authenticator code, which 2.11.9 never did and which locks out whoever | |
| 1006 | + * removed the app after the switch. Dropping that enrolment opens nothing, | |
| 1007 | + * because the account then goes to email, which needs no enrolment. | |
| 1008 | + * | |
| 1009 | + * @since 2.11.10 | |
| 1010 | + * @since 2.11.11 An enrolment only wins while an authenticator app is asked for. | |
| 1011 | + * | |
| 1012 | + * @param WP_User $user User being authenticated. | |
| 1013 | + * @param bool $enrolled Whether the account has a TOTP enrolment anywhere. | |
| 1014 | + * @return string 'email', 'totp', or '' when nothing asks. | |
| 1015 | + */ | |
| 1016 | + public static function two_factor_handler_for( $user, $enrolled ) { | |
| 1017 | + $methods = self::two_factor_methods_for( $user ); | |
| 1018 | + | |
| 1019 | + if ( ! $methods ) { | |
| 1020 | + return ''; | |
| 1021 | + } | |
| 1022 | + | |
| 1023 | + if ( $enrolled && in_array( 'totp', $methods, true ) ) { | |
| 1024 | + return 'totp'; | |
| 1025 | + } | |
| 1026 | + | |
| 1027 | + return in_array( 'email', $methods, true ) ? 'email' : 'totp'; | |
| 1028 | + } | |
| 1029 | + | |
| 1030 | + /** | |
| 1031 | + * The two factor settings of every site that asks this account for one | |
| 1032 | + * | |
| 1033 | + * @since 2.11.10 | |
| 1034 | + * | |
| 1035 | + * @param WP_User $user User being authenticated. | |
| 1036 | + * @return array[] The two_factor section of each site that asks. | |
| 1037 | + */ | |
| 1038 | + private static function two_factor_demands_for( $user ) { | |
| 1039 | + if ( empty( $user->ID ) ) { | |
| 1040 | + return array(); | |
| 1041 | + } | |
| 1042 | + | |
| 1043 | + if ( ! is_multisite() ) { | |
| 1044 | + $roles = ( isset( $user->roles ) && is_array( $user->roles ) ) ? $user->roles : array(); | |
| 1045 | + $policy = self::two_factor_policy(); | |
| 1046 | + | |
| 1047 | + return self::two_factor_site_requires( $policy, $user, $roles ) ? array( $policy ) : array(); | |
| 1048 | + } | |
| 1049 | + | |
| 1050 | + $demands = array(); | |
| 1051 | + $blog_ids = array( (int) get_main_site_id() ); | |
| 1052 | + | |
| 1053 | + /* | |
| 1054 | + * A super administrator is a member of almost no site (measured on the | |
| 1055 | + * Multisite install: of three sites, the network owner belongs to one), | |
| 1056 | + * yet can log in through any of them and the cookie is valid everywhere. | |
| 1057 | + * Asking only the sites they belong to left the account with the most | |
| 1058 | + * power in the network outside the policy, which is the bypass upside | |
| 1059 | + * down. So for them every site of the network is consulted. There are | |
| 1060 | + * few super administrators. It does not only run at login, though, which | |
| 1061 | + * this note claimed until 2.11.11: the dashboard hooks of the TOTP class | |
| 1062 | + * ask it on every admin screen of every site of a network, at least once | |
| 1063 | + * per hook. | |
| 1064 | + */ | |
| 1065 | + if ( is_super_admin( $user->ID ) ) { | |
| 1066 | + $blog_ids = array_merge( $blog_ids, get_sites( array( 'fields' => 'ids', 'number' => 200 ) ) ); | |
| 1067 | + } | |
| 1068 | + | |
| 1069 | + foreach ( get_blogs_of_user( $user->ID ) as $blog ) { | |
| 1070 | + if ( ! empty( $blog->userblog_id ) ) { | |
| 1071 | + $blog_ids[] = (int) $blog->userblog_id; | |
| 1072 | + } | |
| 1073 | + } | |
| 1074 | + | |
| 1075 | + foreach ( array_unique( $blog_ids ) as $blog_id ) { | |
| 1076 | + $options = get_blog_option( $blog_id, self::OPTION_NAME, array() ); | |
| 1077 | + | |
| 1078 | + if ( ! is_array( $options ) || empty( $options['login_security']['two_factor'] ) ) { | |
| 1079 | + continue; | |
| 1080 | + } | |
| 1081 | + | |
| 1082 | + /* | |
| 1083 | + * A site whose Login Security module is off asks for nothing, and | |
| 1084 | + * reading only the sub-setting made it ask anyway: a subsite that had | |
| 1085 | + * switched the whole module off, leaving an orphan two_factor.enabled | |
| 1086 | + * behind, imposed a second factor on every account of the network, | |
| 1087 | + * with no screen anywhere explaining why. It is the two-level toggle | |
| 1088 | + * trap of this plugin read upside down. Found by the third cross | |
| 1089 | + * review of 2.11.10. | |
| 1090 | + */ | |
| 1091 | + if ( empty( $options['modules']['login_security'] ) ) { | |
| 1092 | + continue; | |
| 1093 | + } | |
| 1094 | + | |
| 1095 | + $elsewhere = new WP_User( $user->ID ); | |
| 1096 | + $elsewhere->for_site( $blog_id ); | |
| 1097 | + | |
| 1098 | + // A super administrator can hold no role row anywhere, and is judged | |
| 1099 | + // as an administrator so the strictest policy of the network reaches | |
| 1100 | + // the account with the most power in it. | |
| 1101 | + $roles = ( isset( $elsewhere->roles ) && is_array( $elsewhere->roles ) && $elsewhere->roles ) | |
| 1102 | + ? $elsewhere->roles | |
| 1103 | + : ( is_super_admin( $user->ID ) ? array( 'administrator' ) : array() ); | |
| 1104 | + | |
| 1105 | + if ( self::two_factor_site_requires( $options['login_security']['two_factor'], $user, $roles ) ) { | |
| 1106 | + $demands[] = $options['login_security']['two_factor']; | |
| 1107 | + } | |
| 1108 | + } | |
| 1109 | + | |
| 1110 | + return $demands; | |
| 1111 | + } | |
| 1112 | + | |
| 1113 | + /** | |
| 1114 | + * Whether one site's two factor settings cover this account | |
| 1115 | + * | |
| 1116 | + * @since 2.11.10 | |
| 1117 | + * | |
| 1118 | + * @param array $settings The two_factor section of one site. | |
| 1119 | + * @param WP_User $user User being authenticated. | |
| 1120 | + * @param string[] $roles Roles the account holds on that site. | |
| 1121 | + * @return bool | |
| 1122 | + */ | |
| 1123 | + private static function two_factor_site_requires( $settings, $user, $roles ) { | |
| 1124 | + if ( ! is_array( $settings ) || empty( $settings['enabled'] ) ) { | |
| 1125 | + return false; | |
| 1126 | + } | |
| 1127 | + | |
| 1128 | + $excluded = isset( $settings['excluded_users'] ) ? array_map( 'absint', (array) $settings['excluded_users'] ) : array(); | |
| 1129 | + | |
| 1130 | + if ( in_array( (int) $user->ID, $excluded, true ) ) { | |
| 1131 | + return false; | |
| 1132 | + } | |
| 1133 | + | |
| 1134 | + $enforced = isset( $settings['enforced_roles'] ) ? (array) $settings['enforced_roles'] : array( 'administrator', 'editor' ); | |
| 1135 | + | |
| 1136 | + return (bool) array_intersect( (array) $roles, $enforced ); | |
| 1137 | + } | |
| 1138 | + | |
| 1139 | + /** | |
| 1140 | + * Settings that only a network administrator may change on the main site | |
| 1141 | + * | |
| 1142 | + * @return array<string,string[]> | |
| 1143 | + */ | |
| 1144 | + public static function get_main_site_file_settings() { | |
| 1145 | + return array( | |
| 1146 | + 'modules' => array( 'firewall', 'security_headers', 'wp_hardening', 'file_integrity' ), | |
| 1147 | + // trusted_proxies goes with trusted_proxy_header, and leaving it out | |
| 1148 | + // was a hole: the header decides which address the firewall of the | |
| 1149 | + // whole installation acts on, and this list decides which peers may | |
| 1150 | + // set that header. An administrator of the main site without network | |
| 1151 | + // rights who could edit only this half turned every visitor into a | |
| 1152 | + // trusted proxy. Found by the file-by-file review of 2.11.10. | |
| 1153 | + 'firewall' => array( 'block_bad_bots', 'block_bad_query_strings', 'trusted_proxy_header', 'trusted_proxies', 'ip_whitelist', 'ua_whitelist' ), | |
| 1154 | + 'file_integrity' => array( 'scan_critical_config' ), | |
| 1155 | + ); | |
| 1156 | + } | |
| 1157 | + | |
| 1158 | + /** | |
| 1159 | + * Shared file settings the current user may not change on this site | |
| 1160 | + * | |
| 1161 | + * Empty when the user can write the shared files. Otherwise the file-only | |
| 1162 | + * settings on every site, plus, on the main site, the ones it also builds | |
| 1163 | + * the shared files from. | |
| 1164 | + * | |
| 1165 | + * @since 2.11.6 | |
| 1166 | + * | |
| 1167 | + * @return array<string,true|string[]> | |
| 1168 | + */ | |
| 1169 | + public static function get_locked_file_settings() { | |
| 1170 | + if ( self::can_write_shared_files() ) { | |
| 1171 | + return array(); | |
| 1172 | + } | |
| 1173 | + | |
| 1174 | + $locked = self::get_shared_file_settings(); | |
| 1175 | + | |
| 1176 | + if ( self::owns_shared_files() ) { | |
| 1177 | + foreach ( self::get_main_site_file_settings() as $section => $keys ) { | |
| 1178 | + if ( ! isset( $locked[ $section ] ) ) { | |
| 1179 | + $locked[ $section ] = $keys; | |
| 1180 | + } elseif ( is_array( $locked[ $section ] ) ) { | |
| 1181 | + $locked[ $section ] = array_values( array_unique( array_merge( $locked[ $section ], $keys ) ) ); | |
| 1182 | + } | |
| 1183 | + } | |
| 1184 | + } | |
| 1185 | + | |
| 1186 | + return $locked; | |
| 1187 | + } | |
| 1188 | + | |
| 1189 | + /** | |
| 1190 | + * Put back the stored value of every shared file setting the user may not change | |
| 1191 | + * | |
| 1192 | + * For every writer of the whole configuration: saving a tab, importing a | |
| 1193 | + * file, applying a preset, restoring the defaults. Hiding a field on the | |
| 1194 | + * screen decides nothing, because the request can carry the key anyway. A | |
| 1195 | + * key that was not stored is dropped, so its default keeps applying. | |
| 1196 | + * | |
| 1197 | + * @since 2.11.6 | |
| 1198 | + * | |
| 1199 | + * @param array $options Configuration about to be stored. | |
| 1200 | + * @param array $stored Configuration stored now, as read from the option. | |
| 1201 | + * @return array | |
| 1202 | + */ | |
| 1203 | + public static function keep_locked_file_settings( $options, $stored ) { | |
| 1204 | + $options = is_array( $options ) ? $options : array(); | |
| 1205 | + $stored = is_array( $stored ) ? $stored : array(); | |
| 1206 | + $locked = self::get_locked_file_settings(); | |
| 1207 | + | |
| 1208 | + if ( ! $locked ) { | |
| 1209 | + return $options; | |
| 1210 | + } | |
| 1211 | + | |
| 1212 | + /* | |
| 1213 | + * A key that was never stored takes its default, which is what it was | |
| 1214 | + * worth before. Until 2.11.8 it was dropped instead, and the sanitize | |
| 1215 | + * callback of the option filled it in again, but validate_options() | |
| 1216 | + * fills a missing module switch with false, not with its default. | |
| 1217 | + */ | |
| 1218 | + $instance = new self(); | |
| 1219 | + $defaults = $instance->get_default_options(); | |
| 1220 | + | |
| 1221 | + foreach ( $locked as $section => $keys ) { | |
| 1222 | + if ( true === $keys ) { | |
| 1223 | + if ( array_key_exists( $section, $stored ) ) { | |
| 1224 | + $options[ $section ] = $stored[ $section ]; | |
| 1225 | + } elseif ( isset( $defaults[ $section ] ) ) { | |
| 1226 | + $options[ $section ] = $defaults[ $section ]; | |
| 1227 | + } else { | |
| 1228 | + unset( $options[ $section ] ); | |
| 1229 | + } | |
| 1230 | + continue; | |
| 1231 | + } | |
| 1232 | + | |
| 1233 | + $stored_section = ( isset( $stored[ $section ] ) && is_array( $stored[ $section ] ) ) ? $stored[ $section ] : array(); | |
| 1234 | + $default_section = ( isset( $defaults[ $section ] ) && is_array( $defaults[ $section ] ) ) ? $defaults[ $section ] : array(); | |
| 1235 | + | |
| 1236 | + foreach ( $keys as $key ) { | |
| 1237 | + if ( array_key_exists( $key, $stored_section ) ) { | |
| 1238 | + $value = $stored_section[ $key ]; | |
| 1239 | + } elseif ( array_key_exists( $key, $default_section ) ) { | |
| 1240 | + $value = $default_section[ $key ]; | |
| 1241 | + } else { | |
| 1242 | + if ( isset( $options[ $section ] ) && is_array( $options[ $section ] ) ) { | |
| 1243 | + unset( $options[ $section ][ $key ] ); | |
| 1244 | + } | |
| 1245 | + continue; | |
| 1246 | + } | |
| 1247 | + | |
| 1248 | + if ( ! isset( $options[ $section ] ) || ! is_array( $options[ $section ] ) ) { | |
| 1249 | + $options[ $section ] = array(); | |
| 1250 | + } | |
| 1251 | + $options[ $section ][ $key ] = $value; | |
| 1252 | + } | |
| 1253 | + } | |
| 1254 | + | |
| 1255 | + return $options; | |
| 1256 | + } | |
| 1257 | + | |
| 1258 | + /** | |
| 1259 | + * Take a lock kept as a row of the options table, or report that another request holds it | |
| 1260 | + * | |
| 1261 | + * add_option() cannot be a lock: it runs INSERT ... ON DUPLICATE KEY UPDATE | |
| 1262 | + * (wp-includes/option.php:1142 in WP 7.1), so two requests that both find | |
| 1263 | + * the option missing both "create" it and both believe they hold it. INSERT | |
| 1264 | + * IGNORE creates the row for exactly one of them, which is what core does in | |
| 1265 | + * WP_Upgrader::create_lock() (wp-admin/includes/class-wp-upgrader.php:1065). | |
| 1266 | + * A lock older than the timeout counts as abandoned, by a fatal error between | |
| 1267 | + * taking and releasing it, and only one request takes it over. | |
| 1268 | + * | |
| 1269 | + * @since 2.11.8 | |
| 1270 | + * | |
| 1271 | + * @param string $name Option name of the lock, in the current site's table. | |
| 1272 | + * @param int $timeout Seconds after which a held lock counts as abandoned. | |
| 1273 | + * @return bool True if this request now holds the lock. | |
| 1274 | + */ | |
| 1275 | + public static function acquire_option_lock( $name, $timeout ) { | |
| 1276 | + global $wpdb; | |
| 1277 | + | |
| 1278 | + // phpcs:ignore WordPress.DB.DirectDatabaseQuery.DirectQuery,WordPress.DB.DirectDatabaseQuery.NoCaching -- an atomic lock needs INSERT IGNORE, which the options API does not offer; same query as WP_Upgrader::create_lock(). | |
| 1279 | + if ( $wpdb->query( $wpdb->prepare( "INSERT IGNORE INTO {$wpdb->options} ( option_name, option_value, autoload ) VALUES ( %s, %s, 'no' )", $name, (string) time() ) ) ) { | |
| 1280 | + wp_cache_delete( $name, 'options' ); | |
| 1281 | + return true; | |
| 1282 | + } | |
| 1283 | + | |
| 1284 | + // phpcs:ignore WordPress.DB.DirectDatabaseQuery.DirectQuery,WordPress.DB.DirectDatabaseQuery.NoCaching -- the lock row as stored right now, not a cached copy. | |
| 1285 | + $held = $wpdb->get_var( $wpdb->prepare( "SELECT option_value FROM {$wpdb->options} WHERE option_name = %s", $name ) ); | |
| 1286 | + | |
| 1287 | + if ( null === $held || ( time() - (int) $held ) < $timeout ) { | |
| 1288 | + return false; | |
| 1289 | + } | |
| 1290 | + | |
| 1291 | + // Abandoned: the delete only matches the value that was read, and only one | |
| 1292 | + // request wins the insert that follows. | |
| 1293 | + // phpcs:ignore WordPress.DB.DirectDatabaseQuery.DirectQuery,WordPress.DB.DirectDatabaseQuery.NoCaching -- removes an abandoned lock row. | |
| 1294 | + $wpdb->query( $wpdb->prepare( "DELETE FROM {$wpdb->options} WHERE option_name = %s AND option_value = %s", $name, $held ) ); | |
| 1295 | + | |
| 1296 | + // phpcs:ignore WordPress.DB.DirectDatabaseQuery.DirectQuery,WordPress.DB.DirectDatabaseQuery.NoCaching -- same atomic insert as above. | |
| 1297 | + return (bool) $wpdb->query( $wpdb->prepare( "INSERT IGNORE INTO {$wpdb->options} ( option_name, option_value, autoload ) VALUES ( %s, %s, 'no' )", $name, (string) time() ) ); | |
| 1298 | + } | |
| 1299 | + | |
| 1300 | + /** | |
| 1301 | + * Release a lock taken with acquire_option_lock() | |
| 1302 | + * | |
| 1303 | + * @since 2.11.8 | |
| 1304 | + * | |
| 1305 | + * @param string $name Option name of the lock. | |
| 1306 | + */ | |
| 1307 | + public static function release_option_lock( $name ) { | |
| 1308 | + global $wpdb; | |
| 1309 | + | |
| 1310 | + // phpcs:ignore WordPress.DB.DirectDatabaseQuery.DirectQuery,WordPress.DB.DirectDatabaseQuery.NoCaching -- removes the row acquire_option_lock() inserted. | |
| 1311 | + $wpdb->query( $wpdb->prepare( "DELETE FROM {$wpdb->options} WHERE option_name = %s", $name ) ); | |
| 1312 | + wp_cache_delete( $name, 'options' ); | |
| 1313 | + } | |
| 1314 | + | |
| 1315 | + /** | |
| 823 | 1316 | * Put a configuration back to the defaults without deleting what the owner typed |
| 824 | 1317 | * |
| 825 | 1318 | * @since 2.9.8 |
| 826 | 1319 | * |
| @@ -1183,8 +1676,28 @@ | ||
| 1183 | 1676 | } |
| 1184 | 1677 | } |
| 1185 | 1678 | } |
| 1186 | 1679 | } |
| 1680 | + | |
| 1681 | + /* | |
| 1682 | + * The lock on the settings the shared files are built from is NOT applied | |
| 1683 | + * here, and that is a decision, not an oversight. The second cross review | |
| 1684 | + * of 2.11.10 raised that register_setting( 'vigilante_options', ... ) | |
| 1685 | + * declares this as its sanitize callback with no lock in it, so anything | |
| 1686 | + * reaching options.php with that option group would write the whole | |
| 1687 | + * option. The chain does not close: the plugin prints no settings_fields() | |
| 1688 | + * for that group anywhere, so the nonce it would need is not obtainable, | |
| 1689 | + * and the five places that do save (saving a tab, importing, a preset, | |
| 1690 | + * restoring the defaults, resetting a section) all apply | |
| 1691 | + * keep_locked_file_settings() themselves. | |
| 1692 | + * | |
| 1693 | + * Putting it here instead would be worse than the door it closes. A | |
| 1694 | + * register_setting() callback runs on EVERY update_option() of this | |
| 1695 | + * option, so it would also lock the writes with no user behind them: the | |
| 1696 | + * expiry of Under Attack restoring what it hardened, WP-CLI and cron. | |
| 1697 | + * Those are already covered by matriz-red-ajustes-compartidos.sh, which | |
| 1698 | + * is where such a change would show up as a row that stopped passing. | |
| 1699 | + */ | |
| 1187 | 1700 | |
| 1188 | 1701 | return apply_filters( 'vigilante_validate_options', $validated, $input ); |
| 1189 | 1702 | } |
| 1190 | 1703 | |
