4 个版本 (2 个重大变更)

0.8.0	2022 年 5 月 9 日
0.7.0	2021 年 9 月 10 日
0.6.3	2021 年 9 月 1 日
0.6.2	2021 年 9 月 1 日

#3 in #niftygate

MIT 许可证

13KB
215 行

niftygate - 通过 NFT 所有权实现嵌入式访问控制

简介

使用任何智能合约，部署在任何区块链上，无需修改代码，即可访问任何网络上的任何内容。

概述

如果你把代币比作进入俱乐部的门票，NiftyGate 就是守门的保安。

与典型的代币标准兼容，包括可替换的和非可替换的（ERC20、ERC721、ERC777 和 ERC1155）。
与任何通过 WebSockets 与 Web3 通信的区块链兼容。
位于任何使用 HTTP 通信的东西之前。
具有嵌入式模式，可用于客户端应用程序。
与支持 HTTP 头的任何身份验证系统集成。
提供选择、部署、调试和审计兼容智能合约的工具。
作为一个单独的、自包含的二进制文件提供。
跨平台（在 Linux 和 macOS 上进行了测试，应在其他地方也能工作）。
开源（MIT 许可），用 Rust 编写。

这是什么？

niftygate 是 HTTP 服务的代理，它验证签名，为这些服务提供身份验证层。它还具有向请求自动注入签名的客户端功能。

我能用它做什么？

截至 0.2，支持智能合约。这些允许使用代币作为可转让的许可证来访问受保护的服务。

一些示例

一个 OCI 仓库，允许授权用户下载资产。
一个问题跟踪器，允许项目支持者获得优先支持。
一个产品路线图，允许客户在功能开发上拥有成比例的投票权。
一个部署管道，需要 N-of-M 个授权用户才能发布到生产。
一个具有去中心化许可证的应用商店，作者保留许可控制权，而不是平台。
一个数字图书馆，借出由代币管理，归还由智能合约强制执行。

为什么会有这个存在？

这实际上是两个问题，让我们分解一下...

为什么这个概念有用？

基于签名的身份验证避免了基于密码认证的许多陷阱。服务器只需要知道公钥，如果那些公钥泄露了...谁在乎呢？它们是公钥。

假设在两种情况下都有合理的用户界面，用户可以像更改密码一样轻松地轮换密钥。他们可以将部分权限委派给其他密钥（就像我们在其他地方处理访问令牌那样）。

密钥是用户生成的，而不是用户记忆的。这完全消除了密码重用等问题。

为什么这种方法是实用的？

将其以代理的形式实现，使其能够应用于大多数现有的HTTP(S)应用程序而无需修改。

将签名与验证分离，可以更精细地控制哪些有权访问私钥。这也意味着代理可以仅在有需要的地方使用。如果客户端应用程序可以本地处理签名，那么它应该这样做。

将其作为一系列可组合的中间件实现，使其扩展变得简单，并且可以（负责任地）对新功能进行实验。

如果您喜欢这种类型的东西，它也可以作为一个边车容器部署。

我如何获得这个出色的工具？

cargo install niftygate

或者，如果您喜欢Docker

docker pull colstrom/niftygate:0.8.0

我如何使用它？

首先，您需要一种服务，您想在前面放置代理。

为了演示和开发目的，niftygate包含一个嵌入式示例服务，该服务将请求头打印在响应体中。

$ niftygate demo
tide::log Logger started
    level DEBUG
tide::server Server listening on http://127.0.0.1:8080

接下来，您需要有一个Ethereum JSON-RPC（Web3）服务可供niftygate交互。 Ganache是本地使用的绝佳选择，因此本文件的其余部分假设您使用了它。

首先，选择您想要用于签名的地址：在Ganache中选择地址的截图

然后，找到该地址的私钥：在Ganache中找到私钥的截图

将此私钥添加到环境变量中

使用fish

set -x SECRET_KEY_DATA PUT_THE_DATA_HERE

使用旧式shell，如bash

export SECRET_KEY_DATA=PUT_THE_DATA_HERE

现在您已经准备好运行它了！让我们看看帮助信息

$ niftygate web3 --help

niftygate-web3 0.1.0
Runs the proxy service

USAGE:
    niftygate web3 [FLAGS] [OPTIONS]

FLAGS:
    -h, --help                             Prints help information
    -V, --provides-account-verification    verify signatures and provide account addresses
    -B, --provides-balances                provide account balances
    -S, --provides-signatures              provide signatures
        --version                          Prints version information

OPTIONS:
        --address-header <name>        [env: ADDRESS_HEADER=]    [default: X-Web3-Account-Address]
    -b, --backend <url>                [env: BACKEND=]           [default: http://127.0.0.1:8080]
        --balance-header <name>        [env: BALANCE_HEADER=]    [default: X-Web3-Account-Balance]
        --balance-maximum <amount>     [env: BALANCE_MAXIMUM=]
        --balance-minimum <amount>     [env: BALANCE_MINIMUM=]
    -u, --balance-scale <unit>         [env: BALANCE_SCALE=]     [default: Wei]
    -c, --challenge <phrase>           [env: CHALLENGE=]         [default: totes-legit]
    -l, --listen <address>             [env: LISTEN=]            [default: 0.0.0.0:8000]
    -K, --secret-key-data <hex>        [env: SECRET_KEY_DATA=]
    -k, --secret-key-file <path>       [env: SECRET_KEY_FILE=]
        --signature-header <name>      [env: SIGNATURE_HEADER=]  [default: X-Web3-Signature]
    -w, --web3-rpc-url <url>           [env: WEB3_RPC_URL=]      [default: ws://127.0.0.1:7545]

尽管这些选项都是可选的，但如果您不启用其中至少一个，它将不会做任何事情。让我们关注两种情况。

场景1 - 提供签名

在此模式下，niftygate为其处理的每个请求添加一个签名。

$ niftygate web3 --provides-signatures
tide::log Logger started
    level DEBUG
tracing::span new
tracing::span build
isahc::agent agent waker listening on 127.0.0.1:61558
isahc::agent agent_thread; port=61558
isahc::agent agent took 409.705µs to start up
tide::server Server listening on http://0.0.0.0:8000

需要秘密（私钥）来签署这些请求。它可以作为一个文件（--secret-key-file）或十六进制字符串（--secret-key-data）给出。如果两者都给出，则忽略--secret-key-file。这些也可以通过环境变量给出，这正是我们上面所做的那样。

该密钥用于签署一个挑战短语（目前由--challenge给出），该短语应该为客户端和服务器所熟知。它不需要是私有的。

该签名使用--signature-header给出的头信息添加到请求中。

场景2 - 提供账户验证

在此模式下，niftygate 期望请求包含签名头，并且会拒绝不包含该头的请求。这些头将被验证，用于签名的地址将被添加到它处理的每个请求中。

请注意，客户端并未明确提供地址。它们会对双方都知晓的挑战短语进行签名，签名的地址可以从有效的签名中恢复。

$ niftygate web3 --provides-account-verification
tide::log Logger started
    level DEBUG
tracing::span new
tracing::span build
isahc::agent agent waker listening on 127.0.0.1:56181
isahc::agent agent_thread; port=56181
isahc::agent agent took 312.747µs to start up
tide::server Server listening on http://0.0.0.0:8000

如果签名有效，将使用由 --address-header 给定的头将地址添加到请求中。假设后端知道如何处理这个头。例如，您可以使用 X-Remote-User 头将 niftygate 与 Dex 集成。

场景 3 - 提供账户余额

在此模式下，niftygate 期望请求包含账户头，并且会拒绝不包含该头的请求。此头中提供的地址的余额将被添加到它处理的每个请求中。

$ niftygate web3 --provides-balances
tide::log Logger started
    level DEBUG
tracing::span new
tracing::span build
isahc::agent agent waker listening on 127.0.0.1:54608
isahc::agent agent_thread; port=54608
isahc::agent agent took 313.524µs to start up
tide::server Server listening on http://0.0.0.0:8000

默认情况下，这并不关心什么余额，它只是将余额添加到由 --balance-header 给定的头中。但是，有一些选项可以根据余额限制访问。

可以使用 --balance-minimum 选项来要求最小余额。这可以用作“有赌注”的一种形式，通过要求非零余额（这可能有助于防止机器人或协助速率限制），或者如果您有某种原因只想让大玩家访问。

可以使用 --balance-maximum 选项来拒绝余额超过给定金额的账户。这可以用来限制风险，或者如果您愿意，只让普通人访问。

可以使用 --balance-unit 选项来方便地缩放上述限制。一个 Gwei 有多少个零？不需要记住，只需设置 --balance-unit=Gwei，然后 niftygate 将在内部进行缩放。不过，余额头仍然以 Wei 表示。

注意

上面的例子展示了如何独立使用功能，但它们都实现为可组合的中间件。您可以在单个进程中启用所有这些功能。在同一个进程中同时使用签名和验证似乎有点愚蠢，但您可以这样做。

试试吧！

假设您已启用所有功能，并且代理位于演示应用程序前面，如果您使用 curl 对其进行查询，您会看到以下内容

直接查询演示应用程序

$ curl -s http://127.0.0.1:8080 | sort
accept: ["*/*"]
host: ["127.0.0.1:8080"]
user-agent: ["curl/7.64.1"]

通过代理查询

$ curl -s http://127.0.0.1:8000 | sort
accept-encoding: ["deflate, gzip"]
accept: ["*/*"]
content-length: ["0"]
content-type: ["application/octet-stream"]
forwarded: ["by=127.0.0.1:8000;for=\"127.0.0.1:52698\";host=127.0.0.1:8000;proto=http"]
host: ["127.0.0.1:8000"]
user-agent: ["curl/7.64.1"]
x-web3-address: ["24f9f97c9e540fed57ef81f6c9aeabdb6fc73acd"]
x-web3-balance: ["100000000000000000000"]
x-web3-signature: ["krpQZO9WpgAEso2uk6eAKDy29QjeVtr+gdDZ7iG4bFkYiTfNvTvU5l4bb2iod5F4Ab8a8tJqzXHSXLkyz9U/gRs="]

智能合约

嵌入预设

为了帮助您入门，niftygate 嵌入来自 OpenZeppelin 项目的预设集。这些预设解决了一些更常见的用例，并且根据 OpenZeppelin 文档，它们是生产就绪的。

目前包括五个预设，以及部署和与每个预设交互的实用工具。这些可以在 contract 子命令下找到。

为了帮助您确定哪个合约是合适的，检查 guide 子命令。在那里您将找到一个交互式程序，它会问您几个简单的问题，然后向您提供一个建议。

路线图

0.1 - 初始发布，支持 Web3 账户验证
0.2 - 支持令牌标准
- 支持 ERC-20 (令牌标准)
- 支持 ERC-777 (令牌标准)
- 支持 ERC-721 (非同质化令牌标准)
- 支持ERC-1155 (多令牌标准)
0.3 - 智能合约的可观察性
0.5 - 支持可升级智能合约
0.6 - 从 sig-proxy 重命名为 NiftyGate
0.7 - TLS 支持
0.8 - 资产管理和（实验性）市场支持

愿望清单（无特定顺序）

Infura 集成

支持RFC-7486 (HTTP 原始源身份验证)

用随机挑战替换固定消息，添加 nonce 和过期时间等。

可选端点以在浏览器中提供嵌入脚本的支持。

使用 Web Crypto API 进行密钥生成和签名。
使用 Web Storage API 进行密钥存储。
使用 Fetch API 进行头部操作和身份验证流程。

X509 支持

这将在更偏好信任模型的情况下提供一种替代方案。

PGP 支持

这将在更偏好信任网络的情况下提供一种替代方案。

许可证

niftygate 在 MIT 许可证下可用。有关完整内容，请参阅 LICENSE.txt。

niftygate 集成了来自 OpenZeppelin Contracts 的合约 ABI 规范和文档摘录。这些内容也按照 MIT 许可证条款分发，详情请参阅此处。

NiftyGate 如何帮助我？

我已有网站和智能合约

以服务器模式运行 niftygate，提供您网站的地址和合约的地址。

我有网站，但不想使用智能合约

以服务器模式运行 niftygate，向 niftygate 提供您网站的地址，它将允许用户使用钱包登录。

我有非 Web 应用程序，并想与智能合约接口

将 niftygate 编译为库，并将其嵌入到您的应用程序中。

我有非 Web 应用程序，并且不想修改我的代码。

以客户端模式运行 niftygate，并将您的应用程序指向它。

我使用容器平台，如 Docker 或 Kubernetes。

以客户端或服务器模式运行 niftygate，作为旁路容器部署。

我使用 Kubernetes，并想将智能合约集成到控制器中。

使用 contract events --stream 模式。这将输出匹配的事件，以紧凑的 JSON 格式在 STDOUT 上显示。

我没有智能合约，但我想有一个。

部署 niftygate 内置的其中一个合约，无需编写代码！

我不知道我需要什么类型的智能合约。

使用 niftygate 内置的交互式向导。

我没有 Ethereum 节点可以连接。

在 infura.io 上注册账户，并将 niftygate 指向它。免费账户每天允许最多 100k 个请求，如果您需要更多，他们有付费计划可供选择。

我想使用私有区块链。

去做吧。niftygate 的大部分开发都是在私有区块链上完成的。只要它支持通过 WebSockets 使用 JSON-RPC + Web3，就应该没问题。

Ganache 和 geth 是不错的选择，具体取决于您的需求。

我想使用自己的身份平台。

以服务器模式运行 niftygate，并告诉它应传递哪些头部信息。

依赖关系

~13–20MB
~245K SLoC