本文的内容是我的开源代码（https://github.com/e10101/AdminLogin）的中文申明。
项目主假如完成了经由过程合理设置Nginx的auth_request模块来完成对敏感途径下的内容举行接见限定。

代码

可经由过程Github接见：https://github.com/e10101/AdminLogin，来猎取代码。假如能够的话，能够Star一下。

开辟初志

这个项目是为了处理网站中部分治理资本(途径)须要举行权限限定,但又不想经由过程庞杂体系去完成而举行编写的项目.

同时这个项目也没有采纳Nginx的auth_basic模块来完成权限限定.二是经由过程auth_request来举行的权限限定.

构造框架

本项目是基于NodeJS/ExpressJS/PassportJS以及Github的。

为解说轻易，假定存在:
服务器A(server1.example.com)，其途径/installs上存有敏感信息，其他途径可公然接见，端口3003。
服务器B(login.example.com)，为认证服务器，其上布置了本项目代码，端口4001。

体系以CentOS7.2为例，认证运用的Github用户认证。

表示设置

服务器A(server1)的Nginx设置文件

server {
    listen 80;
    listen [::]:80;

    server_name  server1.example.com;

    location = /auth {
        internal;
        proxy_pass http://login.example.com;

        proxy_pass_request_body     off;

        proxy_set_header X-Original-URI $request_uri;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    error_page 401 = @error401;
    location @error401 {
        return 302 http://login.example.com;
    }
    location / {
        try_files $uri $uri/ @proxy;
    }

    # The path has secret content
    location /installs {
        auth_request /auth;
        try_files $uri $uri/ @proxy;
    }

    location @proxy {
        proxy_set_header  Host $host;
        proxy_set_header  X-Real-IP $remote_addr;
        proxy_set_header  X-Forwarded-Proto https;
        proxy_set_header  X-Forwarded-For $remote_addr;
        proxy_set_header  X-Forwarded-Host $remote_addr;
        proxy_pass    http://127.0.0.1:3003;
    }
}

服务器B(login)的Nginx设置

server {
    listen 80;
    listen [::]:80;

    server_name  login.example.com;

    location / {
    proxy_set_header  Host $host;
    proxy_set_header  X-Real-IP $remote_addr;
    proxy_set_header  X-Forwarded-Proto https;
    proxy_set_header  X-Forwarded-For $remote_addr;
    proxy_set_header  X-Forwarded-Host $remote_addr;
    proxy_pass    http://127.0.0.1:4001/;

    }
}

基础流程

• 用户接见服务器A的敏感资本（即途径/installs中的内容），Nginx经由过程设置文件中的auth_request字段去要求http://login.example.com/auth，因为用户并未在服务器B举行登录，因而服务器B返回了401无权限的毛病。

• 依据服务器A的设置，发明401毛病后，会向用户返回302状况指向为服务器B的主机地点（login.example.com）。

• 用户浏览器跳转到服务器B，并挑选第三方的用户认证举行受权（此处以Github为例），当用户经由过程Github举行受权后，回向服务器B返回用户的个人信息。

• 服务器B从第三方反应回的信息中，检索出用户的用户名（username），然后服务器B会将此用户名与已有的治理员信息举行对照（此处经由过程设置文件完成），假如登录用户为正当的治理员账号，则服务器B受权其登录进入。假如为不法用户，则不对其受权，因而不法用户没法取得有用登录凭据。

  • 假如用户为正当用户：
    那末服务器B将会天生session，并经由过程Set-cookie敕令示知用户浏览器。用户经由过程此Cookie即可取得服务器B的承认受权。当用户经由过程此Cookie接见服务器B中的/auth目次时，会返回200的状况码。

  • 假如用户为不法用户：
    那末服务器B将不会session，因为用户没法取得承认的Cookie，那末当用户再次接见/auth的途径时，服务器会返回401毛病。

• 假定用户已受权胜利，那末当用户接见服务器A中的敏感内容/installs时，服务器A接见服务器B的/auth途径，此时返回200状况码，服务器A则许可用户举行接见。

以上，经由过程auth_request模块以及相干设置就完成了对敏感内容的接见限定。而且经由过程第三方的机制，也无需本身手工完成登录功用。同时，此计划能够对统一域名下的差别子域名中的内容举行接见限定。能够反复运用一个登录体系，服务于多个其他体系。

注意事项

• 设置Express的session时，因为本案例中运用了差别的子域名（server1.example.com及login.example.com），须要迥殊设置cookie的domain项，以下所示：

  app.use(session({ 
   secret: config.session.secret,
   cookie: {
     path: config.cookie.path,
     domain: config.cookie.domain,
     maxAge: config.cookie.maxAge
   }
  }));

  个中的domain花样为：.example.com。

• 关于为什么运用Github的题目。

  1. 国内能够接见（此项排除了Facebook,Google,Twitter等）；

  2. 建立运用简朴无需考核（此项排除了微信,微博等）。