VUE+PostgreSQL+PostgREST实现用户权限安全分级

灰太狼 2022-04-08 10:42 551阅读 0赞

预计阅读时间：5分钟

**目录直通车**

前言

一、如何实现权限验证？

1、 后台JWT生成key

（1） 新增用户 （Add a Trusted User）

（2） 加密处理（Make a Secret）

（3） 制定token（Sign a Token）

（4） HTTP请求

（5） 设置token的到期时间

2、 前台与后台结合实现

这样真的安全吗，如果请求被伪造怎么办？

--------------------

# 前言 #

最近在做一个工厂的项目，在这个项目里面需要给用户设置一些权限，比如说普通员工只能录入数据不能修改、普通管理员可以查看和修改、超级管理员可以给其他用户设置有哪些权限。以下内容是我们团队完成权限验证之后的浓缩总结。PostgREST不知道是啥的话，还是[点击这里][Link 1]补脑吧！（官方文档实在看不懂的话.......关于PostgREST的中文文档，我们团队已翻译处理，后续也会放在文末分享给大家。）

# 一、如何实现权限验证？ #

（参考PostgREST官方文档**JWT**部分：[http://postgrest.org/en/v5.1/auth.html\#jwt-generation][http_postgrest.org_en_v5.1_auth.html_jwt-generation]如果下面的方案解决不了您的问题请参考其它方案请回来参考[http://postgrest.org/en/v5.1/tutorials/tut1.html\#tutorial-1-the-golden-key][http_postgrest.org_en_v5.1_tutorials_tut1.html_tutorial-1-the-golden-key]）

这个项目的验证机制的核心是在后台生成一个带有权限的key，前台只是负责发送key与后台的key比对，我不想误导大家，因为我之前被别人的文章误导之后久久不能释怀......，所以请看下方原话：

> 客户端使用JSON Web Tokens通过API进行身份验证。这些是JSON对象，使用仅为我们和服务器所知的密码进行加密签名。由于客户端不知道密码，因此无法篡改其令牌的内容。PostgREST将检测伪造的令牌并拒绝它们。

那么问题来了，如果有人抓数据包，岂不是很容易就什么都看到了？所以需要加密。

## 1、 后台JWT生成key ##

这个key分为三部分，前两个部分系统生成，在第三个**secret**的部分。请注意这里指的不是用户的密码，当时我看了一些博文导致我以为token写死的不能变。然而，这个secret的部分是自己可以随意放入的字符串，这样的加密方式可以说是非常安全。如果您已经明白了，看完下面这张图就可以直接跳过了。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjQ3OTk5_size_16_color_FFFFFF_t_70][]

**具体实现**

（原文链接：[http://postgrest.org/en/v5.1/tutorials/tut1.html\#step-1-add-a-trusted-user][http_postgrest.org_en_v5.1_tutorials_tut1.html_step-1-add-a-trusted-user]）

###  （1） 新增用户 （Add a Trusted User） ###

在PostgreSQL数据库中创建了一个web\_anon角色，用于执行匿名Web请求。让我们todo\_user为使用API，进行身份验证的用户调用一个角色。此角色将有权赋予权限列表执行任何操作。

//创建角色不允许登陆
    create role todo_user nologin;    
    //赋予角色与postgres用户	
    grant todo_user to postgres;	
     //schema api允许todo_user查找该Schema下的对象
    grant usage on schema api to todo_user;   
     //单表赋予todo_user角色对api.todos表所有权限
    grant all on api.todos to todo_user;     
    //赋予todo_user 对于当前api下的所有表的所有权限
    //grant select on ALL tables in schema api to web_anon ;   
    //查询此表序列号的权限也就是 序列号自动增长的权限
    grant usage, select on sequence api.todos_id_seq to todo_user;

### （2） 加密处理（Make a Secret） ###

客户端使用JSON Web Tokens通过API进行身份验证。这些是JSON对象，使用仅为我们和服务器所知的密码进行加密签名。由于客户端不知道密码，因此无法篡改其令牌的内容。PostgREST将检测伪造的令牌并拒绝它们。

让我们创建一个密码并将其提供给PostgREST。想想一个很好的长的，或使用工具来生成它。**您的密码长度必须至少为32个字符**

**我们的服务器是：Linux 7**

[root@localhost ~]# openssl rand 32 -base64

得到下面这串加密后的字符串：qHH/CeK+w3gqSOZjZJyuon4n7ptaQ+2TarNh7r7BYKM=

接着打开 tutorial.conf 文件，把这串加密的字符串新增一行写进去。

# PASSWORD MUST BE AT LEAST 32 CHARS LONG
    # add this line to tutorial.conf:
    
    #jwt-secret = "<the password you made>"
    jwt-secret = "qHH/CeK+w3gqSOZjZJyuon4n7ptaQ+2TarNh7r7BYKM="
    
    #如果启用了secret base64 encoded 
    #请把下面设置为ture默认为false 本实例中设置的
    #secret-is-base64 = true

然后重启PostgREST服务器，一定不要忘记了。

### （3） 制定token（Sign a Token） ###

在JWT的官网创建一个会话测试：[*https://jwt.io*][https_jwt.io]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjQ3OTk5_size_16_color_FFFFFF_t_70 1][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjQ3OTk5_size_16_color_FFFFFF_t_70 2][]

### （4） HTTP请求 ###

现在回到服务器终端，让我们curl来添加一个行记录。该请求将包含一个包含身份验证令牌的HTTP标头。

#export TOKEN="<paste token here>"
    export TOKEN = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyb2xlIjoidG9kb191c2VyIn0.8qw7X2-98Gaua0d5AljE8qaBWd-LFBlCdLVQ5hOnNyA"
    curl http://localhost:3000/todos -X POST \
         -H "Authorization: Bearer $TOKEN"   \
         -H "Content-Type: application/json" \
         -d '{"task": "learn how to auth"}'

紧接着通过一个patch请求将done设置为true。

curl http://localhost:3000/todos -X PATCH \
         -H "Authorization: Bearer $TOKEN"    \
         -H "Content-Type: application/json"  \
         -d '{"done": true}'

服务器端完成配置后。在postgREST里发送一个如下的json包请求给服务器测试一波。

curl http://localhost:3000/todos
    [
      {
        "id": 1,
        "done": true,
        "task": "finish tutorial 0",
        "due": null
      },
      {
        "id": 2,
        "done": true,
        "task": "pat self on back",
        "due": null
      },
      {
        "id": 3,
        "done": true,
        "task": "learn how to auth",
        "due": null
      }
    ]

### （5） 设置token的到期时间 ###

原文如下：

> Currently our authentication token is valid for all eternity. The server, as long as it continues using the same JWT password, will honor the token.
> 
> It’s better policy to include an expiration timestamp for tokens using the exp claim. This is one of two JWT claims that PostgREST treats specially.

目前token永久有效，只要服务器继续使用相同的**JWT**的**Secret**，它就会使用相同的token，所以就希望能够设置这个token到期的时间，需要使用exp来声明**时间戳**给这个token。

现在在数据库运行下面这条命令来设置到期时间：

select extract(epoch from now() + '5 minutes'::interval) :: integer;

再回到发送[*https://jwt.io* ][https_jwt.io]以下payload：

{
      "role": "todo_user",
      "exp": <computed epoch value>
    }

把之前的token复制保存到一个新的变量里面，便于复制之后重新向服务器发送请求作为对比。

as $$
    begin
      if current_setting('request.jwt.claim.email', true) =
         'disgruntled@mycompany.com' then
        raise insufficient_privilege
          using hint = 'Nope, we are on to you';
      end if;
    end
    $$;

接下来在tutorial.conf的文件里面添加下面一行指定新功能：

pre-request = "auth.check_token"

完成之后，请不要忘记重启PostgREST。下面验证一下之前保存下来的token。

# 这个可以正常请求
    
    curl http://localhost:3000/todos \
         -H "Authorization: Bearer $TOKEN"
    
    # 这个请求失败
    
    curl http://localhost:3000/todos \
         -H "Authorization: Bearer $WAYWARD_TOKEN"

失败之后，服务器会返回以下信息：

{
      "hint": "Nope, we are on to you",
      "details": null,
      "code": "42501",
      "message": "insufficient_privilege"
    }

## 2、 前台与后台结合实现 ##

前台Vue无非就是route路由控制。我这里实现的方式是，用户每一次的操作都会做一次校验（也就是key与服务器的key比对），前端的话可以减轻工作量，而且也很安全。

### **这样真的安全吗，如果请求被伪造怎么办？** ###

这个key分为三个部分，有两个部分是写死的，secret这个部分可以随机给，然后组合成为一段字符串。所以，在用户登录的时候才给用户生成一个他对应权限的key，然后销毁。每一次登录和每一次操作都会重新生成一次key，每一次都会与后台的key比对。

源码的话，一般我都会免费分享给大家，但考虑到同某央企工厂签过保密协议，这里就不提供给大家了，还望见谅。

[PostgREST中文参考文档][PostgREST] ，提取码: rnbn

[Link 1]: https://www.baidu.com/s?ie=utf-8&f=8&rsv_bp=1&tn=monline_3_dg&wd=PostgRest&oq=xamarin%2520%25E5%25BA%2595%25E9%2583%25A8%25E5%25AF%25BC%25E8%2588%25AA%2520%25E4%25BE%25A7%25E6%25BB%2591&rsv_pq=cb25f1d200005ef5&rsv_t=859fhxdvhaNPyYgZ1kNi9cy2co4c2X7iHntTGUtsz1Ohgx8UCrK%2FmG%2FMV6rNPhuA7ZFg&rqlang=cn&rsv_enter=1&inputT=9784&rsv_sug3=91&rsv_sug1=58&rsv_sug7=101&rsv_sug2=0&rsv_sug4=12713
[http_postgrest.org_en_v5.1_auth.html_jwt-generation]: http://postgrest.org/en/v5.1/auth.html#jwt-generation
[http_postgrest.org_en_v5.1_tutorials_tut1.html_tutorial-1-the-golden-key]: http://postgrest.org/en/v5.1/tutorials/tut1.html#tutorial-1-the-golden-key
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjQ3OTk5_size_16_color_FFFFFF_t_70]: /images/20220406/3fa2b6994bb849569adbd911a8a0caa2.png
[http_postgrest.org_en_v5.1_tutorials_tut1.html_step-1-add-a-trusted-user]: http://postgrest.org/en/v5.1/tutorials/tut1.html#step-1-add-a-trusted-user
[https_jwt.io]: https://jwt.io/
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjQ3OTk5_size_16_color_FFFFFF_t_70 1]: /images/20220406/034e418cdf1e4783886b787dd43c3a0c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjQ3OTk5_size_16_color_FFFFFF_t_70 2]: /images/20220406/2f1ea1d869b14a9e906a3ad225da7cf5.png
[PostgREST]: https://pan.baidu.com/s/1b07urO3UormyIcCVm-HR8A