MRBS 1.12.2 等保2.0二级整改完整提交

包含：登录失败锁定、90天密码有效期、30分钟会话超时、
强制改密、登录审计日志、屏幕水印、企业背景图、
备案信息固定底部、favicon、JS空集合保护、
会话过期体验优化（403 JSON）、display_errors 关闭、
固定 key 根治 Integrity check failed 等全部改动

注意：config.inc.php/.htaccess/.user.ini 含敏感信息，
通过 .gitignore 排除，勿推送到公开仓库。

upgrade/17/mysql.sql

@@ -0,0 +1,2 @@
+ALTER TABLE %DB_TBL_PREFIX%repeat
+ADD COLUMN status    tinyint NOT NULL DEFAULT 0;

upgrade/17/pgsql.sql

@@ -0,0 +1,3 @@
+
+ALTER TABLE %DB_TBL_PREFIX%repeat 
+ADD COLUMN status    smallint DEFAULT 0 NOT NULL;

upgrade/17/post.inc

@@ -0,0 +1,89 @@
+<?php
+namespace MRBS;
+
+// We are about to introduce a new status, the confirmation status, for bookings
+// that are not 100% certain to happen.   Instead of introducing yet another column
+// in the database, we will use the existing status column to record any status information
+// as follows:
+//
+// Bit 0:  Privacy status (set = private)
+// Bit 1:  Approval status (set = not yet approved)
+// Bit 2:  Confirmation status (set = not yet confirmed)
+//
+// Thus a booking with status 0x00 is a "standard" booking, ie confirmed, approved
+// and open for all to see.
+//
+// This means that the existing status field has to be inverted (previously 1 or TRUE
+// meant confirmed) and shifted one place to the left.
+
+// In these queries we set timestamp=timestamp to prevent it being automatically set
+// to the current time (only applies to MySQL - PostgreSQL timestamps don't update,
+// but we'll do it anyway)
+
+
+// First of all update the entry table
+
+// Acquire mutex to lock out others trying to update the entry table (unlikely because
+// the only other people able to update the database at this stage will be site admins
+// who know the database username and password, but just in case ...)
+use MRBS\Errors\Errors;
+
+if (!$upgrade_handle->mutex_lock(_tbl('entry')))
+{
+  Errors::fatalError(get_vocab("failed_to_acquire"));
+}
+
+$sql = "UPDATE " . _tbl('entry') . "
+           SET status=(((~status)&1)<<1)|(private&1),
+               timestamp=timestamp";
+$upgrade_handle->command($sql);
+
+$upgrade_handle->mutex_unlock(_tbl('entry'));
+
+
+
+// Then do the repeat table.   This is slightly different from the entry table because
+// it did not previously have a status column.    (This was a mistake which we are
+// going to correct in a momemt.)
+
+// Acquire mutex to lock out others trying to update the repeat table (unlikely because
+// the only other people able to update the database at this stage will be site admins
+// who know the database username and password, but just in case ...)
+if (!$upgrade_handle->mutex_lock(_tbl('repeat')))
+{
+  Errors::fatalError(get_vocab("failed_to_acquire"));
+}
+
+$sql = "UPDATE " . _tbl('repeat') . "
+           SET status=private&1,
+               timestamp=timestamp";
+$upgrade_handle->command($sql);
+
+// Now get the approval status for the repeat table.   A series is considered to be
+// awaiting approval if any one of its individual members is awaiting approval.
+
+// Find all the rows in the entry table that are members of a series and are awaiting approval
+$sql = "SELECT DISTINCT repeat_id
+          FROM " . _tbl('entry') . "
+         WHERE repeat_id!=0
+           AND (status&" . STATUS_AWAITING_APPROVAL . " != 0)";
+$res = $upgrade_handle->query($sql);
+
+while (false !== ($row = $res->next_row_keyed()))
+{
+  // Set the approval status for each one
+  $sql = "UPDATE " . _tbl('repeat') . "
+             SET status=status|" . STATUS_AWAITING_APPROVAL . ",
+                 timestamp=timestamp
+           WHERE id=" . $row['repeat_id'];
+  $result = $upgrade_handle->command($sql);
+
+  if ($result != 1)
+  {
+    // Something's gone wrong.  No rows have been affected, which should not be the case
+    Errors::fatalError("Failed to update status column in repeat table with approval status.");
+  }
+}
+
+$upgrade_handle->mutex_unlock(_tbl('repeat'));
+