Files
人事系统开发 1ba6efd8ed 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 排除,勿推送到公开仓库。
2026-09-09 16:55:02 +08:00

90 lines
3.2 KiB
PHP

<?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'));