技术周总结 2024.07.29 ~ 08.04周日(MyBatis, 极限编程)

一、08.01 周四

1.1）mybatis的 xml文件中的 ${var} 和 #{var}的区别？

在MyBatis的XML文件中，${}和#{}都用于传递参数给SQL语句，但有一些区别：

1. ${}是直接替换变量的值，相当于拼接字符串，存在SQL注入的风险。在使用${}时，变量值会直接替换SQL语句中的对应位置，不会进行预编译处理，因此不安全。
2. #{}是使用预编译处理，会将传入的参数按照参数类型进行处理，可以防止SQL注入。在使用#{}时，MyBatis会将传入的参数进行预编译处理，将参数值放入占位符中，再执行SQL语句，可以提高性能和安全性。

因此，推荐在MyBatis的XML文件中使用#{}来传递参数，以提高安全性和性能。

二、08.03 周六

2.1）极限编程

极限编程（Extreme Programming，XP）是一种敏捷软件开发方法，旨在提高软件质量并响应不断变化的客户需求。由Kent Beck在1996年提出，极限编程通过强调团队协作、持续反馈、客户参与和快速交付来实现这些目标。

核心价值观

极限编程基于五个核心价值观：

1. 沟通：鼓励团队成员之间的频繁和开放的沟通，以确保每个人都在同一页面上。
2. 简单：专注于简单的解决方案，避免过度设计和复杂性。
3. 反馈：通过客户反馈、测试和持续集成获得快速反馈，以便及时调整和改进。
4. 勇气：鼓励团队成员敢于面对和解决问题，敢于重构代码，敢于放弃不合适的方案。
5. 尊重：团队成员之间相互尊重，理解并支持彼此的工作和决策。

核心实践

极限编程包含了一系列核心实践，这些实践相互支持和强化，以确保开发过程高效且高质量。以下是极限编程的主要实践：

1. 持续集成：频繁地将代码集成到主干中，并进行自动化测试，以确保每次集成都不会破坏现有功能。
2. 测试驱动开发（TDD）：在编写功能代码之前先编写测试代码，确保每个功能都有对应的测试覆盖。
3. 结对编程：两名程序员共同工作在一个工作站上，一人编写代码，另一人进行审查和建议，以提高代码质量和知识共享。
4. 简单设计：保持代码设计简单，只实现当前需要的功能，避免未来的扩展性考虑。
5. 重构：持续改进代码结构，使其更易于理解和维护。
6. 小发布：频繁发布小版本的软件，确保客户可以快速获得新功能和改进。
7. 客户在场：客户代表与开发团队一起工作，随时提供需求和反馈，确保产品符合客户期望。
8. 40小时工作周：避免加班，保持工作与生活的平衡，确保团队成员的长期生产力和幸福感。
9. 编码标准：团队遵循一致的编码标准，使代码更易于理解和维护。

实施极限编程的好处

1. 提高软件质量：通过TDD、结对编程和持续集成等实践，极限编程可以显著提高软件的质量。
2. 更快的交付：小发布和客户在场等实践确保团队能够快速响应客户需求，并频繁交付功能。
3. 减少风险：持续反馈和测试使得问题可以在早期被发现和解决，减少了项目失败的风险。
4. 增强团队协作：极限编程强调沟通、结对编程和尊重，促进了团队成员之间的协作和知识共享。

极限编程的挑战

1. 需要客户的高参与度：客户需要能够持续参与开发过程，并随时提供反馈和需求，这在某些情况下可能是一个挑战。
2. 团队成员的适应性：一些团队成员可能不习惯频繁的沟通和结对编程，需要时间来适应这种工作方式。
3. 对实践的严格遵守：极限编程的成功依赖于对其核心实践的严格遵守，任何偏离都可能影响其效果。

适用场景

极限编程适用于那些需求变动频繁、需要快速响应客户需求和高质量交付的软件项目。特别适合小型团队和需要快速迭代开发的项目。

通过实施极限编程，团队可以在不断变化的环境中保持高效和高质量的开发过程，最终交付符合客户需求的高质量软件产品。

三、08.04 周日

3.1）《计算机信息系统安全保护等级划分准则》把计算机信息安全划分为的5个等级要怎么理解？请举例说明

《计算机信息系统安全保护等级划分准则》（GB 17859—1999）是中国国家信息安全标准之一，它将计算机信息系统的安全保护能力划分为五个等级。每个等级都对应着不同级别的保护要求，从低到高依次为：

1. 用户自主保护级 (第一级)
2. 系统审计保护级 (第二级)
3. 安全标记保护级 (第三级)
4. 结构化保护级 (第四级)
5. 访问验证保护级 (第五级)

下面是对这五个等级的简要解释以及示例：

1. 用户自主保护级 (第一级)

• 定义: 在这个级别，用户对自己的数据和资源具有完全的控制权。系统提供了基本的安全功能，比如用户标识和认证。
• 示例: 家庭电脑安装的操作系统，用户可以设置自己的用户名和密码，但没有更多的安全措施来防止未经授权的访问。

2. 系统审计保护级 (第二级)

• 定义: 在这个级别上，除了基本的用户标识和认证之外，还增加了审计功能，能够记录重要的安全事件。
• 示例: 企业内部使用的服务器系统，管理员可以查看登录失败的日志，以便追踪潜在的安全威胁。

3. 安全标记保护级 (第三级)

• 定义: 这个级别增加了对数据和资源的标记，以确保只有经过授权的用户才能访问特定的数据和资源。
• 示例: 政府部门使用的内部网络，文件可能带有不同的安全级别标签，例如“机密”、“秘密”，只有拥有相应权限的人员才能访问这些文件。

4. 结构化保护级 (第四级)

• 定义: 在这个级别，系统的设计和实施遵循了严格的结构化安全策略模型。系统可以对用户和资源之间的交互进行细粒度的控制。
• 示例: 高安全性的军事或金融系统，其中的访问控制非常严格，确保只有经过认证的实体才能进行特定的操作。

5. 访问验证保护级 (第五级)

• 定义: 这是最高的安全级别，它要求系统实现形式化的安全策略模型和严格的数学证明，确保系统按照安全策略运行。
• 示例: 涉及到国家安全的关键基础设施，如国防系统，其中的数据处理和访问控制经过严密设计和验证，以防止任何形式的未授权访问。

这些等级的划分主要是为了指导不同领域和组织根据其业务需求选择合适的安全保护措施。随着等级的提高，系统的安全性也随之增强，但同时也意味着更高的成本和技术复杂性。因此，在实际应用中，组织通常会根据自身的实际情况和需求选择适当的安全等级。

3.2）基于任务的访问控制(TBAC)模型的组成部分

基于任务的访问控制 (Task-Based Access Control, TBAC) 的另一种描述确实提到了工作流、授权结构体、受托人集、许可集这几个组成部分。这种描述方式是从一个更具体的角度来解释 TBAC 的工作原理。下面是这些组成部分的解释：

1. 工作流 (Workflow)

• 定义：工作流是指一系列按照预定顺序执行的任务集合，它定义了业务过程中的各个步骤以及这些步骤之间的依赖关系。
• 作用：工作流描述了业务流程如何从开始到结束的整个过程，包括任务的执行顺序、条件分支等。
• 示例：在一个审批流程中，工作流可以定义为“提交申请”->“部门经理审批”->“财务审核”->“最终批准”。

2. 授权结构体 (Authorization Structure)

• 定义：授权结构体定义了任务和角色之间的关系，即哪些角色可以执行哪些任务。
• 作用：授权结构体是 TBAC 的核心，它决定了用户根据其角色可以执行哪些任务。
• 示例：在上述审批流程中，“部门经理审批”任务可能仅授权给“部门经理”角色。

3. 受托人集 (Trustee Set)

• 定义：受托人集是指一组被授权执行特定任务的用户或角色。
• 作用：受托人集定义了哪些用户或角色可以执行工作流中的特定任务。
• 示例：对于“财务审核”任务，受托人集可能是财务部门的所有成员。

4. 许可集 (Permission Set)

• 定义：许可集是一组与任务相关的权限，这些权限定义了在执行任务时可以进行的操作。
• 作用：许可集定义了执行特定任务时用户可以访问的资源或执行的操作。
• 示例：对于“最终批准”任务，许可集可能包括“查看所有文档”和“批准/拒绝请求”。

综合理解

综合以上四个组成部分，我们可以这样理解 TBAC：

• 工作流 描述了业务过程的顺序和逻辑，定义了任务的执行顺序。
• 授权结构体 定义了哪些角色可以执行哪些任务。
• 受托人集 指的是实际执行任务的用户或角色集合。
• 许可集 规定了执行特定任务时用户可以执行的操作或访问的资源。

示例说明

假设有一个医院信息系统，其中涉及的工作流、授权结构体、受托人集和许可集如下：

• 工作流:

  • 提交处方 -> 医生审批 -> 药房配药 -> 发放药品

• 授权结构体:

  • “提交处方”任务授权给“医生”角色。
  • “医生审批”任务授权给“医生”角色。
  • “药房配药”任务授权给“药剂师”角色。
  • “发放药品”任务授权给“药房工作人员”角色。

• 受托人集:

  • “医生审批”任务的受托人集是所有具有“医生”角色的用户。
  • “药房配药”任务的受托人集是所有具有“药剂师”角色的用户。

• 许可集:

  • “医生审批”任务的许可集可能包括“查看处方详情”和“批准/拒绝处方”。
  • “药房配药”任务的许可集可能包括“查看处方详情”和“准备药品”。

通过这种方式，TBAC 模型确保了只有适当的用户或角色可以执行特定的任务，并且在执行这些任务时只能进行被许可的操作。这种模型非常适合于需要根据业务流程动态调整权限的场景。

3.3) git clone时报错： Permission denied (keyboard-interactive,publickey).fatal: Could not read from remote repository.

当您尝试使用 git clone 命令克隆仓库时遇到 Permission denied (keyboard-interactive,publickey) 错误，这通常表明您没有足够的权限访问远程仓库。这个问题可以通过几种不同的方法解决：

1. 检查 SSH 密钥

• 确认 SSH 密钥已添加到远程仓库：确保您的 SSH 公钥已添加到目标 Git 仓库的服务提供商（如 GitHub、GitLab 或 Bitbucket）中。
• 生成 SSH 密钥：如果还没有生成 SSH 密钥，可以使用以下命令生成一个新的 SSH 密钥对：

  ssh-keygen -t ed25519 -C "your_email@example.com"
  

• 添加 SSH 密钥：将生成的公钥添加到远程仓库的服务提供商中。

2. 使用 HTTPS 协议

• 使用 HTTPS 克隆仓库：如果使用 SSH 方式仍然出现问题，可以考虑使用 HTTPS 协议。使用 HTTPS 需要输入用户名和密码。

  git clone https://username@github.com/user/repo.git
  

3. 配置 SSH Agent

• 启动 SSH Agent：确保 SSH Agent 正在运行，并将私钥添加到 SSH Agent 中。

  eval "$(ssh-agent -s)"
  ssh-add ~/.ssh/id_ed25519
  

  其中 ~/.ssh/id_ed25519 是您的私钥文件路径。

4. 配置 Git

• 检查 Git 配置：确保 Git 的配置正确。您可以使用以下命令查看当前的 Git 配置：

  git config --list
  

5. 检查远程仓库 URL

• 确认远程仓库 URL 正确：确保您使用的远程仓库 URL 是正确的，并且与您的账户相关联。

6. 使用正确的 Git 凭证助手

• 配置 Git 凭证助手：如果您使用的是 HTTPS 协议，确保您配置了正确的 Git 凭证助手。

  git config --global credential.helper store
  

7. 检查防火墙和网络配置

• 检查防火墙和网络配置：确保防火墙或网络配置没有阻止 SSH 或 HTTPS 连接。

8. 重新生成 SSH 密钥

• 重新生成 SSH 密钥：如果之前的 SSH 密钥有问题，可以尝试删除旧的密钥并重新生成一对新的 SSH 密钥。

9. 检查用户名和仓库名称

• 确认用户名和仓库名称正确：确保您提供的用户名和仓库名称是正确的。

10. 联系服务提供商

• 联系服务提供商：如果以上方法都无法解决问题，可能需要联系 Git 仓库的服务提供商寻求帮助。

根据您的具体情况，您可以尝试上述方法中的一个或几个来解决问题。如果您能提供更多关于您的环境的信息（例如您是在哪个平台上操作，您是否已经设置了 SSH 密钥等），我可以为您提供更具体的指导。