今天就跟大家聊聊有關(guān)使用nginx反向代理怎么解決Cookie跨域問題,可能很多人都不太了解,為了讓大家更加了解,小編給大家總結(jié)了以下內(nèi)容,希望大家根據(jù)這篇文章可以有所收獲。
成都創(chuàng)新互聯(lián)公司是專業(yè)的納溪網(wǎng)站建設(shè)公司,納溪接單;提供網(wǎng)站制作、做網(wǎng)站,網(wǎng)頁設(shè)計,網(wǎng)站設(shè)計,建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進行納溪網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!一、前言
隨著項目模塊越來越多,很多模塊現(xiàn)在都是獨立部署。模塊之間的交流有時可能會通過cookie來完成。比如說門戶和應(yīng)用,分別部署在不同的機器或者web容器中,假如用戶登陸之后會在瀏覽器客戶端寫入cookie(記錄著用戶上下文信息),應(yīng)用想要獲取門戶下的cookie,這就產(chǎn)生了cookie跨域的問題。
二、介紹一下cookiev
cookie路徑:
cookie 一般都是由于用戶訪問頁面而被創(chuàng)建的,可是并不是只有在創(chuàng)建 cookie 的頁面才可以訪問這個cookie。在默認情況下,出于安全方面的考慮,只有與創(chuàng)建 cookie 的頁面處于同一個目錄或在創(chuàng)建cookie頁面的子目錄下的網(wǎng)頁才可以訪問。那么此時如果希望其父級或者整個網(wǎng)頁都能夠使用cookie,就需要進行路徑的設(shè)置。
path表示cookie所在的目錄,asp.net默認為/,就是根目錄。在同一個服務(wù)器上有目錄如下:/test/,/test/cd/,/test/dd/,現(xiàn)設(shè)一個cookie1的path為/test/,cookie2的path為/test/cd/,那么test下的所有頁面都可以訪問到cookie1,而/test/和/test/dd/的子頁面不能訪問cookie2。這是因為cookie能讓其path路徑下的頁面訪問。
讓這個設(shè)置的cookie 能被其他目錄或者父級的目錄訪問的方法:
document.cookie = "name = value; path=/";
cookie 域:
domain表示的是cookie所在的域,默認為請求的地址,如網(wǎng)址為www.jb51.net/test/test.aspx,那么domain默認為www.jb51.net。而跨域訪問,如域A為t1.test.com,域B為t2.test.com,那么在域A生產(chǎn)一個令域A和域B都能訪問的cookie就要將該cookie的domain設(shè)置為.test.com;如果要在域A生產(chǎn)一個令域A不能訪問而域B能訪問的cookie就要將該cookie的domain設(shè)置為t2.test.com。
三、解決cookie跨域問題之nginx反向代理
反向代理概念
反向代理(Reverse Proxy)方式是指以代理服務(wù)器來接受Internet上的連接請求,然后將請求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器;并將從服務(wù)器上得到的結(jié)果返回給Internet上請求連接的客戶端,此時代理服務(wù)器對外就表現(xiàn)為一個服務(wù)器。
反向代理服務(wù)器對于客戶端而言它就像是原始服務(wù)器,并且客戶端不需要進行任何特別的設(shè)置??蛻舳讼蚍聪虼?的命名空間(name-space)中的內(nèi)容發(fā)送普通請求,接著反向代理將判斷向何處(原始服務(wù)器)轉(zhuǎn)交請求,并將獲得的內(nèi)容返回給客戶端,就像這些內(nèi)容 原本就是它自己的一樣。
場景模擬
兩個工程web1,web2,部署在同一臺機器上的不同tomcat上,請求web1工程的index.html,如下:
然后點擊鏈接請求web2工程的index.jsp,內(nèi)容如下:
再看一下nginx的配置,如下:
worker_processes 2; events { worker_connections 65535; } http { include mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; server_names_hash_bucket_size 128; client_header_buffer_size 32k; large_client_header_buffers 4 32k; client_body_buffer_size 8m; server_tokens off; ignore_invalid_headers on; recursive_error_pages on; server_name_in_redirect off; sendfile on; tcp_nopush on; tcp_nodelay on; #keepalive_timeout 0; keepalive_timeout 65; upstream web1{ server 127.0.0.1:8089 max_fails=0 weight=1; } upstream web2 { server 127.0.0.1:8080 max_fails=0 weight=1; } server { listen 80; server_name 127.0.0.1; charset utf-8; index index.html; location /web/web1 { proxy_pass http://web1/web1; proxy_set_header Host 127.0.0.1; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Cookie $http_cookie; log_subrequest on; } location /web/web2 { proxy_pass http://web2/web2; proxy_set_header Host 127.0.0.1; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Cookie $http_cookie; log_subrequest on; } location /nginxstatus { stub_status on; access_log on; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } } }