nginx過濾器鑒權

Ⅰ nginx auth_basic

nginx的簡單鑒權
使用nginx搭建的web服務，需要限制訪問，但是構建用戶系統又過於繁瑣時，可考慮使用nginx的auth_basic進行簡單鑒權

Debian系統一般安裝apache後已經帶入，如果命令不存在嘗試 apt-get install apache2-utils 命令安裝

這個可以給swagger等頁面做簡單的鑒權。防止介面直接公開外露

Ⅱ nginx 有哪些功能

1.處理靜態文件，索引文件以及自動索引;
2.反向代理加速(無緩存)，簡單的負載均衡和容錯;
3.FastCGI，簡單的負載均衡和容錯;
4.模塊化的結構。過濾器包括gzipping,byte ranges,chunked responses，以及 SSI-filter。在SSI過濾器中，到同一個 proxy 或者 FastCGI 的多個子請求並發處理;
5.SSL 和 TLS SNI 支持;
6.IMAP/POP3代理服務功能：
7.使用外部 HTTP 認證伺服器重定向用戶到 IMAP/POP3 後端;
8.使用外部 HTTP 認證伺服器認證用戶後連接重定向到內部的 SMTP 後端;
以上nginx的基礎功能。

Ⅲ 如何給 nginx rtmp 服務加入鑒權機制

設置MSYS、Perl、VC環境變數
運行vc設置環境變數腳本vcvarsall.bat（默認安裝路徑：C:\Program Files\MicrosoftVisual Studio 9.0\VC）！

Ⅳ 面試官：請問Nginx為什麼比Apache性能好

Nginx才短短幾年，就拿下了web伺服器大筆江山，眾所周知，Nginx在處理大並發靜態請求方面，效率明顯高於httpd，甚至能輕松解決C10K問題。下面我們就來聊聊Web伺服器背後的一些原理。

進程是具有一定獨立功能的，在計算機中已經運行的程序的實體。在早期系統中（如linux 2.4以前），進程是基本運作單位，在支持線程的系統中（如windows，linux2.6）中，線程才是基本的運作單位，而進程只是線程的容器。程序本身只是指令、數據及其組織形式的描述，進程才是程序（那些指令和數據）的真正運行實例。若干進程有可能與同一個程序相關系，且每個進程皆可以同步（循序）或非同步（平行）的方式獨立運行。現代計算機系統可在同一段時間內以進程的形式將多個程序載入到存儲器中，並藉由時間共享（或稱時分復用），以在一個處理器上表現出同時（平行性）運行的感覺。同樣的，使用多線程技術（多線程即每一個線程都代表一個進程內的一個獨立執行上下文）的操作系統或計算機架構，同樣程序的平行線程，可在多 CPU 主機或網路上真正同時運行（在不同的CPU上）。

Web伺服器要為用戶提供服務，必須以某種方式，工作在某個套接字上。一般Web伺服器在處理用戶請求是，一般有如下三種方式可選擇：多進程方式、多線程方式、非同步方式。Web伺服器要為用戶提供服務，必須以某種方式，工作在某個套接字上。一般Web伺服器在處理用戶請求是，一般有如下三種方式可選擇：多進程方式、多線程方式、非同步方式。多進程方式：為每個請求啟動一個進程來處理。由於在操作系統中，生成進程、銷毀進程、進程間切換都很消耗CPU和內存，當負載高是，性能會明顯降低。優點： 穩定性！由於採用獨立進程處理獨立請求，而進程之間是獨立的，單個進程問題不會影響其他進程，因此穩定性最好。缺點： 資源佔用！當請求過大時，需要大量的進程處理請求，進程生成、切換開銷很大，而且進程間資源是獨立的，造成內存重復利用。多線程方式：一個進程中用多個線程處理用戶請求。由於線程開銷明顯小於進程，而且部分資源還可以共享，因此效率較高。優點：開銷較小！線程間部分數據是共享的，且線程生成與線程間的切換所需資源開銷比進程間切換小得多。缺點：穩定性！線程切換過快可能造成線程抖動，且線程過多會造成伺服器不穩定。非同步方式：使用非阻塞方式處理請求，是三種方式中開銷最小的。但非同步方式雖然效率高，但要求也高，因為多任務之間的調度如果出現問題，就可能出現整體故障，因此使用非同步工作的，一般是一些功能相對簡單，但卻符合伺服器任務調度、且代碼中沒有影響調度的錯誤代碼存在的程序。優點：性能最好！一個進程或線程處理多個請求，不需要額外開銷，性能最好，資源佔用最低。缺點：穩定性！某個進程或線程出錯，可能導致大量請求無法處理，甚至導致整個服務宕機。

從上圖中我們可以看出，可以看出，越往後，阻塞越少，理論上效率也是最優。其五種I/O模型中，前三種屬於同步I/O，後兩者屬於非同步I/O。

同步I/O:

非同步I/O:

非同步 I/O 和 信號驅動I/O的區別:

注，其中iocp是Windows實現的，select、poll、epoll是Linux實現的，kqueue是FreeBSD實現的，/dev/poll是SUN的Solaris實現的。select、poll對應第3種（I/O復用）模型，iocp對應第5種（非同步I/O）模型，那麼epoll、kqueue、/dev/poll呢？其實也同select屬於同一種模型，只是更高級一些，可以看作有了第4種（信號驅動I/O）模型的某些特性，如callback機制。

答案是，他們無輪詢。因為他們用callback取代了。想想看，當套接字比較多的時候，每次select()都要通過遍歷FD_SETSIZE個Socket來完成調度，不管哪個Socket是活躍的，都遍歷一遍。這會浪費很多CPU時間。如果能給套接字注冊某個回調函數，當他們活躍時，自動完成相關操作，那就避免了輪詢，這正是epoll、kqueue、/dev/poll做的。這樣子說可能不好理解，那麼我說一個現實中的例子，假設你在大學讀書，住的宿舍樓有很多間房間，你的朋友要來找你。select版宿管大媽就會帶著你的朋友挨個房間去找，直到找到你為止。而epoll版宿管大媽會先記下每位同學的房間號，你的朋友來時，只需告訴你的朋友你住在哪個房間即可，不用親自帶著你的朋友滿大樓找人。如果來了10000個人，都要找自己住這棟樓的同學時，select版和epoll版宿管大媽，誰的效率更高，不言自明。同理，在高並發伺服器中，輪詢I/O是最耗時間的操作之一，select、epoll、/dev/poll的性能誰的性能更高，同樣十分明了。

誠然，Windows的IOCP非常出色，目前很少有支持asynchronous I/O的系統，但是由於其系統本身的局限性，大型伺服器還是在UNIX下。而且正如上面所述，kqueue、epoll、/dev/poll 與 IOCP相比，就是多了一層從內核數據到應用層的阻塞，從而不能算作asynchronous I/O類。但是，這層小小的阻塞無足輕重，kqueue、epoll、/dev/poll 已經做得很優秀了。

只有IOCP(windows實現)是asynchronous I/O，其他機制或多或少都會有一點阻塞。select（Linux實現）低效是因為每次它都需要輪詢。但低效也是相對的，視情況而定，也可通過良好的設計改善epoll(Linux實現)、kqueue（FreeBSD實現）、/dev/poll（Solaris實現）是Reacor模式，IOCP是Proactor模式。Apache 2.2.9之前只支持select模型，2.2.9之後支持epoll模型Nginx 支持epoll模型Java nio包是select模型

我們都知道Apache有三種工作模塊，分別為prefork、worker、event。prefork：多進程，每個請求用一個進程響應，這個過程會用到select機制來通知。worker：多線程，一個進程可以生成多個線程，每個線程響應一個請求，但通知機制還是select不過可以接受更多的請求。event：基於非同步I/O模型，一個進程或線程，每個進程或線程響應多個用戶請求，它是基於事件驅動（也就是epoll機制）實現的。

如果不用「--with-mpm」顯式指定某種MPM,prefork就是Unix平台上預設的MPM.它所採用的預派生子進程方式也是 Apache1.3中採用的模式。prefork本身並沒有使用到線程，2.0版使用它是為了與1.3版保持兼容性；另一方面，prefork用單獨的子進程來處理不同的請求，進程之間是彼此獨立的,這也使其成為最穩定的MPM之一。

相對於prefork，worker是2.0版中全新的支持多線程和多進程混合模型的MPM。由於使用線程來處理，所以可以處理相對海量的請求，而系統資源的開銷要小於基於進程的伺服器。但是，worker也使用了多進程,每個進程又生成多個線程，以獲得基於進程伺服器的穩定性，這種MPM的工作方 式將是Apache2.0的發展趨勢。

一個進程響應多個用戶請求，利用callback機制，讓套接字復用，請求過來後進程並不處理請求，而是直接交由其他機制來處理，通過epoll機制來通知請求是否完成；在這個過程中，進程本身一直處於空閑狀態，可以一直接收用戶請求。可以實現一個進程程響應多個用戶請求。支持持海量並發連接數，消耗更少的資源。

有幾個基本條件：

剛好，Nginx 支持以上所有特性。所以Nginx官網上說，Nginx支持50000並發，是有依據的。

傳統上基於進程或線程模型架構的web服務通過每進程或每線程處理並發連接請求，這勢必會在網路和I/O操作時產生阻塞，其另一個必然結果則是對內存或CPU的利用率低下。生成一個新的進程/線程需要事先備好其運行時環境，這包括為其分配堆內存和棧內存，以及為其創建新的執行上下文等。這些操作都需要佔用CPU，而且過多的進程/線程還會帶來線程抖動或頻繁的上下文切換，系統性能也會由此進一步下降。另一種高性能web伺服器/web伺服器反向代理：Nginx（Engine X），nginx的主要著眼點就是其高性能以及對物理計算資源的高密度利用，因此其採用了不同的架構模型。受啟發於多種操作系統設計中基於「事件」的高級處理機制，nginx採用了模塊化、事件驅動、非同步、單線程及非阻塞的架構，並大量採用了多路復用及事件通知機制。在nginx中，連接請求由為數不多的幾個僅包含一個線程的進程worker以高效的回環(run-loop)機制進行處理，而每個worker可以並行處理數千個的並發連接及請求。

Nginx會按需同時運行多個進程：一個主進程(master)和幾個工作進程(worker)，配置了緩存時還會有緩存載入器進程(cache loader)和緩存管理器進程(cache manager)等。所有進程均是僅含有一個線程，並主要通過「共享內存」的機制實現進程間通信。主進程以root用戶身份運行，而worker、cache loader和cache manager均應以非特權用戶身份運行。

主進程主要完成如下工作：

註：如果負載以CPU密集型應用為主，如SSL或壓縮應用，則worker數應與CPU數相同；如果負載以IO密集型為主，如響應大量內容給客戶端，則worker數應該為CPU個數的1.5或2倍。

Nginx的代碼是由一個核心和一系列的模塊組成, 核心主要用於提供Web Server的基本功能，以及Web和Mail反向代理的功能；還用於啟用網路協議，創建必要的運行時環境以及確保不同的模塊之間平滑地進行交互。不過，大多跟協議相關的功能和某應用特有的功能都是由nginx的模塊實現的。這些功能模塊大致可以分為事件模塊、階段性處理器、輸出過濾器、變數處理器、協議、upstream和負載均衡幾個類別，這些共同組成了nginx的http功能。事件模塊主要用於提供OS獨立的(不同操作系統的事件機制有所不同)事件通知機制如kqueue或epoll等。協議模塊則負責實現nginx通過http、tls/ssl、smtp、pop3以及imap與對應的客戶端建立會話。在Nginx內部，進程間的通信是通過模塊的pipeline或chain實現的；換句話說，每一個功能或操作都由一個模塊來實現。例如，壓縮、通過FastCGI或uwsgi協議與upstream伺服器通信，以及與memcached建立會話等。

處理靜態文件，索引文件以及自動索引；反向代理加速(無緩存)，簡單的負載均衡和容錯；FastCGI，簡單的負載均衡和容錯；模塊化的結構。過濾器包括gzipping, byte ranges, chunked responses, 以及 SSI-filter 。在SSI過濾器中，到同一個 proxy 或者 FastCGI 的多個子請求並發處理；SSL 和 TLS SNI 支持；

使用外部 HTTP 認證伺服器重定向用戶到 IMAP/POP3 後端；使用外部 HTTP 認證伺服器認證用戶後連接重定向到內部的 SMTP 後端；認證方法：POP3: POP3 USER/PASS, APOP, AUTH LOGIN PLAIN CRAM-MD5;IMAP: IMAP LOGIN;SMTP: AUTH LOGIN PLAIN CRAM-MD5;SSL 支持；在 IMAP 和 POP3 模式下的 STARTTLS 和 STLS 支持；

FreeBSD 3.x, 4.x, 5.x, 6.x i386; FreeBSD 5.x, 6.x amd64;Linux 2.2, 2.4, 2.6 i386; Linux 2.6 amd64;Solaris 8 i386; Solaris 9 i386 and sun4u; Solaris 10 i386;MacOS X (10.4) PPC;Windows 編譯版本支持 windows 系列操作系統

一個主進程和多個工作進程，工作進程運行於非特權用戶；kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7 11/99+), select, 以及 poll 支持；kqueue支持的不同功能包括 EV_CLEAR, EV_DISABLE （臨時禁止事件）， NOTE_LOWAT, EV_EOF, 有效數據的數目，錯誤代碼；sendfile (FreeBSD 3.1+), sendfile (Linux 2.2+), sendfile64 (Linux 2.4.21+), 和 sendfilev (Solaris 8 7/01+) 支持；輸入過濾 (FreeBSD 4.1+) 以及 TCP_DEFER_ACCEPT (Linux 2.4+) 支持；10,000 非活動的 HTTP keep-alive 連接僅需要 2.5M 內存。最小化的數據拷貝操作；

基於IP 和名稱的虛擬主機服務；Memcached 的 GET 介面；支持 keep-alive 和管道連接；靈活簡單的配置；重新配置和在線升級而無須中斷客戶的工作進程；可定製的訪問日誌，日誌寫入緩存，以及快捷的日誌回卷；4xx-5xx 錯誤代碼重定向；基於 PCRE 的 rewrite 重寫模塊；基於客戶端 IP 地址和 HTTP 基本認證的訪問控制；PUT, DELETE, 和 MKCOL 方法；支持 FLV （Flash 視頻）；帶寬限制；

在高連接並發的情況下，Nginx是Apache伺服器不錯的替代品: Nginx在美國是做虛擬主機生意的老闆們經常選擇的軟體平台之一. 能夠支持高達 50,000 個並發連接數的響應, 感謝Nginx為我們選擇了 epoll and kqueue 作為開發模型。Nginx作為負載均衡伺服器: Nginx 既可以在內部直接支持 Rails 和 PHP 程序對外進行服務, 也可以支持作為 HTTP代理 伺服器對外進行服務. Nginx採用C進行編寫, 不論是系統資源開銷還是CPU使用效率都比 Perlbal 要好很多。作為郵件代理伺服器: Nginx 同時也是一個非常優秀的郵件代理伺服器（最早開發這個產品的目的之一也是作為郵件代理伺服器）, Last.fm 描述了成功並且美妙的使用經驗.Nginx 安裝非常的簡單 , 配置文件非常簡潔（還能夠支持perl語法）,Bugs 非常少的伺服器: Nginx 啟動特別容易, 並且幾乎可以做到7*24不間斷運行，即使運行數個月也不需要重新啟動. 你還能夠 不間斷服務的情況下進行軟體版本的升級 。Nginx 的誕生主要解決C10K問題

Ⅳ nginx cas單點登錄受影響嗎

1.1. What is CAS ？
CAS （ Central Authentication Service ） 是 Yale 大學發起的一個企業級的、開源的項目，旨在為 Web 應用系統提供一種可靠的單點登錄解決方法（屬於 Web SSO ）。
CAS 開始於 2001 年， 並在 2004 年 12 月正式成為 JA-SIG 的一個項目。
1.2. 主要特性
1、 開源的、多協議的 SSO 解決方案； Protocols ： Custom Protocol 、 CAS 、 OAuth 、 OpenID 、 RESTful API 、 SAML1.1 、 SAML2.0 等。
2、 支持多種認證機制： Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates 等；
3、 安全策略：使用票據（ Ticket ）來實現支持的認證協議；
4、 支持授權：可以決定哪些服務可以請求和驗證服務票據（ Service Ticket ）；
5、 提供高可用性：通過把認證過的狀態數據存儲在 TicketRegistry 組件中，這些組件有很多支持分布式環境的實現，如： BerkleyDB 、 Default 、 EhcacheTicketRegistry 、 JDBCTicketRegistry 、 JBOSS TreeCache 、 JpaTicketRegistry 、 MemcacheTicketRegistry 等；
6、 支持多種客戶端： Java 、 .Net 、 PHP 、 Perl 、 Apache, uPortal 等。

2. SSO 單點登錄原理
本文內容主要針對 Web SSO 。
2.1. 什麼是SSO
單點登錄（ Single Sign-On , 簡稱 SSO ）是目前比較流行的服務於企業業務整合的解決方案之一， SSO 使得在多個應用系統中，用戶只需要 登錄一次 就可以訪問所有相互信任的應用系統。
2.2. SSO 原理
2.2.1. SSO 體系中的角色
一般 SSO 體系主要角色有三種：
1、 User （多個）
2、 Web 應用（多個）
3、 SSO 認證中心（ 1 個 ）
2.2.2. SSO 實現模式的原則
SSO 實現模式一般包括以下三個原則：
1、 所有的認證登錄都在 SSO 認證中心進行；
2、 SSO 認證中心通過一些方法來告訴 Web 應用當前訪問用戶究竟是不是已通過認證的用戶；
3、 SSO 認證中心和所有的 Web 應用建立一種信任關系，也就是說 web 應用必須信任認證中心。（單點信任）
2.2.3. SSO 主要實現方式
SSO 的主要實現方式有：
1、 共享 cookies
基於共享同域的 cookie 是 Web 剛開始階段時使用的一種方式，它利用瀏覽同域名之間自動傳遞 cookies 機制，實現兩個域名之間系統令牌傳遞問題；另外，關於跨域問題，雖然 cookies 本身不跨域，但可以利用它實現跨域的 SSO 。如：代理、暴露 SSO 令牌值等。
缺點：不靈活而且有不少安全隱患，已經被拋棄。
2、 Broker-based( 基於經紀人 )
這種技術的特點就是，有一個集中的認證和用戶帳號管理的伺服器。經紀人給被用於進一步請求的電子身份存取。中央資料庫的使用減少了管理的代價，並為認證提供一個公共和獨立的 " 第三方 " 。例如 Kerberos 、 Sesame 、 IBM KryptoKnight （憑證庫思想 ) 等。 Kerberos 是由麻省理工大學發明的安全認證服務，已經被 UNIX 和 Windows 作為默認的安全認證服務集成進操作系統。
3、 Agent-based （基於代理人）
在這種解決方案中，有一個自動地為不同的應用程序認證用戶身份的代理程序。這個代理程序需要設計有不同的功能。比如，它可以使用口令表或加密密鑰來自動地將認證的負擔從用戶移開。代理人被放在伺服器上面，在伺服器的認證系統和客戶端認證方法之間充當一個 " 翻譯 " 。例如 SSH 等。
4、 Token-based
例如 SecureID,WebID ，現在被廣泛使用的口令認證，比如 FTP 、郵件伺服器的登錄認證，這是一種簡單易用的方式，實現一個口令在多種應用當中使用。
5、 基於網關
6、 基於 SAML
SAML(Security Assertion Markup Language ，安全斷言標記語言）的出現大大簡化了 SSO ，並被 OASIS 批准為 SSO 的執行標准 。開源組織 OpenSAML 實現了 SAML 規范。

3. CAS 的基本原理
3.1. 結構體系
從結構體系看， CAS 包括兩部分： CAS Server 和 CAS Client 。
3.1.1. CAS Server
CAS Server 負責完成對用戶的認證工作 , 需要獨立部署 , CAS Server 會處理用戶名 / 密碼等憑證 (Credentials) 。
3.1.2. CAS Client
負責處理對客戶端受保護資源的訪問請求，需要對請求方進行身份認證時，重定向到 CAS Server 進行認證。（原則上，客戶端應用不再接受任何的用戶名密碼等 Credentials ）。
CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護受保護的資源。
3.2. CAS 原理和協議
3.2.1. 基礎模式
基礎模式 SSO 訪問流程主要有以下步驟：
1. 訪問服務： SSO 客戶端發送請求訪問應用系統提供的服務資源。
2. 定向認證： SSO 客戶端會重定向用戶請求到 SSO 伺服器。
3. 用戶認證：用戶身份認證。
4. 發放票據： SSO 伺服器會產生一個隨機的 Service Ticket 。
5. 驗證票據： SSO 伺服器驗證票據 Service Ticket 的合法性，驗證通過後，允許客戶端訪問服務。
6. 傳輸用戶信息： SSO 伺服器驗證票據通過後，傳輸用戶認證結果信息給客戶端。
下面是 CAS 最基本的協議過程：

cas基礎協議圖
基礎協議圖

如上圖： CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護 Web 應用的受保護資源，過濾從客戶端過來的每一個 Web 請求，同時， CAS Client 會分析 HTTP 請求中是否包含請求 Service Ticket( ST 上圖中的 Ticket) ，如果沒有，則說明該用戶是沒有經過認證的；於是 CAS Client 會重定向用戶請求到 CAS Server （ Step 2 ），並傳遞 Service （要訪問的目的資源地址）。 Step 3 是用戶認證過程，如果用戶提供了正確的 Credentials ， CAS Server 隨機產生一個相當長度、唯一、不可偽造的 Service Ticket ，並緩存以待將來驗證，並且重定向用戶到 Service 所在地址（附帶剛才產生的 Service Ticket ） , 並為客戶端瀏覽器設置一個 Ticket Granted Cookie （ TGC ） ； CAS Client 在拿到 Service 和新產生的 Ticket 過後，在 Step 5 和 Step6 中與 CAS Server 進行身份核實，以確保 Service Ticket 的合法性。
在該協議中，所有與 CAS Server 的交互均採用 SSL 協議，以確保 ST 和 TGC 的安全性。協議工作過程中會有 2 次重定向 的過程。但是 CAS Client 與 CAS Server 之間進行 Ticket 驗證的過程對於用戶是透明的（使用 HttpsURLConnection ）。
CAS 請求認證時序圖如下：
cas認證時序圖
3.2.1. CAS 如何實現 SSO
當用戶訪問另一個應用的服務再次被重定向到 CAS Server 的時候， CAS Server 會主動獲到這個 TGC cookie ，然後做下面的事情：
1) 如果 User 持有 TGC 且其還沒失效，那麼就走基礎協議圖的 Step4 ，達到了 SSO 的效果；
2) 如果 TGC 失效，那麼用戶還是要重新認證 ( 走基礎協議圖的 Step3) 。

3.2.2. CAS 代理模式
該模式形式為用戶訪問 App1 ， App1 又依賴於 App2 來獲取一些信息，如： User -->App1 -->App2 。
這種情況下，假設 App2 也是需要對 User 進行身份驗證才能訪問，那麼，為了不影響用戶體驗（過多的重定向導致 User 的 IE 窗口不停地閃動 ) ， CAS 引入了一種 Proxy 認證機制，即 CAS Client 可以代理用戶去訪問其它 Web 應用。
代理的前提是需要 CAS Client 擁有用戶的身份信息 ( 類似憑據 ) 。之前我們提到的 TGC 是用戶持有對自己身份信息的一種憑據，這里的 PGT 就是 CAS Client 端持有的對用戶身份信息的一種憑據。憑借 TGC ， User 可以免去輸入密碼以獲取訪問其它服務的 Service Ticket ，所以，這里憑借 PGT ， Web 應用可以代理用戶去實現後端的認證，而 無需前端用戶的參與 。
下面為代理應用（ helloService ）獲取 PGT 的過程： （註： PGTURL 用於表示一個 Proxy 服務，是一個回調鏈接； PGT 相當於代理證； PGTIOU 為取代理證的鑰匙，用來與 PGT 做關聯關系；）
cas代理PGT獲取
如上面的 CAS Proxy 圖所示， CAS Client 在基礎協議之上，在驗證 ST 時提供了一個額外的 PGT URL( 而且是 SSL 的入口 ) 給 CAS Server ，使得 CAS Server 可以通過 PGT URL 提供一個 PGT 給 CAS Client 。
CAS Client 拿到了 PGT(PGTIOU-85 … ..ti2td) ，就可以通過 PGT 向後端 Web 應用進行認證。
下面是代理認證和提供服務的過程：

如上圖所示， Proxy 認證與普通的認證其實差別不大， Step1 ， 2 與基礎模式的 Step1,2 幾乎一樣，唯一不同的是， Proxy 模式用的是 PGT 而不是 TGC ，是 Proxy Ticket （ PT ）而不是 Service Ticket 。

3.2.3. 輔助說明
CAS 的 SSO 實現方式可簡化理解為： 1 個 Cookie 和 N 個 Session 。 CAS Server 創建 cookie ，在所有應用認證時使用，各應用通過創建各自的 Session 來標識用戶是否已登錄。
用戶在一個應用驗證通過後，以後用戶在同一瀏覽器里訪問此應用時，客戶端應用中的過濾器會在 session 里讀取到用戶信息，所以就不會去 CAS Server 認證。如果在此瀏覽器里訪問別的 web 應用時，客戶端應用中的過濾器在 session 里讀取不到用戶信息，就會去 CAS Server 的 login 介面認證，但這時 CAS Server 會讀取到瀏覽器傳來的 cookie （ TGC ），所以 CAS Server 不會要求用戶去登錄頁面登錄，只是會根據 service 參數生成一個 Ticket ，然後再和 web 應用做一個驗證 ticket 的交互而已。
3.3. 術語解釋
CAS 系統中設計了 5 中票據： TGC 、 ST 、 PGT 、 PGTIOU 、 PT 。
Ø Ticket-granting cookie(TGC) ：存放用戶身份認證憑證的 cookie ，在瀏覽器和 CAS Server 間通訊時使用，並且只能基於安全通道傳輸（ Https ），是 CAS Server 用來明確用戶身份的憑證；
Ø Service ticket(ST) ：服務票據，服務的惟一標識碼 , 由 CAS Server 發出（ Http 傳送），通過客戶端瀏覽器到達業務伺服器端；一個特定的服務只能有一個惟一的 ST ；
Ø Proxy-Granting ticket （ PGT ）：由 CAS Server 頒發給擁有 ST 憑證的服務， PGT 綁定一個用戶的特定服務，使其擁有向 CAS Server 申請，獲得 PT 的能力；
Ø Proxy-Granting Ticket I Owe You （ PGTIOU ） : 作用是將通過憑證校驗時的應答信息由 CAS Server 返回給 CAS Client ，同時，與該 PGTIOU 對應的 PGT 將通過回調鏈接傳給 Web 應用。 Web 應用負責維護 PGTIOU 與 PGT 之間映射關系的內容表；
Ø Proxy Ticket (PT) ：是應用程序代理用戶身份對目標程序進行訪問的憑證；

其它說明如下：
Ø Ticket Granting ticket(TGT) ：票據授權票據，由 KDC 的 AS 發放。即獲取這樣一張票據後，以後申請各種其他服務票據 (ST) 便不必再向 KDC 提交身份認證信息 (Credentials) ；
Ø Authentication service(AS) --------- 認證用服務，索取 Credentials ，發放 TGT ；
Ø Ticket-granting service (TGS) --------- 票據授權服務，索取 TGT ，發放 ST ；
Ø KDC( Key Distribution Center ) ---------- 密鑰發放中心；

4. CAS 安全性
CAS 的安全性僅僅依賴於 SSL 。使用的是 secure cookie 。
4.1. TGC/PGT 安全性
對於一個 CAS 用戶來說，最重要是要保護它的 TGC ，如果 TGC 不慎被 CAS Server 以外的實體獲得， Hacker 能夠找到該 TGC ，然後冒充 CAS 用戶訪問 所有 授權資源。 PGT 的角色跟 TGC 是一樣的。
從基礎模式可以看出， TGC 是 CAS Server 通過 SSL 方式發送給終端用戶，因此，要截取 TGC 難度非常大，從而確保 CAS 的安全性。
TGT 的存活周期默認為 120 分鍾。
4.2. ST/PT 安全性
ST （ Service Ticket ）是通過 Http 傳送的，因此網路中的其他人可以 Sniffer 到其他人的 Ticket 。 CAS 通過以下幾方面來使 ST 變得更加安全（事實上都是可以配置的）：
1、 ST 只能使用一次
CAS 協議規定，無論 Service Ticket 驗證是否成功， CAS Server 都會清除服務端緩存中的該 Ticket ，從而可以確保一個 Service Ticket 不被使用兩次。
2、 ST 在一段時間內失效
CAS 規定 ST 只能存活一定的時間，然後 CAS Server 會讓它失效。默認有效時間為 5 分鍾。
3、 ST 是基於隨機數生成的
ST 必須足夠隨機，如果 ST 生成規則被猜出， Hacker 就等於繞過 CAS 認證，直接訪問 對應的 服務。

5. 參考資料
1、 https://wiki.jasig.org/display/CASUM/Introction
2、 http://www.jasig.org/cas/protocol/
3、 http://www.ibm.com/developerworks/cn/opensource/os-cn-cas/index.html
4、 http://www.blogjava.net/security/archive/2006/10/02/sso_in_action.html
5、 http://ke..com/view/190743.htm

Ⅵ Nginx是什麼，有什麼優點

Nginx是一個高性能的 HTTP 和 反向代理 伺服器，也是一個 IMAP/POP3/SMTP 代理伺服器。因它的穩定性、豐富的功能集、示例配置文件和低系統資源的消耗而聞名。2011年6月1日，nginx 1.0.4發布。
優點：
（1）更快
這表現在兩個方面：一方面，在正常情況下，單次請求會得到更快的響應；另一方面，在高峰期（如有數以萬計的並發請求），Nginx可以比其他Web伺服器更快地響應請求。
（2）高擴展性，跨平台
Nginx的設計極具擴展性，它完全是由多個不同功能、不同層次、不同類型且耦合度極低的模塊組成。因此，當對某一個模塊修復Bug或進行升級時，可以專
注於模塊自身，無須在意其他。而且在HTTP模塊中，還設計了HTTP過濾器模塊：一個正常的HTTP模塊在處理完請求後，會有一串HTTP過濾器模塊對
請求的結果進行再處理。這樣，當我們開發一個新的HTTP模塊時，不但可以使用諸如HTTP核心模塊、events模塊、log模塊等不同層次或者不同類
型的模塊，還可以原封不動地復用大量已有的HTTP過濾器模塊。這種低耦合度的優秀設計，造就了Nginx龐大的第三方模塊，當然，公開的第三方模塊也如
官方發布的模塊一樣容易使用。
Nginx的模塊都是嵌入到二進制文件中執行的，無論官方發布的模塊還是第三方模塊都是如此。這使得第三方模塊一樣具備極其優秀的性能，充分利用Nginx的高並發特性，因此，許多高流量的網站都傾向於開發符合自己業務特性的定製模塊。
（3）高可靠性：用於反向代理，宕機的概率微乎其微
高可靠性是我們選擇Nginx的最基本條件，因為Nginx的可靠性是大家有目共睹的，很多家高流量網站都在核心伺服器上大規模使用Nginx。
Nginx的高可靠性來自於其核心框架代碼的優秀設計、模塊設計的簡單性；另外，官方提供的常用模塊都非常穩定，每個worker進程相對獨
立，master進程在1個worker進程出錯時可以快速「拉起」新的worker子進程提供服務。

（4）低內存消耗
一般情況下，10 000個非活躍的HTTP Keep-Alive連接在Nginx中僅消耗2.5MB的內存，這是Nginx支持高並發連接的基礎。
（5）單機支持10萬以上的並發連接
這是一個非常重要的特性！隨著互聯網的迅猛發展和互聯網用戶數量的成倍增長，各大公司、網站都需要應付海量並發請求，一個能夠在峰值期頂住10萬以上並發
請求的Server，無疑會得到大家的青睞。理論上，Nginx支持的並發連接上限取決於內存，10萬遠未封頂。當然，能夠及時地處理更多的並發請求，是
與業務特點緊密相關的。
（6）熱部署
master管理進程與worker工作進程的分離設計，使得Nginx能夠提供熱部署功能，即可以在7×24小時不間斷服務的前提下，升級Nginx的可執行文件。當然，它也支持不停止服務就更新配置項、更換日誌文件等功能。
（7）最自由的BSD許可協議
這是Nginx可以快速發展的強大動力。BSD許可協議不只是允許用戶免費使用Nginx，它還允許用戶在自己的項目中直接使用或修改Nginx源碼，然後發布。這吸引了無數開發者繼續為Nginx貢獻自己的智慧。
以上7個特點當然不是Nginx的全部，擁有無數個官方功能模塊、第三方功能模塊使得Nginx能夠滿足絕大部分應用場景，這些功能模塊間可以疊加以實現
更加強大、復雜的功能，有些模塊還支持Nginx與Perl、Lua等腳本語言集成工作，大大提高了開發效率。這些特點促使用戶在尋找一個Web伺服器時
更多考慮Nginx。
選擇Nginx的核心理由還是它能在支持高並發請求的同時保持高效的服務。

Ⅶ Nginx性能調優

本文翻譯自 Tuning NGINX for Performance

Nginx以高性能 負載均衡 、 緩存 和 web伺服器 出名，支撐著世界上繁忙網站中的40%。大多數使用場景下，Nginx和Linux系統的默認配置表現較好，但是仍有必要做一些調優以期達到最佳性能。這篇文章討論當調優系統時需要考慮的一些Nginx和Linux配置。這些配置有很多，但是在本文里我們只涉及適合大多數用戶的配置。那些沒有涉及到的配置，只有那些對Nginx和Linux有深入理解的人，或者Nginx專家服務團隊推薦，才會考慮到。Nginx專家服務，已經和世界上一些繁忙網站合作來調優Nginx以達到最大限度的性能，並且可以對任何需要充分發揮系統能力的客戶提供支持。

這里假定讀者對Nginx架構和配置概念有個基本了解。本文不會重復Nginx文檔的內容，而是概述各種配置選項並提供相關文檔鏈接。

調優時，有一條較好的准則是，一次只改一個配置項，如果改後沒有性能上的提升，就退回為原先的值。

我們先討論Linux調優，因為有些值會影響在Nginx配置中可以用的值。

現代Linux內核（2.6+）能夠很好的調節各種配置，有些配置您可能想更改。如果操作系統配置太低，那麼會在內核日誌中看到錯誤信息，因此需要調節這些配置。Linux配置項很多，本文只提及那些在普通工作負載下最可能需要調優的配置項。如果需要這些配置的詳細信息，請參考Linux文檔。

以下設置與連接及其如何排隊直接相關。如果傳入的連接率很高而性能水平參差不齊，比如一些連接似乎被暫停了，那麼更改這些配置可能會有用。

文件描述符是一種操作系統資源，用來處理諸如連接和打開文件的事情。對每一個連接，Nginx可以用上多達兩個文件描述符。例如，如果Nginx用作代理，則其中一個用於客戶端連接，另一個用於連接到被代理的伺服器。如果使用了HTTP keepalive，則連接描述符的使用會少得多。對於有大量連接的系統，如下設置可能需要進行調整：

當Nginx被當作代理使用時，每一個到upstream伺服器的連接都使用一個臨時埠。

下面是一些可能影響性能的Nginx指令。如前所述，我們僅討論那些推薦大多數用戶調整的指令。這里未提及到的任何指令，如果沒有Nginx團隊的指導，不推薦更改。

Nginx可以運行多個工作進程，每個都能處理大量連接。你可以用如下指令控制工作進程個數以及連接如何被處理：

持久連接可以減少打開和關閉連接所需要的CPU和網路開銷，因而對性能有重大影響。Nginx終止所有客戶端連接，並具有到upstream伺服器的單獨連接。Nginx支持客戶端和upstream伺服器的持久連接。如下指令涉及客戶端持久連接：

如下指令涉及upstream持久連接：

為了啟用到upstream的持久連接，需要增加如下指令：

記錄每個請求需要花費CPU和IO周期，減少這種影響的一種方法是啟用access日誌緩沖。這將導致Nginx緩沖一系列日誌條目，然後一次性寫入文件而不是單個單個寫入。通過指定access_log指令的"buffer=size"選項可以打開access日誌緩沖，該設置指定要使用的緩沖區的大小。你還可以使用"flush=time"選項告訴Nginx多長時間後把緩沖區中的條目寫入文件。定義了這兩個選項後，當緩沖區放不下下一條日誌，或者緩沖區中的條目超過了flush參數指定的時間，Nginx會將緩沖區中的條目寫入日誌文件。當工作進程重新打開日誌文件或者關閉時，緩沖區中的條目也會被寫入文件。也可以完全禁用access日誌記錄。

Sendfile 是一個操作系統特性，可以在Nginx上啟用。它通過在內核中從一個文件描述符向另一個文件描述符復制數據，往往能達到 零拷貝 ，因而可以提供更快的TCP數據傳輸。Nginx可以使用該機制將緩存或者磁碟上的內容寫到socket，無需從內核空間到用戶空間的上下文切換，因而非常快並且使用較少的CPU開銷。由於數據永遠不會觸及用戶空間，所以不可能把需要訪問數據的過濾器插入到處理鏈中，不能使用任何需要改變內容的Nginx過濾器，比如gzip過濾器。Nginx默認沒有啟用該機制。

Nginx和Nginx Plus允許設置各種限制，用來控制客戶端資源消耗，以防影響系統性能以及用戶體驗和安全。以下是一些相關指令：

Nginx還有一些特性可以用來提高web應用的性能。這些特性不常出現在調優討論中，但是有必要一提，因為它們的影響也可能比較可觀。我們將討論這些特性中的兩個。

對於一個為一組web伺服器或者應用伺服器作負載均衡的Nginx實例來說，啟用緩存可以顯著地降低響應時間，同時能顯著減輕後端伺服器的負載。緩存本身就是一個主題，這里不會討論。Nginx緩存配置的更多信息請參考： Nginx管理指南 - 緩存 。

壓縮響應可以大大減小響應的大小，減少帶寬佔用。不過，這需要CPU資源來處理壓縮，所以最好在值得減少帶寬佔用的情況下使用。需要注意的是，不能對已經壓縮的東西（比如jpeg圖片）再次啟用壓縮。Nginx壓縮配置的更多信息請參考： Nginx管理指南 - 壓縮和解壓縮 。

更多信息請參考：

Ⅷ 眾多語言中，為什麼很多伺服器都選擇Nginx呢讓大佬告訴你

Nginx是一個高性能的Web和反向代理伺服器，它具有有很多非常優越的特性:

作為負載均衡伺服器 :Nginx既可以在內部直接支持Rails和PHP，也可以支持作為HTTP代

理伺服器對外進行服務。Nginx用C編寫,不論是系統資源開銷還是CPU使用效率都比

Perlbal要好的多。

作為郵件代理伺服器 :Nginx同時也是-一個非常優秀的郵件代理伺服器(最早開發這個產品的目的之-也是作為郵件代理伺服器)，Last.fm 描述了成功並且美妙的使用經驗。

Nginx安裝非常的簡單，配置文件非常簡潔(還能夠支持per語法)，Bugs非 常少的伺服器:

Nginx啟動特別容易，並且幾乎可以做到7*24不間斷運行，即使運行數個月也不需要重新啟

動。你還能夠在不間斷服務的情況下進行軟體版本的升級。

處理靜態文件，索引文件以及自動索引;

反向代理加速(無緩存)， 簡單的負載均衡和容錯;

FastCGI,簡單的負載均衡和容錯;

模塊化的結構。過濾器包括gzipping, byte ranges, chunked responses,以及SSiI-ilter 。

在SSI過濾器中，到同一個proxy或者FastCGI的多個子請求並發處理;

SSL和TLSSNI支持;

使用外部HTTP認證伺服器重定向用戶到IMAP/POP3後端;

使用外部HTTP認證伺服器認證用戶後連接重定向到內部的SMTP後端;

認證方法:

POP3: POP3 USER/PASS, APOP, AUTH LOGIN PL AIN CRAM-MD5;

IMAP: IMAP LOGIN;

SMTP: AUTH LOGIN PLAIN CRAM-MD5;

SSL支持;

在IMAP和POP3模式下的STARTTLS和STLS支持;

FreeBSD 3.x, 4.x, 5.x, 6.x i386; FreeBSD 5.x, 6.x amd64;

Linux2.2, 2.4, 2.6 i386; Linux 2.6 amd64;

Solaris 8 i386; Solaris 9 i386 and sun4u; Solaris 10 i386;

MacOS X (10.4) PPC;

一個主進程和多個工作進程。工作進程是單線程的，且不需要特殊授權即可運行;

kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), t signals (Linux 2.2.19+), /dev/poll (Solaris711/99+), select,以及poll支持;

kqueue支持的不同功能包括EV_ _CLEAR, EV_ DISABLE (臨時禁止事件)，NOTE_ _LOWAT, EV_ EOF, 有效數據的數目，錯誤代碼;

sendfile (FreeBSD 3.1+), sendfile (Linux 2.2+), sendfile64 (Linux 2.4.21+),和sendfilev(Solaris 8 7/01+)支持;

輸入過濾(FreeBSD 4.1+)以及TCP_ _DEFER_ ACCEPT (Linux2.4+)支持;

10,000 非活動的HTTP keep-alive連接僅需要2.5M內存。

最小化的數據拷貝操作;

基於IP和名稱的虛擬主機服務;

Memcached的GET介面;

支持keep-alive和管道連接;

靈活簡單的配置;

重新配置和在線升級而無須中斷客戶的工作進程;

可定製的訪問日誌，日誌寫入緩存，以及快捷的日誌回卷;

4xx-5xx錯誤代碼重定向;

基於PCRE的rewrite重寫模塊;

基於客戶端IP地址和HTTP基本認證的訪問控制;

PUT, DELETE,和MKCOL方法;

支持FLV (Flash視頻) ;

帶寬限制;

內嵌的perl

通過aio. read() 1 aio _write() 的套接字工作的實驗模塊，僅在FreeBSD下。

對線程的實驗化支持，FreeBSD 4.x的實現基於rfork()

Nginx主要的英語站點是htp://sysoev.ru/en/

本人有自己整理大數據學習的功課，閑置著也無用了。

獲取方式：

私信方式：

第一步，點擊頭像。

第二部：頭像旁邊有一個私信按鈕，發送{學習資料}即可！

Ⅸ getway不校驗白名單怎麼設置

lovenuo1314

碼齡11年

關注
1、若依後端gateway模塊配置白名單
顧名思義，就是允許訪問的地址。且無需登錄就能訪問。在ignore中設置whites，表示允許匿名訪問。

1.1、在nacos中gateway配置文件中配置


1.2、代碼
package com.ruoyi.gateway.filter;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.cloud.gateway.filter.GatewayFilterChain;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.core.Ordered;
import org.springframework.http.server.reactive.ServerHttpRequest;
import org.springframework.stereotype.Component;
import org.springframework.web.server.ServerWebExchange;
import com.ruoyi.common.core.constant.CacheConstants;
import com.ruoyi.common.core.constant.HttpStatus;
import com.ruoyi.common.core.constant.SecurityConstants;
import com.ruoyi.common.core.constant.TokenConstants;
import com.ruoyi.common.core.utils.JwtUtils;
import com.ruoyi.common.core.utils.ServletUtils;
import com.ruoyi.common.core.utils.StringUtils;
import com.ruoyi.common.redis.service.RedisService;
import com.ruoyi.gateway.config.properties.IgnoreWhiteProperties;
import io.jsonwebtoken.Claims;
import reactor.core.publisher.Mono;

/**
* 網關鑒權
*
* @author ruoyi
*/
@Component
public class AuthFilter implements GlobalFilter, Ordered
{
private static final Logger log = LoggerFactory.getLogger(AuthFilter.class);

// 排除過濾的 uri 地址，nacos自行添加
@Autowired
private IgnoreWhiteProperties ignoreWhite;

@Autowired
private RedisService redisService;

@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain)
{
ServerHttpRequest request = exchange.getRequest();
ServerHttpRequest.Builder mutate = request.mutate();

String url = request.getURI().getPath();
// 跳過不需要驗證的路徑
if (StringUtils.matches(url, ignoreWhite.getWhites()))
{
return chain.filter(exchange);
}
String token = getToken(request);
if (StringUtils.isEmpty(token))
{
return unauthorizedResponse(exchange, "令牌不能為空");
}
Claims claims = JwtUtils.parseToken(token);
if (claims == null)
{
return unauthorizedResponse(exchange, "令牌已過期或驗證不正確！");
}
String userkey = JwtUtils.getUserKey(claims);
boolean islogin = redisService.hasKey(getTokenKey(userkey));
if (!islogin)
{
return unauthorizedResponse(exchange, "登錄狀態已過期");
}
String userid = JwtUtils.getUserId(claims);
String username = JwtUtils.getUserName(claims);
if (StringUtils.isEmpty(userid) || StringUtils.isEmpty(username))
{
return unauthorizedResponse(exchange, "令牌驗證失敗");
}

// 設置用戶信息到請求
addHeader(mutate, SecurityConstants.USER_KEY, userkey);
addHeader(mutate, SecurityConstants.DETAILS_USER_ID, userid);
addHeader(mutate, SecurityConstants.DETAILS_USERNAME, username);
// 內部請求來源參數清除
removeHeader(mutate, SecurityConstants.FROM_SOURCE);
return chain.filter(exchange.mutate().request(mutate.build()).build());
}

private void addHeader(ServerHttpRequest.Builder mutate, String name, Object value)
{
if (value == null)
{
return;
}
String valueStr = value.toString();
String valueEncode = ServletUtils.urlEncode(valueStr);
mutate.header(name, valueEncode);
}

private void removeHeader(ServerHttpRequest.Builder mutate, String name)
{
mutate.headers(httpHeaders -> httpHeaders.remove(name)).build();
}

private Mono<Void> unauthorizedResponse(ServerWebExchange exchange, String msg)
{
log.error("[鑒權異常處理]請求路徑:{}", exchange.getRequest().getPath());
return ServletUtils.webFluxResponseWriter(exchange.getResponse(), msg, HttpStatus.UNAUTHORIZED);
}

/**
* 獲取緩存key
*/
private String getTokenKey(String token)
{
return CacheConstants.LOGIN_TOKEN_KEY + token;
}

/**
* 獲取請求token
*/
private String getToken(ServerHttpRequest request)
{
String token = request.getHeaders().getFirst(TokenConstants.AUTHENTICATION);
// 如果前端設置了令牌前綴，則裁剪掉前綴
if (StringUtils.isNotEmpty(token) && token.startsWith(TokenConstants.PREFIX))
{
token = token.replaceFirst(TokenConstants.PREFIX, StringUtils.EMPTY);
}
return token;
}

@Override
public int getOrder()
{
return -200;
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
package com.ruoyi.gateway.config.properties;

import java.util.ArrayList;
import java.util.List;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.cloud.context.config.annotation.RefreshScope;
import org.springframework.context.annotation.Configuration;

/**
* 放行白名單配置
*
* @author ruoyi
*/
@Configuration
@RefreshScope
@ConfigurationProperties(prefix = "security.ignore")
public class IgnoreWhiteProperties
{
/**
* 放行白名單配置，網關不校驗此處的白名單
*/
private List<String> whites = new ArrayList<>();

public List<String> getWhites()
{
return whites;
}

public void setWhites(List<String> whites)
{
this.whites = whites;
}
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
啟動代碼並測試

已經走到了sytem模塊中，並且沒有進行登錄；說明我們的配置已經生效

文章知識點與官方知識檔案匹配
Java技能樹首頁概覽
84637 人正在系統學習中
打開CSDN，閱讀體驗更佳

Amazon API Gateway使用IP白名單控制後端服務訪問_亞林瓜子的博客-CSD...
異地IP驗證 使用移動IP調用,請求被拒絕了。 白名單IP驗證 同樣的請求,在白名單中的IP就可以正常請求。 總結 這里使用的AWS中國北京地區的API Gateway服務,通過策略控制對後台服務的訪問控制。
SpringCloud Gateway網關配置(二)介面訪問IP白名單配置(真實IP)
SpringCloud Gateway網關配置中,需要對訪問的IP設置白名單,SpringCloud Gateway官方給出YML配置文件配置。 如下: 5.10. The RemoteAddr Route Predicate Factory The RemoteAddr route predicate factory takes a list (min size 1) of so...
Spring Cloud Gateway 網關實現白名單功能
對於微服務後台而言，網關層作為所有網路請求的入口。一般基於安全考慮，會在網關層做許可權認證，但是對於一些例如登錄、注冊等介面以及一些資源數據，這些是不需要有認證信息，因此需要在網關層設計一個白名單的功能。本文將基於 Spring Cloud Gateway 2.X 實現白名單功能。注意事項: Gateway 網關層的白名單實現原理是在過濾器內判斷請求地址是否符合白名單，如果通過則跳過當前過濾器。如果有多個過濾器，則需要在每一個過濾器里邊添加白名單判斷。......
繼續訪問
若依vue分離版（ruoyi-vue）跳過token驗證，設置白名單
找到SecurityConfig類的configure方法 如圖所示 在設置白名單後還需要把介面上的許可權標識符去掉。然後需要重啟一下項目，熱載入不行，會報錯。
繼續訪問

Kong Gateway - 13 基於網關服務的IP白名單限制訪問(Whitelist IP Restri...
為名稱為book的服務的路由{route_id啟用IP白名單限制訪問其中192.168.10.50表示限制macOS系統這一台計算機不能訪問book服務的路由其中192.168.43.0/24表示限制IP地址是192.168.43這一整個網段的IP都不能訪問book服務的路由(Windows 10在此...
服務網關:Gateway_青銅造白的博客
可以實現日誌攔截、許可權控制、解決跨域、限流、熔斷、負載均衡,隱藏服務端的ip,黑名單與白名單攔截、授權等。 二:gateway的核心概念 1、Route(路由):就是轉發規則 Spring Cloud Gateway的基礎元素,可簡單理解成一條轉發的規則。包含:ID...
SpringCloud Gateway網關配置（二）介面訪問IP白名單配置（真實IP）
SpringCloud Gateway網關配置中，需要對訪問的IP設置白名單，SpringCloud Gateway官方給出YML配置文件配置。 如下： 5.10. The RemoteAddr Route Predicate Factory The RemoteAddr route predicate factory takes a list (min size 1) of sources, which are CIDR-notation (IPv4 or IPv6) strings, such as 1
繼續訪問
nacos許可權認證(二) 開啟許可權認證
直接設置下述屬性為true，就可以避免 nacos許可權認證(一) 中的問題。 這個時候再訪問nacos頁面，則會直接報錯。因此，還需要再設置兩個屬性（數值可以隨便填）。添加好這兩個屬性時頁面就能正常訪問了。注意：如果你遇到這種情況，只需要關閉提示，點擊用戶名，登出，然後重新登錄即可。這個時候，如果你加修改直接啟動其他服務，則其他服務無法正常連接nacos，也需要坐一番配置。需要再其他服務的配置文件中加上如下配置。 這樣，其他服務就能正常連接nacos了。至此，nacos的許可權漏洞問題就解決了。
繼續訪問

若依RuoYi-Cloud代碼學習三---ruoyi-gateway擴展gateway網關組件的知識
一、API 網關概述 作為微服務的門面，應用於服務數量眾多、復雜度較高、規模比較大的系統。 優點： 客戶端通過 API 網關與微服務交互時，客戶端只需要知道 API 網關地址即可，而不需要維護大量的服務地址，簡化了客戶端的開發。 客戶端直接與 API 網關通信，能夠減少客戶端與各個服務的交互次數。 客戶端與後端的服務耦合度降低。 節省流量，提高性能，提升用戶體驗。 API 網關還提供了安全、流控、過濾、緩存、計費以及監控等 API 管理功能。 常見API 網關實現方案 Spring Cloud G
繼續訪問
熱門推薦 GateWay中添加白名單
最近開發中有一個鑒權的操作，最後需要進行添加白名單的，廢話不多說，直接上代碼吧， 這是我的項目結構 applicaton啟動類： import org.springframework.boot.SpringApplication; import org.springframework.cloud.client.SpringCloudApplication; import org.spr...
繼續訪問

Spring Gateway+白名單+docker
域名解析 從物理機上調用外部服務正常，但是docker里的java服務去調用卻有問題。 答案 docker並不能使用宿主機的host配置信息 為每一個http請求定製header 如果在RouteLocatorBuilder里設置header的話就會對所有http request生效，如果為了對每個request請求使用不同header需要如下設置 @Configuration public cl...
繼續訪問
GateWay網關應用案例(跨域、限流、黑白名單)
Spring Cloud Gateway是基於Spring Boot 2.x，Spring WebFlux和Project Reactor 構建的。屬於非同步非阻塞架構 Spring Cloud Gateway與Spring Data 和Spring Securit 技術不能同時使用 Spring Cloud Gateway基於Spring Boot和Spring Webflux提供的Netty運行。它在傳統的Servlet容器中或用WAR的方式構建時不起作用 網關基本的功能 ：鑒權、流量控制、熔斷、路徑重寫
繼續訪問

ruoyi分離版前端白名單
ruoyi分離版前端白名單 先在router下的index.js中加上需要添加的路由 之後再permission.js下的whiteList中加上上面添加的路由就可以了 後端的介面 介面白名單 /**是匹配路徑下的所有介面，也可以直接指定某一個具體的介面 ...
繼續訪問
若依後端gateway模塊解決跨域問題
跨域問題
繼續訪問

微服務項目在gateway網關配置路徑訪問白名單
網關的鑒權：許可權身份認證作用實際上就是由一串組合起來的過濾器實現的, 過濾器的自定義過程就是實現兩個介面org.springframework.cloud.gateway.filter.GlobalFilter和org.springframework.core.Ordered 通過重寫org.springframework.cloud.gateway.filter.GlobalFilter中的filter方法來定義過濾的邏輯 通過重寫org.springframework.core.Ordered中的get
繼續訪問
若依微服務SpringCloud—使用Spring Cloud Gateway網關
一.API網關 API網關，就是指系統的統一入口，它封裝來應用程序的內部結構，為客戶端提供統一服務，一些與業務本身功能無關的公共邏輯可以在這里實現，諸如認證，鑒權，監控，路由轉發等等。 二.業界流行的網關 （1)Ngnix+lua ：使用nginx的反向代理和負載均衡可實現api伺服器的負載均衡及高可用。lua是一種腳步語言，可以來編寫一些簡單的nginx支持lua腳本。 （2）Kong：基於Nginx+Lua開發，性能高，穩定，有多個可用的插件（限流，鑒權等等）可以開箱即用。缺點：只支持http協
繼續訪問

最新發布 若依前後端分離ruoyi-vue請求添加白名單403
【代碼】若依前後端分離ruoyi-vue請求添加白名單403。
繼續訪問

Nacos配置與踩坑總結
核心問題： 1.不同域名，走不同配置 2.開關、配置、JSON三種配置類型 解決方案 設計思路： 1.分三大類： 業務配置、域名配置、域名自定義配置 業務配置：用於配置所有業務中的配置信息 針對業務情況，分為三類業務配置：開關配置、基礎配置、數據配置(黑/白名單) 每種配置都為單獨的nacos 針對大促情況：將三類配置各自再兩個環境配置，共三個環境配置，方便在不同配置環境中自由切換 域名配置：用於配置域名走哪個配置環境，實現出現問題快速將某域名切換到不同環境 域
繼續訪問

微服務網關springcloud gateway自定義全局過濾器
微服務網關springcloud gateway自定義全局過濾器
繼續訪問
ruoyi-spring boot 升級為nacos配置
springboot集成nacos
繼續訪問
若依Cloud之旅（二）：一次登錄到出現界面，若依做了什麼？
若依一次登錄到出現界面的三個介面都做了什麼
繼續訪問

實現登錄驗證
最近練習搭建了一個後台管理系統,首先第一步做了關於驗證登錄的功能.以下項目使用了Nacos作為服務發現和注冊中心,將Auth和gateway,system等相關多個微服務注冊進Nacos.每次刷新登錄頁面,就會獲取新的驗證碼(,輸入正確的驗證碼即可成功跳轉至首頁. 獲取驗證碼url:http://localhost/dev-api/code - dev-api是前端設置的反向代理,實際訪問的是網關路徑和埠.即在網關gateway模塊做了路由轉發.返回給前端 /** * 路由轉發...
繼續訪問
若依前後端分離-免登錄
項目需要對若依進行不輸入賬號密碼的登錄，所以臨時進行修改，增加獲取不到token時，判斷是否攜帶了某個特殊參數，有就用默認的賬號密碼調用登錄達到驗證登錄的需求。 http://localhost/#/?index=1 // 沒有token if (whiteList.indexOf(to.path) !== -1) { // 在免登錄白名單，直接進入 next() } else if (to.query.index === '1') { let..
繼續訪問

gateway白名單
gateway