系统操作日志设计(转载)

本文探讨了在企业管理系统中实现操作日志的目的、设计思路及具体实现方式,包括日志列表展示和日志内容查看等功能,并介绍了通过数据库设计解决日志管理问题的方法。
前言

 

我们在做企业管理系统时,有多多少少都有对数据的完整性有所要求,比如要求系统不能物理删除记录,要求添加每一条数据时都要有系统记录、或者更新某条数据都需要跟踪到变化的内容、或者删除数据时需要记录谁删除了,何时删除了,以便误删后可以通过系统的XXX功能来恢复误删的数据。

我将这种功能称为操作日志

为什么要做操作日志?

其 实上文也描述了一些,其主要目的就是跟踪到每一个用户在系统的操作行为,如对数据进行查询、新增、编辑或删除甚至是登录等行为。更进一步的理解可以说是对 用户使用系统情况的跟踪,对数据的跟踪防止数据意外删除、更改时有所记录,有所依据,以便对数据的还原,从某种程序上可以保护数据的完整性。

 

系统设计

场景

我们现在有一张表叫Employee:

IDint
Namenvarchar(50)
Gendernvarchar(2)
DateCreateddatetime
CreateUsernvarchar(50)

在aspx页面中可能会有EmployeeEdit.aspx(用来添加或更新Employee信息等操作),EmployeeList.aspx(用来查询或进行删除Employee信息等操作)

好了,现在我们要对Empoyee表操作的信息做一个系统日志,那怎么办?

也许你可以建立多一个表跟Employee表一模一样的,叫做EmployeeLog

IDint
Namenvarchar(50)
Gendernvarchar(2)
DateCreateddatetime
CreateUsernvarchar(50)
LogCreateddatetime
OperationTypeint

其中加多了一些附属的信息如LogCreated(日志添加日期)和OperationType(查询、新增、删除、更新)

此时这种情况可能大家在做用户登录日志的时候是一件很常见的事件。

但……问题来了,假如我需要对表EmployeeIncome(员工的收入情况)做日志那怎么办?

好建立多一张表叫EmployeeIncomeLog来记录员工收入情况的操作日志。

假如又需要对表FixedAsset(固定资产)进行日志记录那又怎么办?

 

好了,大家可能意识到我们这样做不但会造成表数量的增倍,而且大大的增加了工作量和开发时间,对数据库表不易管理等情况。

 

因此我们需要一个能够通过简单的配置和编写就可以完成以上功能的日志管理

数据库设计

系统日志设计

包括三个表,

LogSetting(日志设置)——用来存储配置业务表名、业务名称、主键等

LogSettingDetail(日志设置明细)——用来存储配置业务表需要记录的详细内容,如Employee表中,我们可能需要记录字段Name、Gender等信息。

LogOperation(操作日志)——用来记录用户对各种业务操作的内容情况。

 

下篇将讨论用代码如何实现日志管理的功能,下面先来几张图:

日志列表:

日志管理列表

查看日志内容:

查看日志内容

转载于:https://www.cnblogs.com/sandea/p/3293692.html

### CTFHUB 平台上的 SSRF 漏洞详情 在 CTFHUB 平台上,SSRF (Server-Side Request Forgery, 服务器端请求伪造) 是一种常见且重要的漏洞类别。该类漏洞允许攻击者通过构造特定的 URL 或参数来诱导服务器向指定目标发起 HTTP 请求。 #### 基本概念与影响范围 通常情况下,SSRF 攻击旨在使受害的应用程序作为代理去访问那些对外部网络不可见但对应用程序可见的服务资源。这些内部服务可能存储敏感数据或提供管理接口,一旦被恶意利用可能导致严重的后果[^3]。 #### 利用方式实例分析 对于某些 PHP 应用环境下的 SSRF 场景,在实际操作过程中发现了一种特殊的 payload 构造方法: ```plaintext http://challenge-80b40c7bb0f917cb.sandbox.ctfhub.com:10800/?url=http://notfound.ctfhub.com@127.0.0.1/flag.php ``` 上述 Payload 的特点在于它巧妙地运用了 `@` 符号将外部域名指向本地 IP (`127.0.0.1`) ,从而绕过了简单的黑名单过滤机制并成功触发了 SSRF 行为,最终实现了对 `/flag.php` 文件内容的非法获取[^4]。 #### 解决方案建议 针对此类问题的有效缓解措施可以从以下几个方面入手: - **输入验证加强**:严格校验用户提交的数据合法性,特别是涉及远程调用功能时要特别谨慎处理 URL 参数。 - **白名单策略实施**:仅限于信任列表内的主机名/IP 进行通信交互;同时考虑加入 DNS 缓存刷新逻辑防止缓存投毒风险。 - **协议限制应用**:避免支持过多不必要的协议(如 gopher:// 等),减少潜在威胁面。 - **防火墙配置优化**:合理设置云服务商提供的安全组规则以及 VPC 内网 ACL 控制,阻止来自公网对私有子网内资产的未授权访问尝试。 综上所述,为了有效防范 SSRF 类型的安全隐患,开发团队应当综合采取多种防护手段相结合的方式,并持续关注最新的攻防动态和技术趋势以确保系统的安全性得到保障[^2]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值