tomcat資料庫加密

⑴ tomcat如何配置

需要做的就是：按照你的需求配置Tomcat，只要你正確配置，Tomcat一般都能適合你的要求。下面是一系列關於Tomcat的配置技巧，這些技巧源自於我的書：《Tomcat權威指南》，希望對你有所幫助。 Jason Brittain

1． 配置系統管理（Admin Web Application）

大多數商業化的J2EE伺服器都提供一個功能強大的管理界面，且大都採用易於理解的Web應用界面。Tomcat按照自己的方式，同樣提供一個成熟的管理工具，並且絲毫不遜於那些商業化的競爭對手。Tomcat的Admin Web Application最初在4.1版本時出現，當時的功能包括管理context、data source、user和group等。當然也可以管理像初始化參數，user、group、role的多種資料庫管理等。在後續的版本中，這些功能將得到很大的擴展，但現有的功能已經非常實用了。

Admin Web Application被定義在自動部署文件：CATALINA_BASE/webapps/admin.xml 。
（譯者註：CATALINA_BASE即tomcat安裝目錄下的server目錄）

你必須編輯這個文件，以確定Context中的 docBase參數是絕對路徑。也就是說，CATALINA_BASE/webapps/admin.xml 的路徑是絕對路徑。作為另外一種選擇，你也可以刪除這個自動部署文件，而在server.xml文件中建立一個Admin Web Application的context，效果是一樣的。你不能管理Admin Web Application這個應用，換而言之，除了刪除CATALINA_BASE/webapps/admin.xml ，你可能什麼都做不了。

如果你使用UserDatabaseRealm（默認），你將需要添加一個user以及一個role到CATALINA_BASE/conf /tomcat-users.xml 文件中。你編輯這個文件，添加一個名叫「admin」的role 到該文件中，如下：

＜role name="admin"/＞

你同樣需要有一個用戶，並且這個用戶的角色是「admin」。象存在的用戶那樣，添加一個用戶（改變密碼使其更加安全）：

＜user name="admin" password="deep_dark_secret" roles="admin"/＞

當你完成這些步驟後，請重新啟動Tomcat，訪問http://localhost:8080/admin，你將看到一個登錄界面。Admin Web Application採用基於容器管理的安全機制，並採用了Jakarta Struts框架。一旦你作為「admin」角色的用戶登錄管理界面，你將能夠使用這個管理界面配置Tomcat。

2．配置應用管理（Manager Web Application）

Manager Web Application讓你通過一個比Admin Web Application更為簡單的用戶界面，執行一些簡單的Web應用任務。

Manager Web Application被被定義在一個自動部署文件中：

CATALINA_BASE/webapps/manager.xml 。

你必須編輯這個文件，以確保context的docBase參數是絕對路徑，也就是說 CATALINA_HOME/server/webapps/manager的絕對路徑。
（譯者註：CATALINA_HOME即 tomcat安裝目錄）

如果你使用的是UserDatabaseRealm，那麼你需要添加一個角色和一個用戶到 CATALINA_BASE/conf/tomcat-users.xml文件中。接下來，編輯這個文件，添加一個名為「manager」的角色到該文件中：

＜role name=」manager」＞

你同樣需要有一個角色為「manager」的用戶。像已經存在的用戶那樣，添加一個新用戶（改變密碼使其更加安全）：

＜user name="manager" password="deep_dark_secret" roles="manager"/＞

然後重新啟動Tomcat，訪問http://localhost/manager/list，將看到一個很樸素的文本型管理界面，或者訪問http://localhost/manager/html/list，將看到一個HMTL的管理界面。不管是哪種方式都說明你的Manager Web Application現在已經啟動了。

Manager application讓你可以在沒有系統管理特權的基礎上，安裝新的Web應用，以用於測試。如果我們有一個新的web應用位於/home/user /hello下在，並且想把它安裝到 /hello下，為了測試這個應用，我們可以這么做，在第一個文件框中輸入「/hello」（作為訪問時的path），在第二個文本框中輸入「file: /home/user/hello」（作為Config URL）。

Manager application還允許你停止、重新啟動、移除以及重新部署一個web應用。停止一個應用使其無法被訪問，當有用戶嘗試訪問這個被停止的應用時，將看到一個503的錯誤??「503 - This application is not currently available」。

移除一個web應用，只是指從Tomcat的運行拷貝中刪除了該應用，如果你重新啟動Tomcat，被刪除的應用將再次出現（也就是說，移除並不是指從硬碟上刪除）。
3．部署一個web應用

有兩個辦法可以在系統中部署web服務。

1＞ 拷貝你的WAR文件或者你的web應用文件夾（包括該web的所有內容）到$CATALINA_BASE/webapps目錄下。

2＞ 為你的web服務建立一個只包括context內容的XML片斷文件，並把該文件放到$CATALINA_BASE/webapps目錄下。這個web應用本身可以存儲在硬碟上的任何地方。

如果你有一個WAR文件，你若想部署它，則只需要把該文件簡單的拷貝到 CATALINA_BASE/webapps目錄下即可，文件必須以「.war」作為擴展名。一旦Tomcat監聽到這個文件，它將（預設的）解開該文件包作為一個子目錄，並以WAR文件的文件名作為子目錄的名字。接下來，Tomcat將在內存中建立一個context，就好象你在server.xml文件里建立一樣。當然，其他必需的內容，將從server.xml中的DefaultContext獲得。

部署web應用的另一種方式是寫一個Context XML片斷文件，然後把該文件拷貝到CATALINA_BASE/webapps目錄下。一個Context片斷並非一個完整的XML文件，而只是一個 context元素，以及對該應用的相應描述。這種片斷文件就像是從server.xml中切取出來的context元素一樣，所以這種片斷被命名為 「context片斷」。

舉個例子，如果我們想部署一個名叫MyWebApp.war的應用，該應用使用realm作為訪問控制方式，我們可以使用下面這個片斷：

＜!--
Context fragment for deploying MyWebApp.war
--＞
＜Context path="/demo" docBase="webapps/MyWebApp.war"
debug="0" privileged="true"＞
＜Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/＞
＜/Context＞

把該片斷命名為「MyWebApp.xml」，然後拷貝到CATALINA_BASE/webapps目錄下。

這種context片斷提供了一種便利的方法來部署web應用，你不需要編輯server.xml，除非你想改變預設的部署特性，安裝一個新的web應用時不需要重啟動Tomcat。

4．配置虛擬主機（Virtual Hosts）

關於server.xml中「Host」這個元素，只有在你設置虛擬主機的才需要修改。虛擬主機是一種在一個web伺服器上服務多個域名的機制，對每個域名而言，都好象獨享了整個主機。實際上，大多數的小型商務網站都是採用虛擬主機實現的，這主要是因為虛擬主機能直接連接到Internet並提供相應的帶寬，以保障合理的訪問響應速度，另外虛擬主機還能提供一個穩定的固定IP。

基於名字的虛擬主機可以被建立在任何web伺服器上，建立的方法就是通過在域名伺服器（DNS）上建立IP地址的別名，並且告訴web伺服器把去往不同域名的請求分發到相應的網頁目錄。因為這篇文章主要是講 Tomcat，我們不準備介紹在各種操作系統上設置DNS的方法，如果你在這方面需要幫助，請參考《DNS and Bind》一書，作者是Paul Albitz and Cricket Liu (O'Reilly)。為了示範方便，我將使用一個靜態的主機文件，因為這是測試別名最簡單的方法。

在Tomcat中使用虛擬主機，你需要設置DNS或主機數據。為了測試，為本地IP設置一個IP別名就足夠了，接下來，你需要在server.xml中添加幾行內容，如下：

＜Server port="8005" shutdown="SHUTDOWN" debug="0"＞
＜Service name="Tomcat-Standalone"＞
＜Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
port="8080" minProcessors="5" maxProcessors="75"
enableLookups="true" redirectPort="8443"/＞
＜Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
port="8443" minProcessors="5" maxProcessors="75"
acceptCount="10" debug="0" scheme="https" secure="true"/＞
＜Factory className="org.apache.coyote.tomcat4.CoyoteServerSocketFactory"
clientAuth="false" protocol="TLS" /＞
＜/Connector＞
＜Engine name="Standalone" defaultHost="localhost" debug="0"＞
＜!-- This Host is the default Host --＞
＜Host name="localhost" debug="0" appBase="webapps"
unpackWARs="true" autoDeploy="true"＞
＜Context path="" docBase="ROOT" debug="0"/＞
＜Context path="/orders" docBase="/home/ian/orders" debug="0"
reloadable="true" crossContext="true"＞
＜/Context＞
＜/Host＞

＜!-- This Host is the first "Virtual Host": http://www.example.com/ --＞
＜Host name="www.example.com" appBase="/home/example/webapp"＞
＜Context path="" docBase="."/＞
＜/Host＞

＜/Engine＞
＜/Service＞
＜/Server＞

Tomcat的server.xml文件，在初始狀態下，只包括一個虛擬主機，但是它容易被擴充到支持多個虛擬主機。在前面的例子中展示的是一個簡單的server.xml版本，其中粗體部分就是用於添加一個虛擬主機。每一個Host元素必須包括一個或多個 context元素，所包含的context元素中必須有一個是默認的context，這個默認的context的顯示路徑應該為空（例如，path=」」）。
5．配置基礎驗證（Basic Authentication）

容器管理驗證方法控制著當用戶訪問受保護的web應用資源時，如何進行用戶的身份鑒別。當一個web應用使用了Basic Authentication（BASIC參數在web.xml文件中auto-method元素中設置），而有用戶訪問受保護的web應用時，Tomcat將通過HTTP Basic Authentication方式，彈出一個對話框，要求用戶輸入用戶名和密碼。在這種驗證方法中，所有密碼將被以64位的編碼方式在網路上傳輸。

注意：使用Basic Authentication通過被認為是不安全的，因為它沒有強健的加密方法，除非在客戶端和伺服器端都使用HTTPS或者其他密碼加密碼方式（比如，在一個虛擬私人網路中）。若沒有額外的加密方法，網路管理員將能夠截獲（或濫用）用戶的密碼。但是，如果你是剛開始使用Tomcat，或者你想在你的 web應用中測試一下基於容器的安全管理，Basic Authentication還是非常易於設置和使用的。只需要添加＜security-constraint＞和＜login-config＞兩個元素到你的web應用的web.xml文件中，並且在CATALINA_BASE/conf/tomcat-users.xml 文件中添加適當的＜role＞和＜user＞即可，然後重新啟動Tomcat。

下面例子中的web.xml摘自一個俱樂部會員網站系統，該系統中只有member目錄被保護起來，並使用Basic Authentication進行身份驗證。請注意，這種方式將有效的代替Apache web伺服器中的.htaccess文件。

＜!--
Define the Members-only area, by defining
a "Security Constraint" on this Application, and
mapping it to the subdirectory (URL) that we want
to restrict.
--＞
＜security- constraint＞
＜web-resource-collection＞
＜web-resource-name＞
Entire Application
＜/web-resource-name＞
＜url-pattern＞/members/*＜/url- pattern＞
＜/web-resource-collection＞
＜auth-constraint＞
＜role- name＞member＜/role-name＞
＜/auth-constraint＞
＜/security- constraint＞
＜!-- Define the Login Configuration for this Application --＞
＜login-config＞
＜auth-method＞BASIC＜/auth-method＞
＜realm- name＞My Club Members-only Area＜/realm-name＞
＜/login-config＞

6．配置單點登錄（Single Sign-On）

一旦你設置了realm和驗證的方法，你就需要進行實際的用戶登錄處理。一般說來，對用戶而言登錄系統是一件很麻煩的事情，你必須盡量減少用戶登錄驗證的次數。作為預設的情況，當用戶第一次請求受保護的資源時，每一個web應用都會要求用戶登錄。如果你運行了多個web應用，並且每個應用都需要進行單獨的用戶驗證，那這看起來就有點像你在與你的用戶搏鬥。用戶們不知道怎樣才能把多個分離的應用整合成一個單獨的系統，所有他們也就不知道他們需要訪問多少個不同的應用，只是很迷惑，為什麼總要不停的登錄。

Tomcat 4的「single sign-on」特性允許用戶在訪問同一虛擬主機下所有web應用時，只需登錄一次。為了使用這個功能，你只需要在Host上添加一個 SingleSignOn Valve元素即可，如下所示：

＜Valve className="org.apache.catalina.authenticator.SingleSignOn"
debug="0"/＞

在Tomcat初始安裝後，server.xml的注釋裡麵包括SingleSignOn Valve配置的例子，你只需要去掉注釋，即可使用。那麼，任何用戶只要登錄過一個應用，則對於同一虛擬主機下的所有應用同樣有效。

使用single sign-on valve有一些重要的限制：

1＞ value必須被配置和嵌套在相同的Host元素里，並且所有需要進行單點驗證的web應用（必須通過context元素定義）都位於該Host下。

2＞ 包括共享用戶信息的realm必須被設置在同一級Host中或者嵌套之外。

3＞ 不能被context中的realm覆蓋。

4＞ 使用單點登錄的web應用最好使用一個Tomcat的內置的驗證方式（被定義在web.xml中的＜auth-method＞中），這比自定義的驗證方式強，Tomcat內置的的驗證方式包括basic、digest、form和client-cert。

5＞ 如果你使用單點登錄，還希望集成一個第三方的web應用到你的網站中來，並且這個新的web應用使用它自己的驗證方式，而不使用容器管理安全，那你基本上就沒招了。你的用戶每次登錄原來所有應用時需要登錄一次，並且在請求新的第三方應用時還得再登錄一次。當然，如果你擁有這個第三方web應用的源碼，而你又是一個程序員，你可以修改它，但那恐怕也不容易做。

6＞ 單點登錄需要使用cookies。

7．配置用戶定製目錄（Customized User Directores）

一些站點允許個別用戶在伺服器上發布網頁。例如，一所大學的學院可能想給每一位學生一個公共區域，或者是一個ISP希望給一些web空間給他的客戶，但這又不是虛擬主機。在這種情況下，一個典型的方法就是在用戶名前面加一個特殊字元（~），作為每位用戶的網站，比如：

http://www.cs.myuniversity.e/~username
http://members.mybigisp.com/~username

Tomcat提供兩種方法在主機上映射這些個人網站，主要使用一對特殊的Listener元素。Listener的 className屬性應該是org.apache.catalina.startup.UserConfig，userClass屬性應該是幾個映射類之一。如果你的系統是Unix，它將有一個標準的/etc/passwd文件，該文件中的帳號能夠被運行中的Tomcat很容易的讀取，該文件指定了用戶的主目錄，使用PasswdUserDatabase 映射類。

＜Listener className="org.apache.catalina.startup.UserConfig"
directoryName="public_html"
userClass="org.apache.catalina.startup.PasswdUserDatabase"/＞

web文件需要放置在像/home/users/ian/public_html 或者 /users/jbrittain/public_html一樣的目錄下面。當然你也可以改變public_html 到其他任何子目錄下。

實際上，這個用戶目錄根本不一定需要位於用戶主目錄下裡面。如果你沒有一個密碼文件，但你又想把一個用戶名映射到公共的像/home一樣目錄的子目錄裡面，則可以使用HomesUserDatabase類。

＜Listener className="org.apache.catalina.startup.UserConfig"
directoryName="public_html" homeBase="/home"
userClass="org.apache.catalina.startup.HomesUserDatabase"/＞

這樣一來，web文件就可以位於像/home/ian/public_html 或者 /home/jasonb/public_html一樣的目錄下。這種形式對Windows而言更加有利，你可以使用一個像c:\home這樣的目錄。

這些Listener元素，如果出現，則必須在Host元素裡面，而不能在context元素裡面，因為它們都用應用於Host本身。

8．在Tomcat中使用CGI腳本

Tomcat主要是作為Servlet/JSP容器，但它也有許多傳統web伺服器的性能。支持通用網關介面（Common Gateway Interface，即CGI）就是其中之一，CGI提供一組方法在響應瀏覽器請求時運行一些擴展程序。CGI之所以被稱為通用，是因為它能在大多數程序或腳本中被調用，包括：Perl，Python，awk，Unix shell scripting等，甚至包括java。當然，你大概不會把一個Java應用程序當作CGI來運行，畢竟這樣太過原始。一般而言，開發Servlet總要比CGI具有更好的效率，因為當用戶點擊一個鏈接或一個按鈕時，你不需要從操作系統層開始進行處理。

Tomcat包括一個可選的 CGI Servlet，允許你運行遺留下來的CGI腳本。

為了使Tomcat能夠運行CGI，你必須做如下幾件事：

1. 把servlets-cgi.renametojar （在CATALINA_HOME/server/lib/目錄下）改名為servlets-cgi.jar。處理CGI的servlet應該位於 Tomcat的CLASSPATH下。

2. 在Tomcat的CATALINA_BASE/conf/web.xml 文件中，把關於＜servlet-name＞ CGI的那段的注釋去掉（默認情況下，該段位於第241行）。

3. 同樣，在Tomcat的CATALINA_BASE/conf/web.xml文件中，把關於對CGI進行映射的那段的注釋去掉（默認情況下，該段位於第 299行）。注意，這段內容指定了HTML鏈接到CGI腳本的訪問方式。

4. 你可以把CGI腳本放置在WEB-INF/cgi 目錄下（注意，WEB-INF是一個安全的地方，你可以把一些不想被用戶看見或基於安全考慮不想暴露的文件放在此處），或者你也可以把CGI腳本放置在 context下的其他目錄下，並為CGI Servlet調整cgiPathPrefix初始化參數。這就指定的CGI Servlet的實際位置，且不能與上一步指定的URL重名。

5. 重新啟動Tomcat，你的CGI就可以運行了。

在Tomcat中，CGI程序預設放置在WEB-INF/cgi目錄下，正如前面所提示的那樣，WEB-INF目錄受保護的，通過客戶端的瀏覽器無法窺探到其中內容，所以對於放置含有密碼或其他敏感信息的CGI腳本而言，這是一個非常好的地方。為了兼容其他伺服器，盡管你也可以把CGI腳本保存在傳統的 /cgi-bin目錄，但要知道，在這些目錄中的文件有可能被網上好奇的沖浪者看到。另外，在Unix中，請確定運行Tomcat的用戶有執行CGI腳本的許可權。

9．改變Tomcat中的JSP編譯器（JSP Compiler）

在Tomcat 4.1（或更高版本，大概），JSP的編譯由包含在Tomcat裡面的Ant程序控制器直接執行。這聽起來有一點點奇怪，但這正是Ant有意為之的一部分，有一個API文檔指導開發者在沒有啟動一個新的JVM的情況下，使用Ant。這是使用Ant進行Java開發的一大優勢。另外，這也意味著你現在能夠在Ant中使用任何javac支持的編譯方式，這里有一個關於Apache Ant使用手冊的javac page列表。使用起來是容易的，因為你只需要在＜init-param＞ 元素中定義一個名字叫「compiler」，並且在value中有一個支持編譯的編譯器名字，示例如下：

＜servlet＞
＜servlet-name＞jsp＜/servlet- name＞
＜servlet-class＞
org.apache.jasper.servlet.JspServlet
＜/servlet- class＞
＜init-param＞
＜param-name＞logVerbosityLevel＜/param-name＞
＜param- value＞WARNING＜/param-value＞
＜/init-param＞
＜init-param＞
＜param- name＞compiler＜/param-name＞
＜param-value＞jikes＜/param-value＞
＜/init- param＞
＜load-on-startup＞3＜/load-on-startup＞
＜/servlet＞

當然，給出的編譯器必須已經安裝在你的系統中，並且CLASSPATH可能需要設置，那處決於你選擇的是何種編譯器。

10．限制特定主機訪問（Restricting Access to Specific Hosts）

有時，你可能想限制對Tomcat web應用的訪問，比如，你希望只有你指定的主機或IP地址可以訪問你的應用。這樣一來，就只有那些指定的的客戶端可以訪問服務的內容了。為了實現這種效果，Tomcat提供了兩個參數供你配置：RemoteHostValve 和RemoteAddrValve。

通過配置這兩個參數，可以讓你過濾來自請求的主機或IP地址，並允許或拒絕哪些主機/IP。與之類似的，在Apache的httpd文件里有對每個目錄的允許/拒絕指定。

例如你可以把Admin Web application設置成只允許本地訪問，設置如下：

＜Context path="/path/to/secret_files" ...＞
＜Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127.0.0.1" deny=""/＞
＜/Context＞

如果沒有給出允許主機的指定，那麼與拒絕主機匹配的主機就會被拒絕，除此之外的都是允許的。與之類似，如果沒有給出拒絕主機的指定，那麼與允許主機匹配的主機就會被允許，除此之外的都是拒絕的。

⑵ 關於web項目要重新部署並重啟tomcat生效的問題

你這個「項目裡面已經有客戶上傳的資源「這句話有點疑問，基本上資源都是放在磁碟上或資料庫裡面，重新部署一個新的版本應該保證數據能轉換過來而不是刪除它們讓用戶重新錄入，那麼我在想你這話話指的是當前用戶在使用時 session 會話中有些數據還在內存裡面，重啟會丟失，如果是這樣的話，基本上只有便宜的伺服器會碰到這個問題，因為商用的伺服器有一個功能叫」持久性會話「，在伺服器重啟時會把所有session的數據寫入到資料庫（有些伺服器會用一個嵌入式的資料庫比如derby或hsql來保存這個東西）或磁碟，重啟成功後會把它們恢復到內存里。對於很多不適合重啟的應用程序它們會想到使用 JSP而不是使用 Servlet。不過還是有很多網站本身是會停機的，只要事先發布公告並挑個使用者數量最少的深夜來做就行了。
從技術上講，session 對於用戶來說，他僅僅有一個 session ID 而已，其它所有東西都在伺服器上，重啟後用戶刷新瀏覽器，那個 session id 對應的數據依然能拿到手。那麼只要伺服器上的東西放在session中的都寫入到資料庫（因為這樣可以加密，防止他人偷看或復制），重啟後恢復到內存中，所有東西都正常了。我們不應該假設所有在內存裡面的東西都能恢復。

因此我們想到了很多 API 對於想放入 session 的東西都要求實現 java.io.Serializable 介面的原因也就在這里，另外對於需要支持集群功能的伺服器也是這樣的，因為 session 數據需要在多台伺服器之間復制。

⑶ javaweb cooike需要加密嗎

登錄幾乎是每個項目都具有的功能，記住密碼也是常見的部分，在用戶登錄時，實現記住密碼的功能一般使用兩個方法來實現：

• 使用cookie，將登錄信息存入cookie，存儲在用戶本地。

• 持久化，將登錄信息存入資料庫，因為cookie存在過期，而且用戶瀏覽器可能會禁用cookie，使用這個方法有效避免了這些問題。

第二種方法就不多說了，基本就是資料庫中表的CRUD的操作了，下面來說一下第一種方法。
cookie是一種WEB伺服器通過瀏覽器在訪問者的硬碟上存儲信息的手段。Cookie的目的就是為用戶帶來方便，為網站帶來增值。雖然有著許多誤傳，事實上Cookie並不會造成嚴重的安全威脅。
Cookie永遠不會以任何方式執行，因此也不會帶來病毒或攻擊你的系統。另外，由於瀏覽器一般只允許存放300個Cookie，每個站點最多存放20個Cookie，每個Cookie的大小限制為4KB，因此Cookie不會塞滿你的硬碟。

例如，當我們第一次訪問網站輸入用戶名密碼時，可以選擇讓系統記住用戶名密碼，下次就不用重新輸入了，這就是典型的Cookie的應用。

在討論cookie的時候都會聯想到session，它們之間的區別和聯系如下：

• cookie機制和session機制的區別
  具體來說cookie機制採用的是在客戶端保持狀態的方案，而session機制採用的是在伺服器端保持狀態的方案。
  同時我們也看到，由於在伺服器端保持狀態的方案在客戶端也需要保存一個標識，所以session機制可能需要藉助於cookie機制來達到保存標識的目的，但實際上還有其他選擇。

• 會話cookie和持久cookie的區別
  如果不設置過期時間，則表示這個cookie生命周期為瀏覽器會話期間，只要關閉瀏覽器窗口，cookie就消失了。這種生命期為瀏覽會話期的cookie被稱為會話cookie。會話cookie一般不保存在硬碟上而是保存在內存里。
  如果設置了過期時間，瀏覽器就會把cookie保存到硬碟上，關閉後再次打開瀏覽器，這些cookie依然有效直到超過設定的過期時間。
  存儲在硬碟上的cookie可以在不同的瀏覽器進程間共享，比如兩個IE窗口。而對於保存在內存的cookie，不同的瀏覽器有不同的處理方式。

接下來實現一個記住密碼的功能：

• <div class="form-group">


• <label class="checkbox-inline">


• <input type="checkbox" name="rememberMe" id="rememberMe" onclick="remember();"/>


• Remember me


• </label> <span class="pull-right">



• </div>1234567





• //記住密碼復選框的點擊事件function remember(){


• var remFlag = $("input[type='checkbox']").is(':checked'); if(remFlag==true){ //如果選中設置remFlag為true


• //cookie存用戶名和密碼,回顯的是真實的用戶名和密碼,存在安全問題.


• var conFlag = confirm("記錄密碼功能不宜在公共場所(如網吧等)使用,以防密碼泄露.您確定要使用此功能嗎?"); if(conFlag){ //確認標志


• $("#remFlag").val(true);


• }else{


• $("input[type='checkbox']").removeAttr('checked');


• $("#remFlag").val(false);


• }


• }else{ //如果沒選中設置remFlag為false


• $("#remFlag").val(false);


• }


• }12345678910111213141516



下一次訪問此頁面自動填充賬號密碼

• $(document).ready(function(){


• //記住密碼功能


• var str = getCookie("loginInfo");


• str = str.substring(1,str.length-1); var username = str.split(",")[0]; var password = str.split(",")[1]; //自動填充用戶名和密碼


• $("#username").val(username);


• $("#pwd").val(password); if(str!=null && str!=""){


• $("input[type='checkbox']").attr("checked", true);


• }


• });12345678910111213



JavaScript getCookie（）

• //獲取cookiefunction getCookie(cname) {


• var name = cname + "="; var ca = document.cookie.split(';'); for(var i=0; i<ca.length; i++) { var c = ca[i]; while (c.charAt(0)==' ') c = c.substring(1); if (c.indexOf(name) != -1) return c.substring(name.length, c.length);


• } return "";


• }1234567891011



後台Java對cookie的操作的封裝的工具類：

• import java.io.UnsupportedEncodingException;import java.net.URLEncoder;import java.util.HashMap;import java.util.Map;import javax.servlet.http.Cookie;import javax.servlet.http.HttpServletRequest;import javax.servlet.http.HttpServletResponse;/**


• * 該類可以從瀏覽器請求中提取出cookies並進行對cookis的相關操作


• * @author Administrator


• *


• */public class CookiesUtil {


• /**


• * 根據名字獲取cookie


• *


• * @param request


• * @param name


• * cookie名字


• * @return


• */


• public static Cookie getCookieByName(HttpServletRequest request, String name) {


• Map<String, Cookie> cookieMap = ReadCookieMap(request); if (cookieMap.containsKey(name)) {


• Cookie cookie = (Cookie) cookieMap.get(name); return cookie;


• } else { return null;


• }


• } /**


• * 將cookie封裝到Map裡面


• *


• * @param request


• * @return


• */


• private static Map<String, Cookie> ReadCookieMap(HttpServletRequest request) {


• Map<String, Cookie> cookieMap = new HashMap<String, Cookie>();


• Cookie[] cookies = request.getCookies(); if (null != cookies) { for (Cookie cookie : cookies) {


• cookieMap.put(cookie.getName(), cookie);


• }


• } return cookieMap;


• } /**


• * 保存Cookies


• *


• * @param response


• * servlet請求


• * @param value


• * 保存值


• */


• public static HttpServletResponse setCookie(HttpServletResponse response, String name, String value,int time) { // new一個Cookie對象,鍵值對為參數


• Cookie cookie = new Cookie(name, value); // tomcat下多應用共享


• cookie.setPath("/"); // 如果cookie的值中含有中文時，需要對cookie進行編碼，不然會產生亂碼


• try {


• URLEncoder.encode(value, "utf-8");


• } catch (UnsupportedEncodingException e) {


• e.printStackTrace();


• }


• cookie.setMaxAge(time); // 將Cookie添加到Response中,使之生效


• response.addCookie(cookie); // addCookie後，如果已經存在相同名字的cookie，則最新的覆蓋舊的cookie


• return response;


• } /**


• * <p>刪除無效cookie</p>


• * <p>無效☞1.過時 2.未發布</p>


• * @param request


• * @param response


• * @param list


• */


• @SuppressWarnings("unused") private void delectCookieByName(HttpServletRequest request, HttpServletResponse response,String deleteKey) throws NullPointerException {


• Map<String, Cookie> cookieMap = ReadCookieMap(request); for (String key : cookieMap.keySet()) {


• if(key==deleteKey && key.equals(deleteKey)) {


• Cookie cookie = cookieMap.get(key);


• cookie.setMaxAge(0);//設置cookie有效時間為0


• cookie.setPath("/");//不設置存儲路徑


• response.addCookie(cookie);


• }


• }


• }


• }



附加知識點：
為了在網路傳輸上更加安全，一般對密碼進行加密之後再提交加密之後的密碼串至後台，在資料庫的用戶表中密碼這一欄位直接存儲加密之後的密碼串即可，二者進行比對，判斷是否能登錄成功。進行加密可以使用不可逆的MD5加密，雖然這已經是不可逆的了，安全度已經很高了，但是如果想更安全一點不被撞擊出原始值，可以自己寫一個工具類生成一定長度的隨機字元串+密碼，之後再進行加密，這樣的話就算使用抓包工具得到了你的密碼串，破解出你的密碼的概率微乎其微了。
工具類生成一定長度的隨機字元串

• import java.io.UnsupportedEncodingException;import java.security.MessageDigest;import java.security.NoSuchAlgorithmException;import java.util.Random;public class StringUtils {


• /**


• * 獲取隨機字元串，可用於加密 添加字元，增加保密度


• */


• private static final String ALLCHAR = ""; /**


• * 獲取任意位的隨機字元串(0-9 a-z A-Z)


• *


• * @param size


• * 位數


• * @return


• */


• public static final String getRandomNum(int size) {


• StringBuffer sb = new StringBuffer();


• Random random = new Random(); for (int i = 0; i < size; i++) {


• sb.append(ALLCHAR.charAt(random.nextInt(ALLCHAR.length())));


• } return sb.toString();


• } /**


• * md5加密(ITS)


• *


• * @param str


• * @param charSet


• * @return


• */


• public synchronized static final String getMD5Str(String str, String charSet) { // md5加密


• MessageDigest messageDigest = null; try {


• messageDigest = MessageDigest.getInstance("MD5");


• messageDigest.reset(); if (charSet == null) {


• messageDigest.update(str.getBytes());


• } else {


• messageDigest.update(str.getBytes(charSet));


• }


• } catch (NoSuchAlgorithmException e) {



• } catch (UnsupportedEncodingException e) {



• } byte[] byteArray = messageDigest.digest();


• StringBuffer md5StrBuff = new StringBuffer(); for (int i = 0; i < byteArray.length; i++) { if (Integer.toHexString(0xFF & byteArray[i]).length() == 1)


• md5StrBuff.append("0").append(


• Integer.toHexString(0xFF & byteArray[i])); else


• md5StrBuff.append(Integer.toHexString(0xFF & byteArray[i]));


• } return md5StrBuff.toString();


• }


• }



jsp頁面產生隨機數或隨機字元串

• <%


• //產生隨機數，和密碼一起生成MD5


• request.getSession().setAttribute("md5RandomKey", StringUtils.getRandomNum(8));


• %> 1234



表單提交時，onsubmit事件中：

• //表單提交時對輸入的密碼進行加密， 避免抓包分析破解密碼


• var hash = MD5($('#pwd').val()+"${md5RandomKey}");


• var hash = MD5($('#pwd').val());


• $('#pwd').val(hash); 1234



好了，功德圓滿。

⑷ 如何配置資料庫密碼加密訪問資料庫

問題解決思路：將配置文件用戶相關的信息(例如：密碼)進行加密使其以密文形式存在，進行初始化連接池的時候進行解密操作，達到成功創建連接池的目的。Tomcat默認使用DBCP連接池(基於common-pool的一種連接池實現)，可在下載commons-dbcp源碼包commons-dbcp-1.4-src.zip，對org.apache.commons.dbcp.BasicDataSourceFactory類修改，把資料庫密碼欄位（加密後的密文）用解密程序解密，獲得解密後的明文即可。具體實現：1.修改org.apache.commons.dbcp.BasicDataSourceFactory類文件找到數據源密碼設置部分value=properties.getProperty(PROP_PASSWORD);if(value!=null){dataSource.setPassword(value);}修改為：value=properties.getProperty(PROP_PASSWORD);if(value!=null){dataSource.setPassword(Encode.decode(value));}將配置文件中的「密碼」（加密後的結果）取出，調用加解密類中的解密方法Encode.decode(value)進行解密。2.加密類Encode.java,本例中使用加密解密模塊比較簡單只是用來說明問題，密文為明文的十六進制串。publicclassEncode{//編碼-普通字元串轉為十六進制字元串publicstaticStringencode(Stringpassword){Stringresult=「」;byte[]psd=password.getBytes();for(inti=0;ipassword696e65743231urljdbc:oracle:thin:@127.0.0.1:1521:orcldriverClassNameoracle.jdbc.driver.OracleDriverusernamewanfang4.將修改後的BasicDataSourceFactory.java和新添加的Encode.java編譯後的class類文件重新打包進commons-dbcp-1.4.jar，將該包拷貝進tomcat下的common/lib目錄中，重啟tomcat。此時tomcat下部署的應用在連接數據源的時候都可以在不暴露密碼明文的情況下進行連接。轉載，僅供參考。

⑸ 如何實現Tomcat連接池資料庫密碼加密

問題解決思路：
將配置文件用戶相關的信息(例如：密碼)進行加密使其以密文形式存在，進行初始化連接池的時候進行解密操作，達到成功創建連接池的目的。Tomcat默認使用DBCP連接池(基於common-pool的一種連接池實現)，可在http://jakarta.apache.org/commons/dbcp/下載commons-dbcp源碼包commons-dbcp-1.4-src.zip，對org.apache.commons.dbcp.BasicDataSourceFactory類修改，把資料庫密碼欄位（加密後的密文）用解密程序解密，獲得解密後的明文即可。
具體實現：
1. 修改org.apache.commons.dbcp.BasicDataSourceFactory類文件
找到數據源密碼設置部分
value = properties.getProperty(PROP_PASSWORD);
if (value != null) {
dataSource.setPassword(value);
}
修改為：
value = properties.getProperty(PROP_PASSWORD);
if (value != null) {
dataSource.setPassword(Encode.decode(value));
}
將配置文件中的「密碼」（加密後的結果）取出，調用加解密類中的解密方法Encode.decode(value)進行解密。
2. 加密類Encode.java,本例中使用加密解密模塊比較簡單只是用來說明問題，密文為明文的十六進制串。
public class Encode {
//編碼-普通字元串轉為十六進制字元串
public static String encode(String password){
String result = 「」;
byte[] psd = password.getBytes();
for(int i=0;i<psd.length;i++){
result += Integer.toHexString(psd[i]&0xff);
}
return result;
}
//解碼–十六進制字元串轉為普通字元串
public static String decode(String password){
String result = 「」;
password = password.toUpperCase();
int length = password.length() / 2;
char[] hexChars = password.toCharArray();
byte[] d = new byte[length];
for (int i = 0; i < length; i++) {
int pos = i * 2;
d[i] = (byte) (charToByte(hexChars[pos]) << 4 | charToByte(hexChars[pos + 1]));
}
result = new String(d);
return result;
}
//字元轉位元組
public static byte charToByte(char c) {
return (byte) 「0123456789ABCDEF」.indexOf(c);
}
}
3. 資料庫連接池文件，紅色字體為數據源配置中密碼設置，此時已經改為密文形式。
<?xml version=』1.0′ encoding=』utf-8′?>
<Context docBase=」reportmis」 path=」/reportmis」 privileged=」true」 workDir=」work\Catalina\localhost\reportmis」>
<Resource auth=」Container」 name=」mis2datasource」 type=」javax.sql.DataSource」/>
<ResourceParams name=」mis2datasource」>
<parameter>
<name>password</name>
<value>696e65743231</value>
</parameter>
<parameter>
<name>url</name>
<value>jdbc:oracle:thin:@127.0.0.1:1521:orcl</value>
</parameter>
<parameter>
<name>driverClassName</name>
<value>oracle.jdbc.driver.OracleDriver</value>
</parameter>
<parameter>
<name>username</name>
<value>wanfang</value>
</parameter>
</ResourceParams>
</Context>
4. 將修改後的BasicDataSourceFactory.java和新添加的Encode.java編譯後的class類文件重新打包進commons-dbcp-1.4.jar，將該包拷貝進tomcat下的common/lib目錄中，重啟tomcat。此時tomcat下部署的應用在連接數據源的時候都可以在不暴露密碼明文的情況下進行連接。

⑹ tomcat配置jndi druiddatasource怎麼加密

name 名字 type source的類型 driverclassname：驅動類名 url:連接url username：資料庫連接用戶名 password：資料庫連接密碼 maxActive：最大活動數 maxIdle：最大空閑數 maxWait：最大等待時間

⑺ java 對資料庫properties文件加密

可以通過其它方法來實現：
1：如果沒用框架，直接加密、解密即可
2：如果用hibernate之類，可以繞過Configuration，讀取Hibernate配置文件解密後再連接資料庫
3：考慮集群影響

⑻ 求教Java web項目一般怎樣做代碼混淆或加密

一、java web項目混淆
proguard4.8工具，說是支持war的，可混淆過後少了classes目錄了，自然成功不了。網上搜的過程不詳說了，最後找著－－「J2EE-web工程ProGuard代碼混淆07_28」，網址：http://wenku..com/link?url=CxToEqg5QWbz2_--cVqaImGKnLLLTO45u6uD_
根據提示一步步完成。
把web項目打成jar包後用proguard進行混淆，然後把混淆過後的class目錄替換發布包war中的對應目錄，啟動運行是正常的。
主要注意利用proguard生成xxx.pro文件，然後手動加工-keep class WebRoot.WEB-INFO.lib.* 等項目中不需要混淆的包和類。
二、java web項目打成.exe
沒找到免費的，這搜到個收費的－－Jinstall，試了下功能挺好，
可以加密、集成jdk、tomcat，如果資料庫是mysql也集成，其他資料庫的話要設置資料庫的url.