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