JFrog Artifactoryx文档
要获得最新版本，请访问JFrog统一平台
跳到元数据的末尾
进入元数据的开始
概述
其中一些设置对于本地、远程和虚拟存储库是通用的。这些在基本设置对应的TAB新增/编辑屏幕下方一般部分。根据为存储库指定的包类型，可以在特定于类型的部分中找到其他设置。
常用基本设置
页面内容
包类型 |
的包类型必须在创建存储库时指定，一旦设置，就不能更改。 |
库的关键 |
Repository Key是存储库的强制标识符，在Artifactory实例中必须是唯一的。不能以数字开头，也不能包含空格或特殊字符。对于本地存储库，我们建议使用“-local”后缀(例如:“libs-release-local”)。 |
仓库布局 |
设置存储库用于存储和标识模块的布局。Artifactory将建议与所定义的包类型相对应的布局，并将上传的包编入索引，并相应地计算元数据。 |
公共描述 |
描述存储库内容和用途的自由文本字段。 |
内部描述 |
一个自由文本字段，用于添加关于存储库的其他注释。这些仅对Artifactory管理员可见。 |
包括和排除模式 |
的包括模式和排除模式当试图解析不同工件的位置时，字段提供了一种过滤特定存储库的方法。 在每个字段中，您可以指定一个类似ant的模式列表来过滤和过滤工件查询。过滤的工作原理是从包含的模式(默认为全部)中减去排除的模式(默认为none)。 例子： 考虑一个存储库的包含模式和排除模式如下: 包含模式:org/apache/**，com/acme/**排除模式:com/acme/exp-project/** 在这种情况下，Artifactory将在存储库中搜索 |
JFrog x射线集成 |
如果Artifactory连接到Xray的实例，则指示存储库是否为分析建立了索引。 |
使用排除模式避免安全风险
本节解释如何使用排除模式来避免以下安全风险。
使用排除模式防止内部构件的暴露
您部署到Artifactory的任何专有构件都存储在本地存储库中，以便它们可以用于安全的和授权的内部使用。
任何通过名称搜索内部工件的人都将通过Artifactory从本地存储库中提取它。
但是，考虑一下，如果对内部工件的请求被不经意地指向，会发生什么外组织的。
关于这种情况的两个例子是:
- 在请求的工件名称中有一个简单的拼写错误
- 开发人员请求一个版本号不存在的快照。
在这种情况下，由于Artifactory没有在本地存储库中找到所请求的工件，它将继续搜索系统中定义的远程存储库。事实上，Artifactory会搜索所有在返回“Not found”之前，在系统中定义的远程存储库。
这带来了安全风险，因为对远程存储库发出的任何请求都可能被记录下来公开查询的所有细节，包括可能包含敏感业务信息的完整工件名称．
为远程存储库使用排除模式以避免安全风险的最佳实践
为避免暴露上述敏感业务信息，我们强烈建议采用以下最佳实践:
- 组织中使用的远程存储库列表应该在一个虚拟存储库下管理，所有请求都指向该虚拟存储库
- 中的所有内部构件都应指定排除模式字段的虚拟存储库(或者每一个远程存储库)使用通配符封装尽可能广泛的内部构件规范。
使用排除模式防止暴露内部包
代理不受信任的公共远程存储库或受到损害的存储库可能会使您暴露于恶意构件。有时，这些存储库允许任何人部署自定义包。例如，对于npm，公共存储库为npmjs，任何人都可以部署他/她拥有的任何包的任何版本。如果一个包没有所有者(以前没有人部署过它的某个版本)，任何人都可以部署它并认领它。
例如，让我们假设您有一个名为“almo-common-utils”它的源代码是公共可访问的，例如，如果它被绑定为公共可访问的产品或web应用程序的一部分，它是在Node和JFrog Artifactory中编写的，它有一组远程(代理公共存储库)，本地(用于内部共享模块)hth华体会最新官方网站和虚拟存储库。
考虑以下几点:
- 在公共存储库中，任何人都可以发布一个非作用域库，并将其命名为任何他们想要的名称。
almo-common-utils”(除非名称冲突)。 - 没有名为"
almo-common-utils＂在公共存储库中(因为它是一个内部公司库)，因此不存在名称冲突。 - 您有项目声明依赖在“
almo-common-utils“使用版本范围。例如，指定与主要版本兼容的最新版本的范围。
这就带来了安全风险，因为攻击者可以通过预先了解库来攻击未受保护的组织。”almo-common-utils \”，正在使用的库的主要版本(假设他们知道版本3在组织中广泛使用)，以及源代码的内容。
攻击者可以克隆和修改源代码，在其中嵌入任何恶意软件，但仍然保持与原始代码的兼容性，并将其上传到存储库作为“almo-common-utils: 3.99.99”．这将创建一个内部库的版本更新劫持，当“almo-common-utils: ^ 3.0.0“是要求的，是假的”almo-common-utils从存储库中获取。
为了避免暴露内部包和内部包版本劫持，我们强烈建议采用以下方法：
- 在远程存储库上使用排除模式。在远程存储库中排除您不想在组织之外搜索的包。您可以通过前缀(来排除。
.npm / almo * / * *)，按范围(.npm / @almo / *)或按姓名(.npm / almo-encoder / * *)．通过在任何公共远程存储库上设置这些排除模式，您实际上不会从公共存储库合并这些包。 - 只创建和发布有作用域的包。在公共存储库中为您的公司注册一个官方组织，以拥有您的组织的范围，并且始终只发布有范围的包。这也简化了排除模式，因为您只需要排除作用域包在远程存储库中排除正在搜索的所有包。
下面是一个阻塞包的示例范围"almo”从远程存储库。
使用Include模式避免性能问题
在典型场景中，Artifactory将引用大型通用存储库，例如JCenter或者Maven Central来解析工件。
此外，Artifactory可以引用任意数量的附加存储库，这些存储库可以承载更专门化和特定的工件集。
如果Artifactory接收到对一组确定的工件(例如，工件的特定版本)的请求，那么它将根据其解析顺序在不同的存储库中搜索，直到找到该工件。
然而，如果Artifactory接收到对一组不确定工件的请求(例如，的所有版本maven-metadata.xml)然后它必须搜索所有直到它能够提供完整的响应为止。
在大多数情况下，组织下载的大部分工件将来自一个大型的通用存储库，但是是在不确定的请求中性能下降，因为Artifactory继续搜索所有专门的存储库才能返回响应．
为远程存储库使用包含模式以避免不必要和浪费的搜索的最佳实践
为了避免在响应不确定请求时执行不必要和浪费的搜索，我们强烈建议所有专门的存储库都配置适当的包括模式只指定组织可能需要的工件集。
在这种情况下，通常在通用存储库中找到的工件的非确定性请求将跳过专用存储库，从而提高性能。
本地和远程存储库
除了上述设置外，本地和远程存储库还在特定于类型的部分中为相关包类型共享以下设置。
最大快照唯一性 |
指定应该存储的同一工件的惟一快照的最大数量。一旦达到这个数量并上传一个新快照，则会自动删除存储时间最早的快照。 空白(默认值)表示不限制快照的唯一性。 |
处理版本 |
如果设置了，Artifactory允许您将版本构件部署到这个存储库中。 |
处理快照 |
如果设置了，Artifactory允许您将快照构件部署到这个存储库中。 |
概述
内容的工具