1 个不稳定版本

0.8.0 2022 年 5 月 9 日

#2#niftygate


niftygate 使用

MIT 许可证

13MB
253K SLoC

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

简介

使用任何智能合约,部署到任何区块链,不修改您的代码,即可访问网络上的任何内容。

概述

如果您认为代币像是进入俱乐部的门票,NiftyGate 将是门口的保安。

  • 兼容典型的代币标准,包括可互换和不可互换的代币(ERC20、ERC721、ERC777 和 ERC1155)。

  • 与任何通过 WebSocket 与 Web3 通信的区块链兼容。

  • 位于任何使用 HTTP 通信的服务之前。

  • 具有嵌入式模式,适用于客户端应用程序。

  • 与支持 HTTP 头的任何身份验证系统集成。

  • 提供选择、部署、调试和审计兼容智能合约的工具。

  • 所有功能作为一个单一、自包含的二进制文件提供。

  • 跨平台(已在 Linux 和 macOS 上进行测试,应在其他平台上也能工作)。

  • 开源(MIT 许可),用 Rust 编写。

这是什么?

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

我能用它来做什么?

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

一些例子

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

为什么会有这个存在?

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

这个概念为什么有用?

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

假设两种情况下的UI都合理,用户可以像更换密码一样轻松地更换密钥。他们可以将权限的子集委派给其他密钥(就像我们在其他地方使用访问令牌一样)。

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

为什么这种方法实用?

以代理的形式实现这一方法,允许它在不修改的情况下应用于大多数现有的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

接下来,您需要有一个以太坊JSON-RPC(Web3)服务可供 niftygate 交互。 Ganache 是本地使用的绝佳选择,所以本文档的其余部分假设您会使用它。

首先,选择您想要用于签名的地址:显示如何在Ganache中选择地址的截图

然后,找到这个地址的私钥:显示在哪里找到Ganache中私钥的截图

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

使用 fish

set -x SECRET_KEY_DATA PUT_THE_DATA_HERE

使用老式外壳 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 头将 niftygateDex 集成。

场景 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 子命令。在那里,你将找到一个交互式程序,它会问你几个简单的问题,然后向你提供一个推荐。

路线图

愿望清单(无特定顺序)

Infura 集成

支持RFC-7486(HTTP 原始地址绑定身份验证)

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

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

X509 支持

  • 这将为偏好信任链模型的用户提供一种替代方案。

PGP 支持

  • 这将为偏好信任网络模型的用户提供一种替代方案。

许可证

niftygate在MIT许可证下可用。有关完整文本,请参阅LICENSE.txt

niftygate嵌入合约ABI规范和从OpenZeppelin Contracts中摘录的文档。这些也在MIT许可证此处的条款下分发。

NiftyGate如何帮助我?

我已经有一个网站和一个智能合约

以服务器模式运行niftygate,给它您的网站地址和合约地址。

我有一个网站,但我不想使用智能合约

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

我有一个非Web应用,我想与智能合约交互

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

我有一个非Web应用,我不想修改我的代码。

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

我正在使用容器平台,如Docker或Kubernetes。

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

我正在使用Kubernetes,并希望将智能合约集成到Controller中。

使用contract events --stream模式。这将输出匹配的事件,作为紧凑的JSON在STDOUT上。

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

部署niftygate附带的一个内置合约,无需代码!

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

使用niftygate内置的交互式指南。

我没有Ethereum节点要连接。

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

我想使用私有区块链。

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

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

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

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

依赖关系

~22–34MB
~484K SLoC