當前位置:首頁 » 網頁前端 » hash路由與web容器有關嗎
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

hash路由與web容器有關嗎

發布時間: 2023-04-02 06:22:23

⑴ 記錄用qiankun微前端改造 路由hash模式

最近來了個新項目,老系統升級。老系統本身是個很多應用混畢飢在一起的一個公眾號應用。因為歷史原因很雜。現在要開始一點點升級。很多子模塊不能一次完成升級,所以是新老應用並行的情況,我就想到了粗睜用微前端改造。手凳返

我選擇的是 qiankun 這個輪子。主應用、微應用 都選擇的是 vue2.x (因為老項目都是vue開發,qiankun可以兼容所有框架) 。路由模式都是選擇的hash。 但是history模式更優雅一點。但是需要伺服器端配置。

b. 注冊微應用入口

b. 修改main.js

c. 修改webpack配置

⑵ 從源碼理解總結web容器、spring容器、spring mvc容器三者關系

本篇,我打算從springMVC項目的web.xml的配置文件入手,通過部分源碼逐步去理解解釋三個容器的關系以及調用順序,因為是基於我個人的理解,可能有所不足。

一般web.xml文件里會有如下兩段配置信息:

我們先了解下web.xml,以下引用自 《web.xml文件是什麼?有什麼用?--詳解》 :

然後結合我們上面的web.xml中關於spring和spring mvc的配置信息來進入話題:

    首先,啟動web容器的時,會先生成對應項目的ServelContent對象,這個是每個項目的上下文,這個ServelContent可以管理所有的servlet,並將我們web.xml中設置的<context-param>內容作為鍵值對交給這個對象。

    然後載入<listener>標簽內容,這個時候就會產生org.springframework.web.context.ContextLoaderListener。

spring的這個 ContextLoaderListener 在接下來的過程中很重要,我們來看一下源碼

首先,可以看出它繼承了ContextLoader類,並實現了ServletContextListener介面。

這里再直接引用他人的結論   《Spring中ContextLoaderListener作用》

好了,人家說法中回到我們的起點了,我們基本都被人告知「ContextLoaderListener的作用是創建並初始化spring容器」

那我們就可以深入進去看看,到底哪裡做了這一步:

首先,我們知道了ServletContextListene是ServletContext的監聽者,監聽器的響應動作就是在伺服器啟動時contextInitialized會被調用,關閉的時候contextDestroyed被調用,這個好理解,那我們就來看一下ContextLoaderListener重寫的contextInitialized方法到底做了什麼。

我們再進入觀察initWebApplicationContext方法細看

我因為自己消化過一遍,直接給出關鍵位置的方法說明——

1、首先是278行:創建了WebApplicationContext,我們可以理解為spring容器的殼子有了

2、其次是288和289行:對ApplicationContext載入了配置文件,並設置servletContext為WebApplicationContext的parent,到這一步,可以理解為我們的spring容器也就差不多成型了

3、接下來是294行:把ApplicationContext對象以鍵值對的形式存到servletContext中,這一步很關鍵,就是因為servletContext中存在這個鍵值對,所以其他內部成員可以通過servletContext訪問到ApplicationContext,當然也能使用其管理的bean,而spring mvc則沒有這樣存在servletContext,所以我覺得正是這一步決定了子容器springmvc可以取用父容器內的bean,反著則不然。

接下來直到輪到我們的springmvc容器<servlet>標簽內容

會生成控制org.springframework.web.servlet.DispatcherServlet,這是一個前端控制器,主要的內容我之前也有一篇文章做過自我記錄

《Spring MVC的工作機制簡單理解》

我們可以看到設置的

<load-on-startup>1</load-on-startup>

這個標簽大概意思就是:

1、load-on-startup 元素標記容器是否應該在web應用程序啟動的時候就載入這個servlet,(實例化並調用其init()方法)。

2、它的值必須是一個整數,表示servlet被載入的先後順序。

3、如果該元素的值為負數或者沒有設置,則容器會當Servlet被請求時再載入。

4、如果值為正整數或者0時,表示容器在應用啟動時就載入並初始化這個servlet,值越小,servlet的優先順序越高,就越先被載入。值相同時,容器就會自己選擇順序來載入。

在DispatcherServlet的時候就根據springMVC容器容器的配置文件生成。

比如我這邊就是

那順序確定了,我們再看一下spring和spring mvc的父子關系哪裡確定:

我們可以從下面3個截圖看到dispatcherServlet的繼承關系,同時,init方法用的是dispatcherServlet父類的父類的方法。

重點在於initServletBean()方法,經過追蹤,我們找到該方法的最終實現又是在dispatcherServlet的父類FrameworkServlet中

其中涉及父子關系的實際是在219行的initWebApplicationContext()方法

initWebApplicationContext()方法主要用於創建或刷新WebApplicationContext實例,並對Servlet功能所使用的變數進行初始化。

從238行源碼就可以看到,它獲得ContextLoaderListener中初始化的rootContext,

在246行設置了父子關系的引用,也就是從這一點我們看到了spring和springMVC的父子關系!

並且,可以看到這只是一條單向的引用,spring中沒有引用直接指向springMVC,也就是子類能找到父類,然而父類都不知道這個子類,父子容器之間內部對象調用關系更明了。

再通過構造函數和Servlet的contextAttribute屬性查找ServletContext來進行webApplicationContext實例的初始化,最終。

這個方法內263行源碼onRefresh(wac)方法是FrameworkServlet提供的模板方法,在子類,也就是我們的DispatcherServlet的onRefresh()方法中進行了重寫。而在onRefresh()方法中調用了initStrategies()方法來完成初始化工作,初始化Spring MVC的9個組件。

1、Tomcat在啟動時給每個Web應用創建一個全局的上下文環境,這個上下文就是ServletContext,其為後面的Spring容器提供環境。

2、Tomcat在啟動過程中觸發容器初始化事件,Spring的ContextLoaderListener會監聽到這個事件,它的contextInitialized方法會被調用,在這個方法中,Spring會初始化全局的Spring根容器,這個就是Spring的IoC容器,IoC容器初始化完畢後,Spring將其存儲到ServletContext中,便於以後來獲取。

3、Tomcat在啟動過程中還會掃描Servlet,一個Web應用中的Servlet可以有多個,以SpringMVC中的DispatcherServlet為例,這個Servlet實際上是一個標準的前端控制器,用以轉發、匹配、處理每個Servlet請求。

4、Servlet會在容器啟動時載入或延遲載入(根據啟動級別設置數字)。延遲載入時,當第一個請求達到時,serlet容器發現對應Servlet還沒有被實例化,就調用Servlet的init方法。

在spring MVC里

        DispatcherServlet在初始化的時候會建立自己的容器,叫做SpringMVC 容器,用來持有Spring MVC相關的Bean。同時,Spring MVC還會通過ServletContext拿到Spring根容器,並將Spring根容器設為SpringMVC容器的父容器,請注意,Spring MVC容器可以訪問父容器中的Bean,但是父容器不能訪問子容器的Bean, 也就是說Spring根容器不能訪問SpringMVC容器里的Bean。

        說的通俗點就是,在Controller里可以訪問Service對象,但是在Service里不可以訪問Controller對象。

⑶ web容器有幾種作用域如何防止sql注入

所謂SQL注入,就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字元串,最終達到欺騙伺服器執行惡意的SQL命令。具體來說,它是利用現有應用程序,將(惡意)的SQL命令注入到後台資料庫引擎執行的能力,它可以通過在Web表螞賀高單中輸入(惡意)SQL語句得到一個存在安全漏洞的網站上的資料庫,而不是按照設計者意圖去執行SQL語句。比如先前的很多影視網站泄露VIP會員密碼大多就是通過WEB表單遞交查詢字元暴出的,這類表單特別容易受到SQL注入式攻擊.
防護
歸納一下,主要有以下幾點:
1.永遠不要信任用戶的輸入。對用戶的輸入進行校驗,可以通過正則表達式,或限制長度;對單引號和
雙"-"進行轉換等。
2.永遠悶尺不要使用動態拼裝sql,可以使用參數化的sql或者直接使用存儲過程進行數據查詢存取。
3.永遠不要使用管理員許可權的資料庫連接,為每個應用使用單獨的許可權有限的資料庫連接。
4.不要把機密信息直接存放,加密或者hash掉密碼和敏感的信息。
5.應用的異常信息應該給出盡可能少的提示,最好使用自定義的錯誤信息對原始錯誤信息進行包拍肆裝
6.sql注入的檢測方法一般採取輔助軟體或網站平台來檢測,軟體一般採用sql注入檢測工具jsky,網站平台就有億思網站安全平台檢測工具。MDCSOFT SCAN等。採用MDCSOFT-IPS可以有效的防禦SQL注入,XSS攻擊等。

⑷ 路由模式(hash、history)

history:不帶#/ 利用html5 的 history.pushState API 來完成URL跳轉,而無需重新載入頁培遲面 好看 正常的URL http://user/id

hash:帶#/ 通過錨點值來實現的路由跳轉

區別:

2.hash 採用的是亂宏通過錨點值來實現的配陪李路由跳轉,history 模式 採用html5 的 history.pushState API 來完成URL跳轉

3.history模式 需要後端配合,因為刷新頁面 會404

4.hash模式 支持IE 7、8,history模式 支持IE 10

⑸ 了解什麼是hash路由和history路由

hash 路由:監聽 url 中 hash 的變化,然後渲染不同的內容,這種路由不向伺服器發送請求,不需要服務端的支持;
history 路由:監聽 url 中的路徑變化,需要客戶端和服務端共同的支持;
我們一步步實現這兩種路由,來深入理解下底層的實現原理。我們主要實現以下幾個簡單的功能:

1.監聽路由的變化,當路由發生變化時,可以作出動作;
2.可以前進或者後退;
3.可以配置路由;

當頁面中的 hash 發生變化時,會觸發hashchange事件,因此我們可以監聽這個事件,來判斷路由是否發生了變化。

事件hashchange只會在 hash 發生變化時才能觸發,而第一次進入到頁面時並不會觸發這個事件,因此我們還需要監聽load事件。

在 history 路由中,我們一定會使用window.history中的方法,常見的操作有:

back():後退到上一個答檔氏路由;
forward():前進到下一個路由,如果有的話;
go(number):進入到任意一個路由,正數為前進,負數為後退;
pushState(obj, title, url):前進到指定的 URL,不刷新頁面;
replaceState(obj, title, url):用 url 替換當前的路由,不刷新頁面;
調用這幾種方式時,蠢歲都會只是修改了當前頁面的 URL,頁面的內容沒有任何的變化。但前 3 個方法只是路由歷史記錄的前進或者後退,無法跳轉到指定的 URL;而pushState和replaceState可以跳轉到指定的 URL。如果有面試官問起這個問題「如何僅修改頁面的 URL,而不發送請求」,那麼答案就是這 5 種方法。

如果服務端沒有新更新的 url 時,一刷新瀏覽器就會報錯,因為刷新瀏覽器後,是真實清散地向伺服器發送了一個 http 的網頁請求。因此若要使用 history 路由,需要服務端的支持。

當我們用 history 的路由時,必然要能監聽到路由的變化才行。全局有個 popstate 事件,別看這個事件名稱中有個 state 關鍵詞,但 pushState 和 replaceState 被調用時,是不會觸發觸發 popstate 事件的,只有上面列舉的前 3 個方法會觸發

針對這種情況,我們可以使用 window.dispatchEvent 添加事件:

然後就可以添加對這兩個方法的監聽了:

⑹ vue路由(一、二級路由)

是前台為了者吵實現單頁面應用然後設置路徑,根據不同的路徑顯示不同頁面。但是這些路徑在伺服器上不是真是存在的

hash路由 默認的是hash路由
history路由

通過onhashchange()來檢測路由的變化,根據不同的hash來顯示不同元素。獲取當前的hash值location.hash

通過onpopstate來檢測history堆棧路徑的變化,堆棧的路徑是通過history.pushState(null, '',"?page=2")添加進去的

由hash路由設置成history路由,給路由添加配置項 mode="history"

1、設置相應組件
2、在router->index.js文件中添加配置
首先引入組件,然後配置規則 {path:設置路徑,name:名,component:組件}

3、在需要現在組件的地方給頁面添加<router-view></router-view>

4、設置導航路徑
使用vue提供 <router-link to="路徑"></router-link> 默認的解析成a標簽

5、設置默認路由

6、設置導航樣式

1、需要定義組件
2、確晌慶定好在那個組件配置二級路由,就去那個組件的配置規則中添加children關鍵字,按照一級路由的配置方法配置規則

3、在需要配置二級路由的組件中添加router-view
4、設置導航 <router-link to="/ / ">

5、設置導航鏈接的樣式

我們可以定義一個一級路由,裡面可以包裹底部footer組件,讓他宴嫌握為二級路由,這時點擊底部的二級路由時,就會切換不同的頁面,而不需要底部組件顯示的時候,那我們在配置一個一級路由就好了!!!

⑺ 什麼叫web容器以及作用

tomcat 是SERVLET的容器。

web 容器就是實現了JAVA的那些介面:javax.servlet。
而且JSP也是SERVLET的

web 容器啟動後一直運行,監聽所有提交到他所監控的那個埠的請求,並對此做出反映。

個人理解, 之前有看過人家別人寫的web容器的例子, 不過忘記了,如果你寫深入理解, 自己搜索把。

⑻ web容器中有哪些重要的作用域,並說出自己的理解

web容器的四大作用域:pageContext, request, session、application四個作用域中
1、如果把變數放到pageContext里,就說明它的作用域是page,它的有效范圍只在當前jsp頁面里。
從把變數放到pageContext開始,到jsp頁面結束,你都可以使用這個變數。
2、如果把變數放到request里,就說明它的作用域是request,它的有效范圍是當前請求周期。所謂請求周期,就是指從http請求發起,到伺服器處理結束,返回響應的整個過程。在這個過
程中可能使用forward的方式跳轉帆鉛逗了多個jsp頁面,在這些頁面里你都可以使用這個變數。
3、如果把變數放到session里,就說明它的作用域是session,它的有效范圍是當前會話。所謂當前會話,就是指從用戶打開瀏覽器激山開始,到用戶關閉瀏覽器這中間的過程。這個過程可能包含多個請求響應。也就是說,只要用戶不關瀏覽器,伺服器就有辦法知道這些請求是一個人發起的,整個過程被稱為一個會話(session),而放到會話中的變數,
4、如果把變數放到application里,就說明它的作用域是application,它的有效范圍是整個應用。整個應用是指從應用啟動,到應用結束。我們沒有說「從伺服器啟動,到伺服器關閉」是因為一個伺服器可能部署多個應用,當然你關閉了伺服器,就會把上面所有的應用都關閉了。application作用域里的變數,它們的存活時間是最長的,如果不進行手工刪除,它們就一直可以使用。與上述三個不同的是,application里的變數可以被所有用戶共用。如果用戶甲的操作修改了application中的變數,用戶乙訪問時得態賣到的是修改後的值。這在其他scope中都是不會發生的,page,
request, session都是完全隔離的,無論如何修改都不會影響其他

⑼ vue路由hash和history

SPA ,即 單頁面應用 (Single Page Application)。就是只有一張 web頁面的應用。單頁應用程序 (SPA) 是載入單個html頁面並在 用戶與應用程序交互時 動態更新該頁面的web應用程序。瀏覽器一開始會載入必需的html、css和 js ,所有的操作都在這張頁面上完成,都由js來控制

對於現代開發的項目來說,稍微復雜一點的SPA,都需要用到 路由 。而 vue-roter 正是 vue 的路由標配,且 vue-router 有 兩種模式 : hash 和 history 。

hash 模式是一種把前端路由的路徑用井號 # 拼接在真實 url 後面的模式。當井號 # 後面的路徑發生變化時,瀏覽器並不會重新發起請求,而是會觸發 onhashchange 事件。

下面用一個網址來演示以上屬性:

history API 是 H5 提供的新特性,允許開發者 直接更改前端路由 ,即更新瀏覽器 URL 地址而 不重新發起請求

hash 與 history 在瀏覽器下刷新時的區別:

正常頁面瀏覽

改造H5 history模式

HTML5新增的API:

主要有以下特點:

對於 history 來說,確實解決了不少 hash 存在的問題,但是也帶來了新的問題:

在實際的項目中,如何對這兩者進行選擇:

⑽ router(History,hash)前端路由機制

前端路由機制
前端路由,顧名思義就是一個前端不同頁面的狀態管理器,可以不向後台發送請求而直接通過前端技術實現多個頁面的效果。

前端路由機制原理及兩種實現方式
一、History
History 介面允許操作瀏覽器的曾經在標簽頁或者框架里訪問的會話歷史記錄。
用戶訪問網頁的歷史記錄通常會被保存在一個類似於棧對象中,即history對象:

history 對象包含用戶(在瀏覽器窗口)訪問過的url
history對象是window對象的一部分,可以通過window.history屬性進行訪問。
基本的API用法如back、forward、go不做多解釋,可以參考MDN
重點解釋html5新增的API:
1、history.pushState() //在history對象中添加一條新的瀏覽記錄
2、History.replaceState() // 是替換history中的當前記錄
3、history.state //是一個屬性,可以得到當前頁的state信息。
4、window.onpopstate //是一個事件,在點擊瀏覽器後退按鈕或js調用forward()、back()、go()時觸發。
(和它相似的一個方法叫做onhashchange,onhashchange是老API, 瀏覽器支持度高, 本來是用來監
聽hash變化的, 但可以被利用來做客戶端前進和後退事件的監聽,onpopstate是專門用來監聽瀏覽器
前進後退的, 不僅可以支持hash, 非hash的同源url也支持。)

history.pushState與History.replaceState的區別
history.pushState和History.replaceState都接收三個參數:即(data[,title][,url])
狀態對象(state Object):一個object,與pushState方法創建的新歷史記錄條目關聯。
標題:一般傳null
地址(url):新的歷史記錄條目的地址。
pushState和replaceState都會操作瀏覽器的歷史記錄,並且不會引起頁面的刷新。
不同之處在與:一個新增,一個替換。
History 模式是 HTML5 新推出的功能,比之 Hash URL 更加美觀

一、hash
我們經常看到在url中出現#符號,這個在路由中出現的#,叫做hash,很多大型框架的路由系統都是由hash實現的。
上面提到一個方法onhashchange事件,用來監聽hash變化,也可以被利用來做客戶端前進和後退事件的監聽。