Personal access tokens (classic)与Fine-grained personal access tokens Beta区别

文章介绍了GitHub的PersonalAccessTokens的两种类型——经典和个人细粒度,强调了细粒度令牌在安全性和权限控制上的优势。创建细粒度令牌允许更精确的资源访问控制,并且需要定期审批,增强了安全性。同时,文章提醒用户注意令牌的使用和安全存储,以防止未授权访问。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1. 背景

在使用github自动化部署博客的环境下,遇到过错误的使用以下秘钥,导致自动构建时出现问题。
在这里插入图片描述
由此就简单认识一下,Personal access tokens (classic)与Fine-grained personal access tokens Beta的区别。

它们之间的区别

关于 personal access token

警告:将访问令牌视为密码。

若要从命令行访问 GitHub,请考虑使用 GitHub CLI 或 Git 凭据管理器,而不是创建 personal access
token。

在脚本中使用 personal access token 时,请考虑将令牌存储为机密,并通过 GitHub Actions 运行脚本。
有关详细信息,请参阅“加密机密。”还可以将令牌存储为 Codespaces 机密,并在 Codespaces 中运行脚本。
有关详细信息,请参阅“管理 codespace 的加密机密。”

如果无法使用这些选项,请考虑使用其他服务(如 1Password CLI)安全地存储令牌。
使用 GitHub API 或命令行时,可使用 Personal access token 替代密码向 GitHub 进行身份验证。 Personal access token 旨在代表你自己访问 GitHub 资源。 若要代表组织访问资源,或为长时间的集成而访问,应使用 GitHub App。 有关详细信息,请参阅“关于应用”。

GitHub 目前支持两种类型的 personal access token:fine-grained personal access token 和 personal access tokens (classic)。 GitHub 建议尽可能使用 fine-grained personal access token 而不是 personal access tokens (classic)。 与 personal access tokens (classic) 相比,Fine-grained personal access token 具有几个安全优势:

  • 每个令牌只能访问单个用户或组织拥有的资源。
  • 每个令牌只能访问特定的存储库。
  • 每个令牌都被授予特定的权限,这些权限比授予 personal access tokens (classic) 的范围提供更多的控制。
  • 每个令牌都必须具有到期日期。
  • 组织所有者可要求必须获取对可访问组织中资源的任何 fine-grained personal access token 的批准。

此外,组织所有者还可以限制 personal access token (classic) 对其组织的访问。

注意:目前,某些功能仅适用于 personal access tokens (classic):

只有 personal access tokens (classic) 对不由你或你所属的组织拥有的公共存储库具有写入访问权限。
外部协作者只能使用 personal access tokens (classic) 访问他们参与协作处理的组织存储库。 以下 API
仅支持 personal access tokens (classic)。 有关 fine-grained personal access
token 支持的 REST API 操作列表,请参阅“可用于 fine-grained personal access token
的终结点”。 GraphQL API 用于管理源导入的 REST API 用于管理 Projects (classic) 的 REST
API 用于管理 GitHub Packages 的 REST API 用于管理通知的 REST API 用于传输存储库的 REST API
用于从模板创建存储库的 REST API 用于为已通过身份验证的用户创建存储库的 REST API

作为安全预防措施,GitHub 会自动删除一年内未使用过的 personal access token。 为了提供进一步的安全性,强烈建议将过期时间添加到 personal access token。

创建 fine-grained personal access token

注意:Fine-grained personal access token 目前处于 beta 状态,且可能会更改。 若要留下反馈,请参阅反馈讨论。

1。 验证电子邮件地址(如果尚未验证)。 1. 在任何页面的右上角,单击个人资料照片,然后单击“设置”。
在这里插入图片描述

  1. 在左侧边栏中,单击“ 开发人员设置”。
  2. 在左侧栏中,在“ Personal access token”下,单击“细粒度令牌” 。
  3. 单击“生成新令牌”。
  4. 在“令牌名称”下,输入令牌的名称。
  5. 在“过期时间”下,选择令牌的过期时间。
  6. (可选)在“说明”下,添加说明来描述令牌的用途。
  7. 在“资源所有者”下,选择资源所有者。 令牌只能访问所选资源所有者拥有的资源。 除非你所属的组织选择加入 fine-grained
    personal access token,否则不会显示该组织。 有关详细信息,请参阅“为组织设置 personal access
    token 策略”。
  8. (可选)如果资源所有者是需要批准 fine-grained personal access token
    的组织,请在资源所有者下方的框中输入请求的理由。
  9. 在“存储库访问权限”下,选择希望令牌访问的存储库。 应选择满足需求的最小存储库访问权限。 令牌始终包括对 GitHub
    上所有公共存储库的只读访问权限。
  10. 如果在上一步中选择了“仅选择存储库”,则在“所选存储库”下拉列表下,选择希望令牌访问的存储库 。
  11. 在“权限”下,选择要授予令牌的权限。 根据指定的资源所有者和存储库访问权限,有存储库、组织和帐户权限这几种可能性。
    应根据需要选择最小权限。 有关每个 REST API 操作所需的权限的详细信息,请参阅“fine-grained personal
    access token 所需的权限”。
  12. 单击“生成令牌”。****

如果选择了某个组织作为资源所有者,并且该组织需要批准 fine-grained personal access token,则令牌将被标记为 pending,直到组织管理员审核为止。 令牌在得到批准之前只能读取公共资源。 如果你是组织的所有者,请求将自动获得批准。 有关详细信息,请参阅“查看和撤销组织中的 personal access token”。

附件

github官方文档:创建个人访问令牌

### 基于分层抽象机的分层强化学习 #### 概念介绍 分层强化学习(Hierarchical Reinforcement Learning, HRL)旨在通过构建多级层次结构来处理复杂任务,从而提高解决问题的能力和效率。这种技术不仅有助于缓解传统单一层面模型面临的维度灾难问题,还促进了跨领域知识迁移的可能性[^2]。 在HRL框架内,“分层抽象机”特指一种特定类型的架构设计,它利用了不同级别的抽象来表征环境动态特性以及代理行为模式。该机制允许系统在一个较高的抽象级别做出决策,并将其细化为更具体的行动计划;此同时,在较低水平上执行这些计划时可以再次应用类似的逻辑进一步细分直至达到最基础的操作单元为止[^4]。 #### 实现方法概述 对于基于分层抽象机的HRL而言,其实现有赖于以下几个核心组件: - **层次结构**:将整体目标任务细分为若干相互关联但又相对独立的小型子任务; - **时间扩展动作(Temporal Abstraction Actions)**:定义跨越较长时间跨度的行为序列作为单个复合动作,即所谓的“选项”,它们可以在任意时刻启动并持续至完成某个预设条件被满足之时; - **价值函数分解**:采用诸如MAXQ这样的算法对总回报进行拆解,以便更好地评估各阶段贡献度大小及优化路径选择策略[^1]。 此外,自动化的状态空间动作集切分也是提升性能的关键因素之一。例如,可以通过聚类分析等手段识别出潜在的任务边界点,进而据此建立合理的层级关系图谱[^3]。 #### 研究进展举例 一项值得注意的研究成果来自于Dietterich提出的MAXQ方法论,此方案创造性地提出了针对非叶节点的价值函数表达方式——即将父项收益视作其所有直系后代累积折扣报酬之和的形式加以量化。这种方法有效地解决了以往仅能依靠末端反馈调整参数所带来的局限性,使得中间管理层同样具备自我改进的机会。 另一篇重要文献则探讨了如何借助Feudal Network实现端到端训练下的高效探索机制。在此基础上所搭建起来的学习网络能够自适应地调节各级别的奖励权重分布情况,确保全局最优解得以快速收敛的同时兼顾局部细节上的精准把控[^5]。 ```python import numpy as np class HierarchicalAgent: def __init__(self): self.high_level_policy = None # 高阶政策初始化 self.low_level_policies = [] # 多个低阶政策列表 def choose_option(self, state): # 根据当前状态挑选合适的option pass def execute_primitive_action(self, action): # 执行最基本单位action pass agent = HierarchicalAgent() state = 'initial_state' chosen_option = agent.choose_option(state) if isinstance(chosen_option, str): # 如果选中的是primitive action,则直接执行 agent.execute_primitive_action(chosen_option) else: # 否则递归调用直到触及底层policy while not chosen_option.is_terminal(): sub_task_result = chosen_option.run_subtask(agent) ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值