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.