J2EE&forever

window下搭建svn全过程

J2EE&forever — Wed, 11 Jun 2008 14:56:52 +0800

作者: J2EE&forever 链接：http://yangzhiwen911.javaeye.com/blog/202156 发表时间: 2008年06月11日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

首先，下载和安装服务器

去官方网站下载并安装svn-1.2.3-setup.exe,

下载地址如下：
http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91

安装到D:\svnserver\Subversion（随意）

然后，建立Repository

打开命令窗口，键入 svnadmin create D:\svnserver\projects\EasyON

再然后，配置Repository

进入Repository目录，在本文中是D:\svnserver\projects\EasyON，你会看到conf目录，进入该目录，你会看到svnserve.conf和passwd两个文件

对两个文件作如下修改

svnserve.conf

[general]
### These options control access to the repository for unauthenticated
### and authenticated users. Valid values are "write", "read",
### and "none". The sample settings below are the defaults.
anon-access = read
auth-access = write
### The password-db option controls the location of the password
### database file. Unless you specify a path starting with a /,
### the file's location is relative to the conf directory.
### Uncomment the line below to use the default password file.
password-db = passwd

passwd

[users]
# harry = harryssecret
# sally = sallyssecret
jackie = jackie (你要添加的svn用户，第一个是用户名，第二个是密码，可以添加多个)

以上配置完事，说明你已经具备了svn服务器的前提条件，可以添加使用用户和密码了，
接下来完成最主要的事宜了，—-—

再再然后，向Subversion中导入项目：现在我们需要将项目导入到Subversion的库中，只需执行一下命令： svn import d:\EasyON（要放到服务器的项目） svn://localhost/demo（欲放到的服务器目录，事先建立好） -m "initial import" --username jackie --password jackie
　　这样项目就导入到subversion库中啦。

最后既然是做为svn服务器，必须要执行svnserve -d -r D:\svnserver\project，记住不要关闭窗口，服务器嘛，就让它跑着，挂了拉倒，呵呵,本人就这么配置的，都OK，没什么问题，呵呵
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

gg Adsense 再思考

J2EE&forever — Wed, 07 May 2008 17:53:56 +0800

作者: J2EE&forever 链接：http://yangzhiwen911.javaeye.com/blog/190681 发表时间: 2008年05月07日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

　发现是一个很大的问题。
　　
　　关于adsense减少点击区域的问题，看来是gg的失误。
　　
　　自己体验了下：不是新闻，所以不是看了标题，然后点击的。重在文字描述。所以，会看完文字描述再决定是否点击广告。
　　
　　然而，鼠标没反应，去点文字，点击也没反应，于是，打消了可能想看看的念头。
　　
　　看广告的，哪有那么精准的。所以，很多网站，点击率降的厉害。
　　
　　原因应该不是空白区，而是文字区。
　　
　　点文字区算误点？广告就是广告。是一个区域，而不是一个链接。
　　
　　有用的广告，也是种信息。光有个标题，谁知道什么名堂，有是不是看新闻。
　　
　　而如果强调用户体验，点了没反应才叫糟糕的体验呢。
　　
　　但愿gg能尽快纠正自己的失误。不是误点不误点的问题了，几乎所有做文字块广告的站长都受影响。大伙心都寒了，再不给个说法，gg的口碑就要受影响了。
　　
　　

　　附：Adsense的点击之变利大还是弊大？（之前写的）

　　过去，用户可以点击广告的所有文字以及整个背景，而现在，用户只能点击广告的标题和URL。
　　
　　15号开始，大小网站的adsense收入纷纷锐减。多是降了一半，也有不少只剩下五分之一。
　　
　　当然，也有收入提高的，比如那些不是主要投放文字内容广告的网站。
　　
　　那么，真是像官方所说的，减少无效点击，保护广告商的利益？
　　
　　对了一半，也错了一半。这就是要讨论的，利大还是弊大的问题。（原文： Keyr.Net ）
　　
　　1、利。
　　
　　 · 减少无效点击。空白区域也可点击，自然就提供了一种无效点击的可能。
　　 · 有效广告点击付费。点击少了，每一次的广告付费自然更为有效。对于单价高的广告主，这点很重要。
　　 · 改进用户体验。精确点击，站长们必须想方设法让广告跟网页内容融合以提高点击率，所以广告设置会合理，也更精美。
　　 · 与单价有关。误点击会少一点点，那对对gg的price评定自然有影响。不过，广告的价摆在那了，能有多少影响还有待观察。（原文： Keyr.Net ）

　　
　　2、弊。
　　
　　 · 减少点击。主要基于购买行为的网络广告，较大点击区域，有利于产生感性点击行为。本来可以把更多对主题感兴趣的用户带给广告主，不过现在只剩下更理性的网友了。对站长还有广告主都是种损失。
　　 · 广告费花不出去。做广告，无论何种形式，很大一部分都是无用功。就像二八原理，去掉八的无用功，还会产生新的1.6的无用功，结果是原来二的有用功只剩下0.4。点击流量进不来，钱花不出去，做什么广告。对于大部分广告主，adwords是带不来流量了。
　　 · 所谓用户体验。adsense的文字链，有好的体验吗？说心里话，不是网站发展需要钱，我真不想放广告。不是大网站，文字链的广告，排版格式完全不同，插在网页里，就像狗皮膏药似的，能有什么好的体验。都说放gg广告的网站多是垃圾站，那么是怎么变得垃圾的？不就是用户体验的问题吗？
　　 · 站长的冬天。的的确确，之前gg的广告收益率比别的联盟都要高。经这么一变，原来，不同点不在于内容匹配，而是点击区域不同。而现在，恐怕，gg联盟和其他联盟就没什么不同了。站长们无疑是会去尝试其他联盟的。但可怕的是，恐怕，收入的巨变，使很多站长不得不改行了。也许，中小网站对gg没什么，不过，大网站都是从小网站的明天，现在，gg要慢慢失去了明天的优势了。（原文： Keyr.Net ）

　　
　　其实，以上都只是分析。原本期望结果是利大于弊，但看来是弊大于利。
　　
　　因为，根本的问题不在gg的广告上，而是网络广告本身的问题。
　　
　　反而，这一事件证明了一点：较大点击区域是有利于网络广告的。
　　
　　广告就是广告：
　　
　　电视上这么做：咔嚓，当你看的起劲的时候，插上一段。
　　评书里这么说：预知后事如何，请听下回分解。
　　交通中这么放：在你看得见的地方，一个个标志就是一个个广告。
　　分众传媒也挤：看你在等电梯，赶紧放段广告。
　　
　　广告再好，有多少是你感兴趣的信息？
　　不广，何来之告？
　　但正是这种重复，甚至无关的信息包围中，我们都被广告了！
　　
　　总之，忠实于gg的一大批站长肯定是坐不住了。　　
　　的确，跟北方的寒风一起，冬天来了。
　　（ By Aireer 原文： Keyr.Net ）
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

jsp下与FCKeditor后台发布的整合全套（精品）

J2EE&forever — Sun, 27 Apr 2008 20:48:42 +0800

作者: J2EE&forever 链接：http://yangzhiwen911.javaeye.com/blog/187350 发表时间: 2008年04月27日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

开发环境：
Tomcat5.5 Eclipse3.1.1 MyEclipse4.1.1

FCKeditor 版本 FCKeditor_2.2 FCKeditor.Java 2.3 这里需要用到两个包
下载地址：http://www.fckeditor.net/download/default.html

开始：

新建工程，名称为 FCKeditor

解压 FCKeditor_2.2 包中的 edit 文件夹到项目中的 WebRoot 目录
解压 FCKeditor_2.2 包中的 fckconfig.js、fckeditor.js、fckstyles.xml、fcktemplates.xml 文件夹到项目中的 WebRoot 目录
解压 FCKeditor-2.3.zip 包中的 \web\WEB-INF\lib 下的两个 jar 文件到项目的 WebRoot\WEB-INF\lib 目录
解压 FCKeditor-2.3.zip 包中的 \src 下的 FCKeditor.tld 文件到项目的 WebRoot\WEB-INF 目录
删除 WebRoot\edit 目录下的 _source 文件夹

刷新一下工程，有一个文件会出错，不管它是什么错，将错误信息清除

修改 web.xml 文件，加入以下内容

Connector

com.fredck.FCKeditor.connector.ConnectorServlet

baseDir

/UserFiles/

debug

true

SimpleUploader

com.fredck.FCKeditor.uploader.SimpleUploaderServlet

baseDir

/UserFiles/

debug

true

enabled

false

AllowedExtensionsFile

DeniedExtensionsFile

php|php3|php5|phtml|asp|aspx|ascx|jsp|cfm|cfc|pl|bat|exe|dll|reg|cgi

AllowedExtensionsImage

jpg|gif|jpeg|png|bmp

DeniedExtensionsImage

AllowedExtensionsFlash

swf|fla

DeniedExtensionsFlash

Connector

/editor/filemanager/browser/default/connectors/jsp/connector

SimpleUploader

/editor/filemanager/upload/simpleuploader

新建一个提交页 test.jsp 文件和一个接收页 test1.jsp 文件

test.jsp 代码如下：
<%@ page contentType= "text/html;charset=UTF-8 " language= "java "%>
<%@ taglib uri= "/WEB-INF/FCKeditor.tld " prefix= "fck " %>

Test

test1.jsp 代码如下：

TEST

<%=request.getParameter( "testfck ")%>

在 WebRoot 目录下新建 UserFiles 文件夹，在此文件夹下新建 Image 和 Flash 两个文件夹
这样就可以了，现在测试

刚出现的错误就是这里了，必须改为 true

看来这里有BUG，两个不同的提交一个乱码，一个正常！

现在需要减少一些不必要的文件
删除 \WebRoot\editor\filemanager\browser\default\connectors 目录下所有的文件，这些是用来浏览文件的，对于jsp的话是使用了 servlet 来处理，所以这些文件都是多余的

同样的，上传部份的文件也不需要。删除 \WebRoot\editor\filemanager\upload 目录下所有的文件

删除 WebRoot\editor\lang 目录下不需要的语言，如保留中文和英文还有 fcklanguagemanager.js 文件

删除 \WebRoot\editor\skins 目录下不需要的皮肤文件，有三种皮肤，可根据需要进行删除

删除 \WebRoot\editor\dialog\fck_image 目录下 fck_image_preview.html 文件中的部份文字，这些文字是出现在浏览图片时在预览框中的内容
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

正确的解决用户退出问题―JSP和Struts

J2EE&forever — Wed, 16 Apr 2008 12:00:02 +0800

作者: J2EE&forever 链接：http://yangzhiwen911.javaeye.com/blog/183323 发表时间: 2008年04月16日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

在一个有密码保护的Web应用当中，正确妥善的处理用户退出过程并不仅仅只需要调用HttpSession对象的invalidate()方法，因为现在大部分浏览器上都有后退(Back)和前进(Forward)按钮，允许用户后退或前进到一个页面。

在用户退出一个Web应用之后，如果按了后退按钮，浏览器把缓存中的页面呈现给用户，这会使用户产生疑惑，他们会开始担心他们的个人数据是否安全。

实际上，许多Web应用会弹出一个页面，警告用户退出时关闭整个浏览器，以此来阻止用户点击后退按钮。还有一些使用JavaScript，但在某些客户端浏览器中这却不一定起作用。这些解决方案大多数实现都很笨拙，且不能保证在任何情况下都100%有效，同时，它还要求用户有一定的操作经验。

这篇文章以简单的程序示例阐述了正确解决用户退出问题的方案。作者Kevin Le首先描述了一个理想的密码保护Web应用，然后以示例程序解释问题如何产生并讨论解决问题的方案。文章虽然是针对JSP进行讨论阐述，但作者所阐述的概念很容易理解而且能够为其他Web技术所采用。最后最后，作者Kevin Le用Jakarta Struts更为优雅地解决用户退出问题。文中包含JSP和Struts的示例程序 (3,700 words; September 27, 2004)

大部分Web应用不会包含像银行账户或信用卡资料那样机密的信息，但是一旦涉及到敏感数据，就需要我们提供某些密码保护机制。例如，在一个工厂当中，工人必须通过Web应用程序访问他们的时间安排、进入他们的培训课程以及查看他们的薪金等等。此时应用SSL(Secure Socket Layer)就有些大材小用了(SSL页面不会在缓存中保存，关于SSL的讨论已经超出本文的范围)。但是这些应用又确实需要某种密码保护措施，否则，工人（在这种情况下，也就是Web应用的使用者）就可以发现工厂中所有员工的私人机密信息。

类似上面的情况还包括位于公共图书馆、医院、网吧等公共场所的计算机。在这些地方，许多用户共同使用几台计算机，此时保护用户的个人数据就显得至关重要。同时应用程序的良好设计与实现对用户专业知识以及相关培训要求少之又少。

让我们来看一下现实世界中一个完美的Web应用是怎样工作的：

1. 用户在浏览器中输入URL，访问一个页面。

2. Web应用显示一个登陆页面，要求用户输入有效的验证信息。

3. 用户输入用户名和密码。

4. 假设用户提供的验证信息是正确的，经过了验证过程，Web应用允许用户浏览他有权访问的区域。

5. 退出时，用户点击页面的退出按钮，Web应用显示确认页面，询问用户是否真的需要退出。一旦用户点击确定按钮，Session结束，Web应用重新定位到登陆页面。用户现在可以放心的离开而不用担心他的信息会被泄露。

6. 另一个用户坐到了同一台电脑前。他点击后退按钮，Web应用不应该显示上一个用户访问过的任何一个页面。

事实上，Web应用将一直停留在登陆页面上，除非第二个用户提供正确的验证信息，之后才可以访问他有权限的区域。

通过示例程序，文章向您阐述了如何在一个Web应用中实现上面的功能。

一. JSP samples

为了更为有效地向您说明这个解决方案，本文将从展示一个Web应用logoutSampleJSP1中碰到的问题开始。这个示例代表了许多没有正确解决退出过程的Web应用。logoutSampleJSP1包含一下JSP页面：login.jsp, home.jsp, secure1.jsp, secure2.jsp, logout.jsp, loginAction.jsp, 和 logoutAction.jsp。其中页面home.jsp, secure1.jsp, secure2.jsp, 和 logout.jsp是不允许未经认证的用户访问的，也就是说，这些页面包含了重要信息，在用户登陆之前或者退出之后都不应该显示在浏览器中。login.jsp页面包含了用于用户输入用户名和密码的form。logout.jsp页面包含了要求用户确认是否退出的form。loginAction.jsp和logoutAction.jsp作为控制器分别包含了登陆和退出动作的代码。

第二个Web示例应用logoutSampleJSP2展示了如何纠正示例logoutSampleJSP1中的问题。但是第二个示例logoutSampleJSP2自身也是有问题的。在特定情况下，退出问题依然存在。

第三个Web示例应用logoutSampleJSP3对logoutSampleJSP2进行了改进，比较妥善地解决了退出问题。

最后一个Web示例logoutSampleStruts展示了JakartaStruts如何优雅地解决退出问题。

注意：本文所附示例在最新版本的Microsoft Internet Explorer (IE), Netscape Navigator, Mozilla, FireFox和Avant浏览器上测试通过。

二. Login action

Brian Pontarelli的经典文章《J2EE Security: Container Versus Custom》讨论了不同的J2EE认证方法。文章同时指出，HTTP协议和基于form的认证方法并不能提供处理用户退出问题的机制。因此，解决方法便是引入用户自定义的安全实现机制，这就提供了更大的灵活性。

在用户自定义的认证方法中，普遍采用的方法是从用户提交的form中获得用户输入的认证信息，然后到诸如LDAP (lightweight directory access protocol)或关系数据库(relational database management system, RDBMS)的安全域中进行认证。如果用户提供的认证信息是有效的，登陆动作在HttpSession对象中保存某个对象。HttpSession存在着保存的对象则表示用户已经登陆到Web应用当中。为了方便起见，本文所附的示例只在HttpSession中保存一个用户名以表明用户已经登陆。清单1是从loginAction.jsp页面中节选的一段代码以此讲解登陆动作：

Listing 1

//...
//initialize RequestDispatcher object; set forward to home page by default
RequestDispatcher rd = request.getRequestDispatcher( "home.jsp" );
//Prepare connection and statement
rs = stmt.executeQuery( "select password from USER where userName = '" + userName + "'" );
if (rs.next()) {
//Query only returns 1 record in the result set;
//Only 1 password per userName which is also the primary key
if (rs.getString( "password" ).equals(password)) { //If valid password
session.setAttribute( "User" , userName); //Saves username string in the session object
}
else { //Password does not match, i.e., invalid user password
request.setAttribute( "Error" , "Invalid password." );
rd = request.getRequestDispatcher( "login.jsp" );
}
} //No record in the result set, i.e., invalid username
else {
request.setAttribute( "Error" , "Invalid user name." );
rd = request.getRequestDispatcher( "login.jsp" );
}
}
//As a controller, loginAction.jsp finally either forwards to "login.jsp" or "home.jsp"
rd.forward(request, response);
//...

本文当中所附Web应用示例均以关系型数据库作为安全域，但本问所讲述的内容同样适用于其他任何类型的安全域。

三. Logout action

退出动作包含删除用户名以及调用用户的HttpSession对象的invalidate()方法。清单2是从loginoutAction.jsp中节选的一段代码，以此说明退出动作：

Listing 2

//...
session.removeAttribute( "User" );
session.invalidate();
//...

四. 阻止未经认证访问受保护的JSP页面

从提交的form中获取用户提交的认证信息并经过验证后，登陆动作仅仅在HttpSession对象中写入一个用户名。退出动作则刚好相反，它从HttpSession中删除用户名并调用 HttpSession对象的invalidate()方法。为了使登陆和退出动作真正发挥作用，所有受保护的JSP页面必须首先验证 HttpSession中包含的用户名，以便确认用户当前是否已经登陆。如果HttpSession中包含了用户名，就说明用户已经登陆，Web应用会将剩余的JSP页中的动态内容发送给浏览器。否则，JSP页将跳转到登陆页面，login.jsp。页面home.jsp, secure1.jsp, secure2.jsp和 logout.jsp均包含清单3中的代码段：

Listing 3

//...
String userName = (String) session.getAttribute( "User" );
if (null == userName) {
request.setAttribute( "Error" , "Session has ended. Please login." );
RequestDispatcher rd = request.getRequestDispatcher( "login.jsp" );
rd.forward(request, response);
}
//...
//Allow the rest of the dynamic content in this JSP to be served to the browser
//...

在这个代码段中，程序从HttpSession中检索username字符串。如果username字符串为空，Web应用则自动中止执行当前页面并跳转到登陆页，同时给出错误信息“Session has ended. Please log in.”；如果不为空，Web应用继续执行，把剩余的页面提供给用户，从而使JSP页面的动态内容成为服务对象。

五.运行logoutSampleJSP1

运行logoutSampleJSP1将会出现如下几种情形：

• 如果用户没有登陆，Web应用将会正确中止受保护页面home.jsp, secure1.jsp, secure2.jsp和logout.jsp中动态内容的执行。也就是说，假如用户并没有登陆，但是在浏览器地址栏中直接敲入受保护JSP页的地址试图访问，Web应用将自动跳转到登陆页面，同时显示错误信息“Session has ended.Please log in.”

• 同样的，当一个用户已经退出，Web应用将会正确中止受保护页面home.jsp, secure1.jsp, secure2.jsp和logout.jsp中动态内容的执行。也就是说，用户退出以后，如果在浏览器地址栏中直接敲入受保护JSP页的地址试图访问，Web应用将自动跳转到登陆页面，同时显示错误信息“Session has ended.Please log in.”

• 用户退出以后，如果点击浏览器上的后退按钮返回到先前的页面，Web应用将不能正确保护受保护的JSP页面——在Session销毁后（用户退出）受保护的JSP页会重新显示在浏览器中。然而，点击该页面上的任何链接，Web应用都会跳转到登陆页面，同时显示错误信息“Session has ended.Please log in.”

六. 阻止浏览器缓存

上述问题的根源就在于现代大部分浏览器都有一个后退按钮。当点击后退按钮时，默认情况下浏览器不会从Web服务器上重新获取页面，而是简单的从浏览器缓存中重新载入页面。这个问题并不仅限于基于Java(JSP/servlets/Struts) 的Web应用当中，在基于PHP (Hypertext Preprocessor)、ASP、(Active Server Pages)、和.NET的Web应用中也同样存在。

在用户点击后退按钮之后，浏览器到Web服务器（一般来说）或者应用服务器（在java的情况下）再从服务器到浏览器这样通常意义上的HTTP回路并没有建立。仅仅只是用户，浏览器和缓存之间进行了交互。所以即使受保护的JSP页面，例如home.jsp, secure1.jsp, secure2.jsp和logout.jsp包含了清单3上的代码，当点击后退按钮时，这些代码也永远不会执行的。

缓存的好坏，真是仁者见仁智者见智。缓存事实上的确提供了一些便利，但这些便利通常只存在于静态的HTML页面或基于图形或影像的页面。而另一方面，Web 应用通常是面向数据的。由于Web应用中的数据频繁变更，所以与为了节省时间从缓存中读取并显示过期的数据相比，提供最新的数据显得尤为重要！

幸运的是，HTTP头信息“Expires”和“Cache-Control”为应用程序服务器提供了一个控制浏览器和代理服务器上缓存的机制。HTTP头信息Expires告诉代理服务器它的缓存页面何时将过期。HTTP1.1规范中新定义的头信息Cache-Control在Web应用当中可以通知浏览器不缓存任何页面。当点击后退按钮时，浏览器发送Http请求道应用服务器以便获取该页面的最新拷贝。如下是使用Cache-Control的基本方法：

• no-cache:强制缓存从服务器上获取该页面的最新拷贝

• no-store: 在任何情况下缓存不保存该页面

HTTP1.0规范中的Pragma:no-cache等同于HTTP1.1规范中的Cache-Control:no-cache，同样可以包含在头信息中。

通过使用HTTP头信息的cache控制，第二个示例应用logoutSampleJSP2解决了logoutSampleJSP1的问题。logoutSampleJSP2与logoutSampleJSP1不同表现在如下代码段中，这一代码段加入进所有受保护的页面中：

//...
response.setHeader( "Cache-Control" , "no-cache" );
//Forces caches to obtain a new copy of the page from the origin server
response.setHeader( "Cache-Control" , "no-store" );
//Directs caches not to store the page under any circumstance
response.setDateHeader( "Expires" , 0);
//Causes the proxy cache to see the page as "stale"
response.setHeader( "Pragma" , "no-cache" );
//HTTP 1.0 backward compatibility
String userName = (String) session.getAttribute( "User" );
if (null == userName) {
request.setAttribute( "Error" , "Session has ended. Please login." );
RequestDispatcher rd = request.getRequestDispatcher( "login.jsp" );
rd.forward(request, response);
}
//...

通过设置头信息和检查HttpSession对象中的用户名来确保浏览器不会缓存JSP页面。同时，如果用户未登陆，JSP页面的动态内容不会发送到浏览器，取而代之的将是登陆页面login.jsp。

七. 运行logoutSampleJSP2

运行Web示例应用logoutSampleJSP2后将会看到如下结果：

• 当用户退出后试图点击后退按钮，浏览器不会重新显示受保护的页面，它只会显示登陆页login.jsp同时给出提示信息Session has ended. Please log in. • 然而，当按了后退按钮返回的页是处理用户提交数据的页面时，IE和Avant浏览器将弹出如下信息提示：

警告：页面已过期

The page you requested was created using information you submitted in a form. This page is no longer available. As a security divcaution, Internet Explorer does not automatically resubmit your information for you.

Mozilla和FireFox浏览器将会显示一个对话框，提示信息如下：

The page you are trying to view contains POSTDATA that has expired from cache. If you resend the data, any action from the form carried out (such as a search or online purchase) will be repeated. To resend the data, click OK. Otherwise, click Cancel.

在IE和Avant浏览器中选择刷新或者在 Mozilla和FireFox浏览器中选择重新发送数据后，前一个JSP页面将重新显示在浏览器中。显然的，这病不是我们所想看到的因为它违背了 logout动作的目的。发生这一现象时，很可能是一个恶意用户在尝试获取其他用户的数据。然而，这个问题仅仅出现在点击后退按钮后，浏览器返回到一个处理POST请求的页面。

八. 记录最后登陆时间

上述问题的发生是因为浏览器重新提交了其缓存中的数据。这本文的例子中，数据包含了用户名和密码。尽管IE浏览器给出了安全警告信息，但事实上浏览器此时起到了负面作用。

为了解决logoutSampleJSP2中出现的问题，logoutSampleJSP3的login.jsp除了包含username和password的之外，还增加了一个称作lastLogon的隐藏表单域，此表单域将会动态的被初始化为一个long型值。这个long型值是通过调用System.currentTimeMillis()获取到的自1970年1月1日以来的毫秒数。当login.jsp中的form提交时，loginAction.jsp首先将隐藏域中的值与用户数据库中的lastLogon值进行比较。只有当lastLogon表单域中的值大于数据库中的值时Web应用才认为这是个有效的登陆。

为了验证登陆，数据库中lastLogon字段必须用表单中的lastLogon值进行更新。上例中，当浏览器重复提交缓存中的数据时，表单中的lastLogon值不比数据库中的lastLogon值大，因此，loginAction将跳转到login.jsp页面，并显示如下错误信息“Session has ended.Please log in.”清单5是loginAction中节选的代码段：

清单5

//...
RequestDispatcher rd = request.getRequestDispatcher( "home.jsp" );
//Forward to homepage by default
//...
if (rs.getString( "password" ).equals(password)) { //If valid password
long lastLogonDB = rs.getLong( "lastLogon" );
if (lastLogonForm > lastLogonDB) {
session.setAttribute( "User" , userName);
//Saves username string in the session object
stmt.executeUpdate( "update USER set lastLogon= " + lastLogonForm + "
where userName = '" + userName + "'" );
}
else {
request.setAttribute( "Error" , "Session has ended. Please login." );
rd = request.getRequestDispatcher( "login.jsp" ); }
}
else { //Password does not match, i.e., invalid user password
request.setAttribute( "Error" , "Invalid password." );
rd = request.getRequestDispatcher( "login.jsp" );
}
//...
rd.forward(request, response);
//...

为了实现上述方法，你必须记录每个用户的最后登陆时间。对于采用关系型数据库安全域来说，这点可以可以通过在某个表中加上lastLogin字段轻松实现。虽然对LDAP以及其他的安全域来说需要稍微动下脑筋，但最后登陆方法很显然是可以实现的。

表示最后登陆时间的方法有很多。示例logoutSampleJSP3利用了自1970年1月1日以来的毫秒数。这个方法即使在许多人在不同浏览器中用一个用户账号登陆时也是可行的。

九. 运行logoutSampleJSP3

运行示例logoutSampleJSP3将展示如何正确处理退出问题。一旦用户退出，点击浏览器上的后退按钮在任何情况下都不会在浏览器中显示受保护的JSP页面。这个示例展示了如何正确处理退出问题而不需要对用户进行额外的培训。

为了使代码更简练有效，一些冗余的代码可以剔除。一种途径就是把清单4中的代码写到一个单独的JSP页中，其他JSP页面可以通过标签进行使用。

十. Struts框架下的退出实现

与直接使用JSP或JSP/servlets进行Web应用开发相比，另一个更好的可选方案是使用Struts。对于一个基于Struts的Web应用来说，添加一个处理退出问题的框架可以优雅地不费气力的实现。这归功于Struts是采用MVC设计模式的，因此可以将模型和视图代码清晰的分离。另外， Java是一个面向对象的语言，支持继承，可以比JSP中的脚本更为容易地实现代码重用。对于Struts来说，清单4中的代码可以从JSP页面中移植到Action类的execute()方法中。

此外，我们还可以定义一个继承Struts Action类的Action基类，其execute()方法中包含了类似清单4中的代码。通过继承，其他Action类可以继承基本类中的通用逻辑来设置HTTP头信息以及检索HttpSession对象中的username字符串。这个Action基类是一个抽象类并定义了一个抽象方法executeAction()。所有继承自Action基类的子类都必须实现exectuteAction()方法而不是覆盖它。通过继承这一机制，所有继承自Action基类的子类都不必再担心退出代码接口。（plumbing实在不知道怎么翻译了，^+^，高手帮帮忙啊！原文：With this inheritance hierarchy in place, all of the base Action's subclasses no longer need to worry about any plumbing logout code.）。他们将只包含正常的业务逻辑代码。清单6是基类的部分代码：

清单6

publicabstractclass BaseAction extends Action {
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
response.setHeader( "Cache-Control" , "no-cache" );
//Forces caches to obtain a new copy of the page from the origin server
response.setHeader( "Cache-Control" , "no-store" );
//Directs caches not to store the page under any circumstance
response.setDateHeader( "Expires" , 0);
//Causes the proxy cache to see the page as "stale"
response.setHeader( "Pragma" , "no-cache" );
//HTTP 1.0 backward compatibility
if (!this.userIsLoggedIn(request)) {
ActionErrors errors = new ActionErrors();
errors.add( "error" , new ActionError( "logon.sessionEnded" ));
this.saveErrors(request, errors);
return mapping.findForward( "sessionEnded" );
}
return executeAction(mapping, form, request, response);
}
protectedabstract ActionForward executeAction(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException;
privateboolean userIsLoggedIn(HttpServletRequest request) {
if (request.getSession().getAttribute( "User" ) == null) {
return false;
}
return true;
}
}

清单6中的代码与清单4中的很相像，唯一区别是用ActionMapping findForward替代了RequestDispatcher forward。清单6中，如果在HttpSession中未找到username字符串，ActionMapping对象将找到名为 sessionEnded的forward元素并跳转到对应的path。如果找到了，子类通过实现executeAction()方法，将执行他们自己的业务逻辑。因此，在struts-web.xml配置文件中为所有继承自Action基类的子类声明个一名为sessionEnded的forward元素并将其指向login.jsp是至关重要的。清单7以secure1 action阐明了这样一个声明：

清单7

type= "com.kevinhle.logoutSampleStruts.Secure1Action"
scope= "request" >

继承自BaseAction类的子类Secure1Action实现了executeAction()方法而不是覆盖它。Secure1Action类不需要执行任何退出代码，如清单8：

清单8

publicclass Secure1Action extends BaseAction {
public ActionForward executeAction(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
HttpSession session = request.getSession();
return (mapping.findForward( "success" ));
}
}

上面的解决方案是如此的优雅有效，它仅仅只需要定义一个基类而不需要额外的代码工作。将通用的行为方法写成一个继承StrutsAction的基类是者的推荐的，而且这是许多Struts项目的共同经验。

十一. 局限性

上述解决方案对JSP或基于Struts的Web应用都是非常简单而实用的，但它还是有某些局限。在我看来，这些局限并不是至关紧要的。

• 通过取消与浏览器后退按钮有关的缓存机制，一旦用户离开页面而没有对数据进行提交，那么页面将会丢失所有输入的数据。即使点击浏览器的后退按钮返回到刚才的页面也无济于事，因为浏览器会从服务器获取新的空白页面显示出来。一种可能的方法并不是阻止这些JSP页面包含数据数据表格。在基于JSP的解决方案当中，那些JSP页面可以删除在清单4中的代码。在基于Struts的解决方案当中，Action类需要继承自Struts的Action类而非 BaseAction类。

• 上面讲述的方法在Opera浏览器中不能工作。事实上没有适用于Opera浏览器的解决方案，因为Opera浏览器与2616 Hypertext Transfer Protocol—HTTP/1.1紧密相关。Section 13.13 of RFC 2616 states:

User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session.

History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.

幸运的是，使用微软的IE 和基于Mozilla的浏览器用户多余Opera浏览器。上面讲述的解决方案对大多数用户来说还是有帮助的。另外，无论是否使用上述的解决方案， Opera浏览器仍然存在用户退出问题，就Opera来说没有任何改变。然而，正如RFC2616中所说，通过像上面一样设置头文件指令，当用户点击一个链接时，Opera浏览器不会从缓存中获取页面。

十二. 结论

这篇文章讲述了处理退出问题的解决方案，尽管方案简单的令人惊讶，但在所有情况下都能有效地工作。无论是对JSP还是Struts，所要做的不过是写一段不超过50行的代码以及一个记录用户最后登陆时间的方法。在有密码保护的Web应用中使用这些方案能够确保在任何情况下用户的私人数据不致泄露，同时，也能增加用户的经验。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

Tomcat中的ssl加密配置

J2EE&forever — Thu, 24 Jan 2008 13:34:11 +0800

作者: J2EE&forever 链接：http://yangzhiwen911.javaeye.com/blog/159049 发表时间: 2008年01月24日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

最近看到了网上不少的网站都有自己的ssl数据证书，今天自己也配置了一下，并整合到了自己的EasyON数字酒店项目里，先简单给大家介绍一下ssl的相关知识（也可以自己参考官方网站）。
SSL简介
SSL, 或者Secure Socket Layer，是一种允许web浏览器和web服务器通过一个安全的连接进行交流的技术。这意味着将被发送的数据在一端被翻译成密码，传送出去，然后在另一端解开密码，再进行处理。这是一个双向的过程，也就是浏览器和服务器都需要在发送数据之前对它们进行加密。
SSL协定的另一个重要方面是认证(Authentication)。这就是说，在你开始试图通过一个安全连接与一个web服务器交流的时候，这个服务器会要求你的浏览器出示一组证件，通过“鉴定”的方式来证明这就是你所声明的网站。在某些情况下，服务器还会要求你的web浏览器的认证书，证明你就是你所说的那个人。这就是所知的“客户认证”，尽管实际情况中，更多地用在商务-对-商务(B2B)交易，而不是对个人用户。大多数有SSL功能的web服务器不要求客户认证(Client Authentication)。
SSL 和 Tomcat

必须要注意，配置Tomcat来利用secure sockets仅仅在它作为一个独立的web服务器时才有必要。当Tomcat主要作为在另外一个web服务器,如Apache 或Microsoft IIS, 后面的Servlet/JSP容器运行时，通常有必要把主要的web服务器配置来处理与用户的SSL连接。通常，这个服务器会对所有的 SSL-相关的功能进行交涉，然后再把对Tomcat容器的请求解密后传递过去。同样，Tomcat会返回明码的回应，这个回应将被加密后才被送到用户浏览器。在这样的环境下，Tomcat知道与主要web服务器和客户的交流是通过一个安全连接才发生的(因为你的程序需要询问这些情况)，但是它本身并没有参与加密和解密。

认证书：Certificate

为了能实施SSL，一个web服务器对每个接受安全连接的外部接口(IP 地址)必须要有相应的认证书(Certificate)。关于这个设计的理论是一个服务器必须提供某种合理的保证以证明这个服务器的主人就是你所认为的那个人，特别是在接收任何敏感信息之前要这样做。关于Certificates的更广泛的解释超过了这个文档资料的范围，就把一个认证书当作一个英特网地址的“数码驾驶执照”。这个认证书要陈述与这个网站相关联的公司，以及这个网站的所有者或系统管理员的一些基本联系信息。
这个"驾驶执照"由所有人以密码方式签字，其他人非常难伪造。对于进行电子商务 (e-commerce)的网站，或其他身份认证至关重要的任何商业交易，认证书要向大家所熟知的认证权威 (Certificate Authority (CA))如VeriSign或Thawte来购买。这样的认证书可用电子技术证明属实——实际上，认证权威单位会担保它发出的认证书的真实性，如果你信任发出认证书的认证权威单位的话，你就可以相信这个认证书是有效的。
在许多情况下，认证并不是真正使人担忧的事。系统管理员或许只想要保证被服务器传送和接收的数据是秘密的，不会被连接线上的偷窃者盗窃到。庆幸的是，Java提供相对简单的被称为keytool的命令行工具，可以简单地产生“自己签名”的认证书。自己签名的认证书只是用户产生的认证书，没有正式在大家所熟知的认证权威那里注册过，因此不能确保它的真实性。认证也许很重要，也许不重要，完全决定于你的需要。

使用SSL需要考虑的地方

用户第一次试图到你的网站访问被安全保卫的页面时,他(她)通常会被要求提供关于认证的详细信息(如公司名称和联系姓名)，并询问他(她)是否愿意接受这个认证的合法性，并继续进行交易。一些浏览器会提供一个选项来永久地接受所给的认证的合法性，这样一来用户就不用在每次访问你的网站时麻烦地去填写认证信息。有的浏览器没有这一选项。一旦用户认可后，这个认证至少在整个浏览器会话期间被认为是合法的。
虽然SSL协议的设计尽量做到既安全又高效，但是加密和解密是复杂耗时的计算过程。通常没有必要让整个网站都通过SSL来传输，开发人员可以选择部分网页用SSL，部分网页不用SSL。对于一个相对繁忙的网站来说，可以选择保护那些比较敏感的信息，如登陆、个人信息、购物车、付账、信用卡等。那些网页只要把网页地址里http:改为https:，浏览器就会自动把信息按照指定的协议传输出去。
最后,使用根据网名决定的虚拟主机来进行安全连接可能会出现问题。这是SSL协定本身的设计局限。 SSL handshake，就是客户浏览器接受服务器认证，在HTTP请求访问之前必须产生。因此，包含虚拟主机名字的请求信息在认证之前不能被确定，所以不可能给单个IP地址分配多个认证书。如果在单个IP 地址上的所有的虚拟主机需要对照同一个认证书来认证的话，再添加多个虚拟主机不应该干扰服务器上正常的SSL操作。不过要当心，大多数的客户浏览器会按认证书上列出的domain names(主要是官方的， CA-签署的认证书)对照比较服务器的domain name。如果领域名(domain names)不相配，这些浏览器会向客户端用户显示警告。总的来说，只有address-based虚拟主机通常和SSL一起在生产环境中被使用。
产生 Keystore

Tomcat 现在只支持 JKS或PKCS12 格式的keystores. JKS格式是 Java 的标准 KeyStore格式，它可以用 Java 的 keytool 来产生。这个工具在 Java 的 bin 目录里。 PKCS12 格式时互联网的标准，可以用 OpenSSL 和微软的 Key-Manager来修改。
要从头开始产生一个新的keystore，包含一个自签的认证书，从一个终端命令行执行下面的命令：
Window%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA

Unix%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA

( 应该把RSA运算法则作为主要安全运算法则，这保证了与其它服务器和组件的兼容性。)
这个命令会在用户的home directory产生一个叫做" .keystore " 的新文件。要指定一个不同的位置(location)或文件名，在上面所示的keytool 命令里添加-keystore参数，后面紧跟着你的keystore文件的全部路径名。你还需要把这个新的位置在server.xml配置文件中反映出来，这在后面将有描述。例如：
Window%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA \
-keystore \path\to\my\keystore

Unix%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA \
-keystore \path\to\my\keystore

在执行这个命令后，你首先被要求出示keystore密码。Tomcat使用的默认密码是 " changeit "(全都是小写字母)，如果你愿意，你可以指定你自己的密码。你还需要在server.xml配置文件里指定自己的密码，这在以后会有描述。
下一步，你会被要求出示关于这个认证书的一般性信息，如公司，联系人名称，等等。这些信息会显示给那些试图访问你程序里安全网页的用户，以确保这里提供的信息与他们期望的相对应。
最后，你会被要求出示密钥(key)密码，也就是这个认证书所特有的密码(与其它的储存在同一个keystore文件里的认证书不同)。你必须在这里使用与keystore 密码相同的密码。(目前，keytool会提示你按ENTER键会自动帮你做这些)。
如果一切顺利，你现在就拥有了一个可以被你的服务器使用的有认证书的keystore文件。
注意：你的 private key 的密码和 keystore 的密码应该相同。如果不同的话你会得到一下错误信息： java.io.IOException: Cannot recover key 这是一个已知的错误，详细请看： Bugzilla issue 38217
Edit the Tomcat Configuration File

最后的步骤是把你的secure socket配置在$CATALINA_HOME/conf/server.xml文件里, $CATALINA_HOME代表你在其中安装Tomcat 5 的目录。一个例子是SSL连接器的元素被包括在和Tomcat一起安装的缺省server.xml文件里。它看起来象是这样：

<-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 -->

你会注意到Connector元素本身，其默认形式是被注释掉的(commented out)，所以你需要把它周围的注释标志删除掉。然后，你可以根据需要客户化(自己设置)特定的属性。关于各种选项的详细信息，请查阅Server Configuration Reference 。下面的讨论仅仅涵盖设置SSL通信(communication)时大家最感兴趣的那些属性。
这个port属性(默认值是8443)是 TCP/IP端口数码，Tomcat在其上监听安全连接。你可以把它更改成任何你愿意要的数值(如默认的https通信，数目是443)。不过，在许多操作系统中，要想在比1024小的端口数码上运行Tomcat，需要特殊的设置(它超出了这个文档资料的范围)。
在完成这些配置更改后，你必须象通常那样重新启动Tomcat，然后你就可以工作了。你应该可以通过SSL访问Tomcat支持的任何web应用程序。例如，试一下下面的指令：

https://localhost:8443

你应该看到通常的Tomcat splash页面(除非你修改过ROOT web应用程序)。如果不行的话，下面的章节包含一些排除故障的提示。
安装和获取认证权威颁发的认证书

产生一个认证签名请求 (CSR)
为了从你选择的认证权威那里获得认证书，你必须产生一个所谓的认证签名请求(Certificate Signing Request (CSR))。这个认证签名请求被认证权威用来产生鉴定你的网站是“安全的”的认证书。按照下列步骤产生一个CSR：
• 产生一个局部认证书(如前面章节描述那样):

keytool -genkey -alias tomcat -keyalg RSA \
-keystore

• 注意：在某些情况下，要产生一个工作认证书，你必须在“"first- and lastname" field 键入你的网站的域名 (例如www.jaxmao.org)。
• 然后用下列指令产生CSR ：

keytool -certreq -keyalg RSA -alias tomcat
-file certreq.csr \
-keystore

执行这个命令之后你会得到一个文件叫 certreq.csr。然后你可以到发送到认证权威，然后你就可以得到你的认证书。具体步骤可以参考他们的网站的帮助文件。
导入认证书
现在你有了认证书，你可以把它输入到你局部的keystore里。首先你必须输入一个叫做证书链 Chain Certificate 或 Root Certificate 到你的 keystore 里去。在这之后，你可以开始输入你的认证书。
• 从你获得认证书的认证权威那里下载一个Chain Certificate 。
For Verisign.com commercial certificates go to: http://www.verisign.com/support/install/intermediate.html
For Verisign.com trial certificates go to: http://www.verisign.com/support/verisign-intermediate-ca/Trial_Secure_Server_Root/index.html For Trustcenter.de go to: http://www.trustcenter.de/certservices/cacerts/en/en.htm#server
对于Thawte.com ，去http://www.thawte.com/certs/trustmap.html下载
• 把Chain Certificate 输入到你的keystore里边

keytool -import -alias root -keystore \
-trustcacerts -file

• 最后输入你的新的认证书

keytool -import -alias tomcat -keystore \
-trustcacerts -file

Troubleshooting

这里是一些你在设置SSL通信时也许会遇到的常见问题，以及如何解决它们。
• 我在我的日志文件中得到"java.security.NoSuchAlgorithmException"错误。
JVM找不到JSSE JAR 文件。按照所有的指导说明下载并安装JSSE。
• 当Tomcat启动时，我得到一个象 "java.io.FileNotFoundException: {some-directory}/{some-file} not found"的异常。
一个可能的解释是Tomcat不能在它要找的地方找到 keystore文件。在默认的情况下， Tomcat预计 keystore文件在Tomcat运行的用户主目录里被命名为.keystore。如果 keystore存放在别的什么地方，你需要向Tomcat配置文件里的元素添加一个 keystoreFile属性。
• 当Tomcat启动时，我得到一个象"java.io.FileNotFoundException: Keystore was tampered with, or password was incorrect"的异常。
如果没有其他人试图修改你的 keystore 文件，最可能的情况是 Tomcat 用了错误的密码。你可以尝试重新产生 keystore 文件，或修改 Tomcat 设置文件里元素的 keystorePass 属性，还请记住密码是分大小写的。

Miscellaneous Tips and Bits

你可以用下面的办法获取用户 SSL session 的 ID：
String sslID = (String)request.getAttribute("javax.servlet.request.ssl_session");

上面的是大体的介绍，现在简要的说明一下我自己配置成功的过程，
首先进入JDK的安装目录：
C:\Program Files\Java\jdk1.6.0_02\bin

在以上目录下输入如下命令：keytool –genkey –alias tomcat –keyalg RSA –keystore tomcat.keystore

操作完毕后，你会看到当前目录下会多出一个tomcat.keystore这个文件，这个就是生成的密钥文件，

如何让tomcat找到并识别出该文件呢？
修改tomcat里的web.xml，添加如下内容:

maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" debug="0" scheme="https" secure="true"
keystoreFile="C:\Program Files\Java\jdk1.6.0_02\bin\tomcat.keystore"
clientAuth="false" sslProtocol="TLS" />
到此，可以做一个简单的测试，看看你配置后的ssl是否成功，
在IE地址栏里输入：https://localhost:8443......
如果出现证书那就是成功了，就这么简单。

接下来就是如果把此ssl应用到我自己的项目里，应用过程无非也就是在请求我本地项目的路径后，会出示数据证书，来进行验证是否是当前会话的发起者，如果是的话，那么会把当前请求的路径转发给https处理，建立ssl连接，此时你仔细看，会发现你刚才输入的http://locahot:8080/your-project会被处理为https://localhost:8443/your-project 。

在此需要在全局配置一下web.xml，内容是这样(需要验证用户名和密码，我的都为tomcat)：

Success

GET

POST

web-user

tomcat

role1

CONFIDENTIAL

BASIC

如果不需要验证的话，那么配置文件这么加：

Success

GET

POST

CONFIDENTIAL

这样就好了，你可以自己去试试，然后看看效果。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

球型鼠标已经上市了

J2EE&forever — Thu, 24 Jan 2008 13:23:41 +0800

作者: J2EE&forever 链接：http://yangzhiwen911.javaeye.com/blog/159045 发表时间: 2008年01月24日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

上个周末，打算去看看最近市面上都有什么新产品，于是就和我同学去北京市中关村电子产品店逛了逛，走了很多家，值得一提的是看到了各个柜台摆的极其吸引人眼球的球型鼠标，感觉很个性，手感不错，最后同学认识人，帮我以最低价成交一款白色球型鼠标，回家用用感觉不错，就顺便查查相关资料，原来这种鼠标是深圳国鲨科技发展有限公司为用户新体验而设计的，（英文简称）ISC，一个很有前途的公司，玩了这么多年的电脑，在工作编程的同时，也可以感受一下球型鼠标所带来的新感觉。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

收集一些国内Blogger的英文博客

J2EE&forever — Tue, 22 Jan 2008 13:43:43 +0800

作者: J2EE&forever 链接：http://yangzhiwen911.javaeye.com/blog/158301 发表时间: 2008年01月22日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

英文学习类 - 李晨兄的李晨英语教学网（中文）和Adventures of Stevenlichen（英文）。李晨是北京外国语大学英语教育专业毕业，现在英国硕士留学。李晨英语教学网（中文）关注于英语学习，Adventures of Stevenlichen 关注于一些国内新闻。

个人生活类 - 其次我要说的是Realwind。Realwind已经在他的In This Life 坚持了一年的英文写作，话题主要关注一些网络应用服务。

IT、技术类 - 月光博客英文站 Moonlight Blog 。早期Moonlight上IT评论的文章较多，现在主要关注WordPress，尤其是WordPress插件。

新闻类 - LoLand -lol(Laugh out Loud) land , a land of Asian wonderful things. 范围很广。

还有关注WordPress的柠檬，Ya,I Yee，China Web2.0 Review，由aw组织的ifgogo.com，David Feng新建的techblog86，等等。

当然，这样的英文博客确实太多，我只能列举几个比较熟悉的。需要查找更多的英文博客，可以去China Blog List。China Blog List 主要收集关注于中国的英文博客，其自我简介是：

The China Blog List (CBL) is a collection of links to English language weblogs focused on China. The CBL plays an important role in providing the rest of the world with convenient access to firsthand accounts and independent views of China.

有些朋友问到我的英文博客，今天我也晒出来 - ToBloggers，初步定位是Blogging Tips。由于能力有限，很少更新，怕写不好，也一直不敢公布出来。今后会尽量更新，主题也不限于博客技巧，会比较随意。

写英文博客的建议：不要把自己当成中国的对外窗口，以广播中国 News为己任；就把自己融入英文世界去写，以所有懂英文的人为读者；避免文字和语法的错误，但不要怕犯错误。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

通过SponsoredReviews.com写英文付费评论

J2EE&forever — Tue, 22 Jan 2008 13:41:26 +0800

作者: J2EE&forever 链接：http://yangzhiwen911.javaeye.com/blog/158300 发表时间: 2008年01月22日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

SponsoredReviews.com是一个提供英文话题广告的网站，在上面我们能看到很多话题，价钱不一。SponsoredReviews.com对blogger的门槛比较低，一般blogger注册后就可以通过验证。blogger在通过验证后，就可以在“Find Advertiser”菜单栏下寻找感兴趣的话题，然后就提交写作申请，等待Advertiser（广告主）的允许。广告主确认让我们写这个话题时，我们就可以开始写了。大概就是这么个流程。下面说说一些细节问题。

1. 添加博客 - 注册比较简单，注册之后就是添加博客。
* 添加中文博客注意博客名称，要填写英文名称，最好用反应博客主题的短语，如blogging tips，make money blogging等。这样在申请话题时比较容易通过（从前博客上学来的）。
* 选择好博客所属分类，这一点很重要。
* 自己给博客定价 - 在博客通过审核后， SponsoredReviews.com会给博客做一个评级，然后按这个等级给出建议的定价。我们可以自己定价，稍微定高点，如100美元。因为定价太低，比如博客定价是30美元，而广告主给他们自己的话题定价在40-100美元，那么blogger就不能申请这个话题。
2. 付款问题 - 收款时最好选用PayPal， SponsoredReviews.com是按周付款，没有最低付款额。
3. SponsoredReviews.com给博客评的等级会按月刷新
4. 申请话题广告后，不一定能马上得到广告主的认可，这个过程可能比较长。我申请的有些话题已经快一个月了，还没有得到广告主的验证，既没有通过，也没有拒绝。
5. 一个话题能得到多少钱？这还是根据广告主给话题的定价而定。如果广告主给自己的话题定价在10-1000美元，而你的博客定价在100美元，那么申请这个话题时，你可以填写的价格就是10-100美元之间。如果你就填100美元，那就可以得到65美元，因为 SponsoredReviews.com会收取35%的服务费（这是我的情况）
6. 一个SponsoredReviews.com帐号可以添加无数个博客
7. 在博客上写的付费评论最少保持一个月的时间，一个月后你可以删除这个评论。
8. 有适合你博客的话题时，SponsoredReviews.com会发邮件提示。现在我基本上每天都能收到这类邮件。

一个多月来，我已经申请了十几个话题，但是只有一个通过审核了（还没写），已经有几个被拒绝了，还有几个等待广告主确定。感觉用中文博客做这个不太好，广告主还是喜欢英文博客的。我现在收到的是介绍http://www.onlinecheck.com的话题，说句实话，看了半天，我还不清楚这个网站到底是干吗的，或者说不能用我的语言来对其做评论。看来英文水平还是太差。

感兴趣的朋友还是可以试试(开始注册)，毕竟这是我所知道的最好的英文话题广告商。

http://www.waterylife.com/articles/get-paid-review-from-sponsoredreviews.html
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

写博客也可以挣钱哦

J2EE&forever — Tue, 22 Jan 2008 13:13:23 +0800

作者: J2EE&forever 链接：http://yangzhiwen911.javaeye.com/blog/158294 发表时间: 2008年01月22日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Google Adsense（推荐）

Google Adsense是全球最大的搜索引擎google提供的一种网络广告联盟模式，如果你拥有自己的网站，当申请成为google的广告发布商之后，就可以在自己的网站发布与网页内容相关的广告。Google Adsense是按点击计费，当用户点击广告时，即可获得点击广告佣金。Google Adsense是google为加盟网站提供的一种将网站访问量转化为收入的网络赚钱模式。网站上我们经常看到“Google 提供的广告”，就是这种广告模式。

Feedsky话题广告

话题广告是Feedsky提供的一种专门针对Blog的新广告形式。由Blogger按照广告主的要求撰写评论文章，然后广告主向Blogger付费。这种形式充分利用了Blog传播快、面积广的特点，宣传效果很好。你只需要拥有一个Blog就可以了，把Blog添加到Feedsky中，并验证身份后就可以激活话题广告服务了。

博狗口碑营销

博狗的博客口碑是类似于Feedsky的话题广告。博客在通过审核后，会接到博狗通过Email发过来的话题邀请。博客对话题发表相关评论，通过审核后就可以得到广告主的支付。

Text Link Ads（推荐）

Text Link Ads-文本链接广告，是国内外很多博客的主要赚钱方式。在Text Link Ads这个平台上，用户可以通过它出售自己网站的链接位置，也可以在上面为自己的网站购买链接。这种链接不仅可以带来流量，还有助于搜索引擎优化。另外，文字链接也不会占据博客较大的广告位。对于流量小或者找不到广告主的博客和网站，Text link ads 是一个很不错的选择，而且它跟Google Adsense 的投放不相冲突。根据经验，PR 值为2 或者以上的博客申请的话，一般都比较容易通过。即使没有通过验证的博客，也可以通过推荐会员（affiliate program）获得收入。

SponsoredReviews（推荐）

SponsoredReviews.com是一个提供英文话题广告的网站，在上面我们能看到很多话题，价钱不一。SponsoredReviews.com对blogger的门槛比较低，一般blogger注册后就可以通过验证。blogger在通过验证后，就可以在“Find Advertiser”菜单栏下寻找感兴趣的话题，然后就提交写作申请，等待Advertiser（广告主）的允许。广告主确认让我们写这个话题时，我们就可以开始写了。

ReviewMe

ReviewMe是国外专门的付费评论服务商，已经成为许多国外知名博客的重要赚钱渠道。广告商通过reviewme在你的博客上购买付费评论。 reviewme根据博客的alexa,technorati排名、Google PR值和RSS的订阅数量，对你的博客定价。如果对这个价格不满意，你也可以自己定价。评论的观点褒贬不一，但有字数上的要求。目前reviewme的很多评论都要求用英语写，很难通过中文博客的申请。

Bloggerwave

Bloggerwave也是一个提供话题广告的在线服务平台。广告发布商联系Bloggerwave发布广告，Bloggerwave通过用户博客的关键字和介绍发放相关广告让博客写评论，验证合格就将报酬打入用户PayPal账户。由于刚成立不久，bloggerwave的接受门槛比较低，一般博客很容易通过。因此很多中文博客都注册了Bloggerwave。虽然单篇评论的价格不高，一般是5-10美元，但毕竟是美元，换成人民币也是不错的收入。

原文出处：http://www.waterylife.com/make-money-online
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

Tomcat中的ssl加密配置

J2EE&forever — Tue, 22 Jan 2008 11:17:04 +0800

作者: J2EE&forever 链接：http://yangzhiwen911.javaeye.com/blog/158257 发表时间: 2008年01月22日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

最近看到了网上不少的网站都有自己的ssl数据证书，今天自己也配置了一下，并整合到了自己的EasyON数字酒店项目里，先简单给大家介绍一下ssl的相关知识。
SSL简介
SSL, 或者Secure Socket Layer，是一种允许web浏览器和web服务器通过一个安全的连接进行交流的技术。这意味着将被发送的数据在一端被翻译成密码，传送出去，然后在另一端解开密码，再进行处理。这是一个双向的过程，也就是浏览器和服务器都需要在发送数据之前对它们进行加密。
SSL协定的另一个重要方面是认证(Authentication)。这就是说，在你开始试图通过一个安连接与一个web服务器交流的时候，这个服务器会要求你的浏览器出示一组证件，通过“鉴定”的方式来证明这就是你所声明的网站。在某些情况下，服务器还会要求你的web浏览器的认证书，证明你就是你所说的那个人。这就是所知的“客户认证”，尽管实际情况中，更多地用在商务-对-商务(B2B)交易，而不是对个人用户。大多数有SSL功能的web服务器不要求客户认证(Client Authentication)。
SSL 和 Tomcat

必须要注意，配置Tomcat来利用secure sockets仅仅在它作为一个独立的web服务器时才有必要。当Tomcat主要作为在另外一个web服务器,如Apache 或Microsoft IIS, 后面的Servlet/JSP容器运行时，通常有必要把主要的web服务器配置来处理与用户的SSL连接。通常，这个服务器会对所有的 SSL-相关的功能进行交涉，然后再把对Tomcat容器的请求解密后传递过去。同样，Tomcat会返回明码的回应，这个回应将被加密后才被送到用户浏览器。在这样的环境下，Tomcat知道与主要web服务器和客户的交流是通过一个安全连接才发生的(因为你的程序需要询问这些情况)，但是它本身并没有参与加密和解密。

认证书：Certificate

为了能实施SSL，一个web服务器对每个接受安全连接的外部接口(IP 地址)必须要有相应的认证书(Certificate)。关于这个设计的理论是一个服务器必须提供某种合理的保证以证明这个服务器的主人就是你所认为的那个人，特别是在接收任何敏感信息之前要这样做。关于Certificates的更广泛的解释超过了这个文档资料的范围，就把一个认证书当作一个英特网地址的“数码驾驶执照”。这个认证书要陈述与这个网站相关联的公司，以及这个网站的所有者或系统管理员的一些基本联系信息。
这个"驾驶执照"由所有人以密码方式签字，其他人非常难伪造。对于进行电子商务 (e-commerce)的网站，或其他身份认证至关重要的任何商业交易，认证书要向大家所熟知的认证权威 (Certificate Authority (CA))如VeriSign或Thawte来购买。这样的认证书可用电子技术证明属实——实际上，认证权威单位会担保它发出的认证书的真实性，如果你信任发出认证书的认证权威单位的话，你就可以相信这个认证书是有效的。
在许多情况下，认证并不是真正使人担忧的事。系统管理员或许只想要保证被服务器传送和接收的数据是秘密的，不会被连接线上的偷窃者盗窃到。庆幸的是，Java提供相对简单的被称为keytool的命令行工具，可以简单地产生“自己签名”的认证书。自己签名的认证书只是用户产生的认证书，没有正式在大家所熟知的认证权威那里注册过，因此不能确保它的真实性。认证也许很重要，也许不重要，完全决定于你的需要。

使用SSL需要考虑的地方

用户第一次试图到你的网站访问被安全保卫的页面时,他(她)通常会被要求提供关于认证的详细信息(如公司名称和联系姓名)，并询问他(她)是否愿意接受这个认证的合法性，并继续进行交易。一些浏览器会提供一个选项来永久地接受所给的认证的合法性，这样一来用户就不用在每次访问你的网站时麻烦地去填写认证信息。有的浏览器没有这一选项。一旦用户认可后，这个认证至少在整个浏览器会话期间被认为是合法的。
虽然SSL协议的设计尽量做到既安全又高效，但是加密和解密是复杂耗时的计算过程。通常没有必要让整个网站都通过SSL来传输，开发人员可以选择部分网页用SSL，部分网页不用SSL。对于一个相对繁忙的网站来说，可以选择保护那些比较敏感的信息，如登陆、个人信息、购物车、付账、信用卡等。那些网页只要把网页地址里http:改为https:，浏览器就会自动把信息按照指定的协议传输出去。
最后,使用根据网名决定的虚拟主机来进行安全连接可能会出现问题。这是SSL协定本身的设计局限。 SSL handshake，就是客户浏览器接受服务器认证，在HTTP请求访问之前必须产生。因此，包含虚拟主机名字的请求信息在认证之前不能被确定，所以不可能给单个IP地址分配多个认证书。如果在单个IP 地址上的所有的虚拟主机需要对照同一个认证书来认证的话，再添加多个虚拟主机不应该干扰服务器上正常的SSL操作。不过要当心，大多数的客户浏览器会按认证书上列出的domain names(主要是官方的， CA-签署的认证书)对照比较服务器的domain name。如果领域名(domain names)不相配，这些浏览器会向客户端用户显示警告。总的来说，只有address-based虚拟主机通常和SSL一起在生产环境中被使用。
产生 Keystore

Tomcat 现在只支持 JKS或PKCS12 格式的keystores. JKS格式是 Java 的标准 KeyStore格式，它可以用 Java 的 keytool 来产生。这个工具在 Java 的 bin 目录里。 PKCS12 格式时互联网的标准，可以用 OpenSSL 和微软的 Key-Manager来修改。
要从头开始产生一个新的keystore，包含一个自签的认证书，从一个终端命令行执行下面的命令：
Window%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA
Unix%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA

( 应该把RSA运算法则作为主要安全运算法则，这保证了与其它服务器和组件的兼容性。)
这个命令会在用户的home directory产生一个叫做" .keystore " 的新文件。要指定一个不同的位置(location)或文件名，在上面所示的keytool 命令里添加-keystore参数，后面紧跟着你的keystore文件的全部路径名。你还需要把这个新的位置在server.xml配置文件中反映出来，这在后面将有描述。例如：
Window%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA \
-keystore \path\to\my\keystore

Unix%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA \
-keystore \path\to\my\keystore

在执行这个命令后，你首先被要求出示keystore密码。Tomcat使用的默认密码是 " changeit "(全都是小写字母)，如果你愿意，你可以指定你自己的密码。你还需要在server.xml配置文件里指定自己的密码，这在以后会有描述。
下一步，你会被要求出示关于这个认证书的一般性信息，如公司，联系人名称，等等。这些信息会显示给那些试图访问你程序里安全网页的用户，以确保这里提供的信息与他们期望的相对应。
最后，你会被要求出示密钥(key)密码，也就是这个认证书所特有的密码(与其它的储存在同一个keystore文件里的认证书不同)。你必须在这里使用与keystore 密码相同的密码。(目前，keytool会提示你按ENTER键会自动帮你做这些)。
如果一切顺利，你现在就拥有了一个可以被你的服务器使用的有认证书的keystore文件。
注意：你的 private key 的密码和 keystore 的密码应该相同。如果不同的话你会得到一下错误信息： java.io.IOException: Cannot recover key 这是一个已知的错误，详细请看： Bugzilla issue 38217
Edit the Tomcat Configuration File

最后的步骤是把你的secure socket配置在$CATALINA_HOME/conf/server.xml文件里, $CATALINA_HOME代表你在其中安装Tomcat 5 的目录。一个例子是SSL连接器的元素被包括在和Tomcat一起安装的缺省server.xml文件里。它看起来象是这样：

<-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 -->

你会注意到Connector元素本身，其默认形式是被注释掉的(commented out)，所以你需要把它周围的注释标志删除掉。然后，你可以根据需要客户化(自己设置)特定的属性。关于各种选项的详细信息，请查阅Server Configuration Reference 。下面的讨论仅仅涵盖设置SSL通信(communication)时大家最感兴趣的那些属性。
这个port属性(默认值是8443)是 TCP/IP端口数码，Tomcat在其上监听安全连接。你可以把它更改成任何你愿意要的数值(如默认的https通信，数目是443)。不过，在许多操作系统中，要想在比1024小的端口数码上运行Tomcat，需要特殊的设置(它超出了这个文档资料的范围)。
在完成这些配置更改后，你必须象通常那样重新启动Tomcat，然后你就可以工作了。你应该可以通过SSL访问Tomcat支持的任何web应用程序。例如，试一下下面的指令：

https://localhost:8443

你应该看到通常的Tomcat splash页面(除非你修改过ROOT web应用程序)。如果不行的话，下面的章节包含一些排除故障的提示。
安装和获取认证权威颁发的认证书

产生一个认证签名请求 (CSR)
为了从你选择的认证权威那里获得认证书，你必须产生一个所谓的认证签名请求(Certificate Signing Request (CSR))。这个认证签名请求被认证权威用来产生鉴定你的网站是“安全的”的认证书。按照下列步骤产生一个CSR：
• 产生一个局部认证书(如前面章节描述那样):

keytool -genkey -alias tomcat -keyalg RSA \
-keystore

• 注意：在某些情况下，要产生一个工作认证书，你必须在“"first- and lastname" field 键入你的网站的域名 (例如www.jaxmao.org)。
• 然后用下列指令产生CSR ：

keytool -certreq -keyalg RSA -alias tomcat
-file certreq.csr \
-keystore

执行这个命令之后你会得到一个文件叫 certreq.csr。然后你可以到发送到认证权威，然后你就可以得到你的认证书。具体步骤可以参考他们的网站的帮助文件。
导入认证书
现在你有了认证书，你可以把它输入到你局部的keystore里。首先你必须输入一个叫做证书链 Chain Certificate 或 Root Certificate 到你的 keystore 里去。在这之后，你可以开始输入你的认证书。
• 从你获得认证书的认证权威那里下载一个Chain Certificate 。
For Verisign.com commercial certificates go to: http://www.verisign.com/support/install/intermediate.html
For Verisign.com trial certificates go to: http://www.verisign.com/support/verisign-intermediate-ca/Trial_Secure_Server_Root/index.html For Trustcenter.de go to: http://www.trustcenter.de/certservices/cacerts/en/en.htm#server
对于Thawte.com ，去http://www.thawte.com/certs/trustmap.html下载
• 把Chain Certificate 输入到你的keystore里边

keytool -import -alias root -keystore \
-trustcacerts -file

• 最后输入你的新的认证书

keytool -import -alias tomcat -keystore \
-trustcacerts -file

Troubleshooting

这里是一些你在设置SSL通信时也许会遇到的常见问题，以及如何解决它们。
• 我在我的日志文件中得到"java.security.NoSuchAlgorithmException"错误。
JVM找不到JSSE JAR 文件。按照所有的指导说明下载并安装JSSE。
• 当Tomcat启动时，我得到一个象 "java.io.FileNotFoundException: {some-directory}/{some-file} not found"的异常。
一个可能的解释是Tomcat不能在它要找的地方找到 keystore文件。在默认的情况下， Tomcat预计 keystore文件在Tomcat运行的用户主目录里被命名为.keystore。如果 keystore存放在别的什么地方，你需要向Tomcat配置文件里的元素添加一个 keystoreFile属性。
• 当Tomcat启动时，我得到一个象"java.io.FileNotFoundException: Keystore was tampered with, or password was incorrect"的异常。
如果没有其他人试图修改你的 keystore 文件，最可能的情况是 Tomcat 用了错误的密码。你可以尝试重新产生 keystore 文件，或修改 Tomcat 设置文件里元素的 keystorePass 属性，还请记住密码是分大小写的。

Miscellaneous Tips and Bits

你可以用下面的办法获取用户 SSL session 的 ID：
String sslID = (String)request.getAttribute("javax.servlet.request.ssl_session");

上面的是大体的介绍，现在简要的说明一下我自己配置成功的过程，
首先进入JDK的安装目录：
C:\Program Files\Java\jdk1.6.0_02\bin

在以上目录下输入如下命令：keytool –genkey –alias tomcat –keyalg RSA –keystore tomcat.keystore

操作完毕后，你会看到当前目录下会多出一个tomcat.keystore这个文件，这个就是生成的密钥文件，

如何让tomcat找到并识别出该文件呢？
修改tomcat里的web.xml，添加如下内容:

maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" debug="0" scheme="https" secure="true"
keystoreFile="C:\Program Files\Java\jdk1.6.0_02\bin\tomcat.keystore"
clientAuth="false" sslProtocol="TLS" />
到此，可以做一个简单的测试，看看你配置后的ssl是否成功，
在IE地址栏里输入：https://localhost:8443......
如果出现证书那就是成功了，就这么简单。

接下来就是如果把此ssl应用到我自己的项目里，应用过程无非也就是在请求我本地项目的路径后，会出示数据证书，来进行验证是否是当前会话的发起者，如果是的话，那么会把当前请求的路径转发给https处理，建立ssl连接，此时你仔细看，会发现你刚才输入的http://locahot:8080/your-project会被处理为https://localhost:8443/your-project 。

在此需要在全局配置一下web.xml，内容是这样(需要验证用户名和密码，我的都为tomcat)：

Success

GET

POST

web-user

tomcat

role1

CONFIDENTIAL

BASIC

如果不需要验证的话，那么配置文件这么加：

Success

GET

POST

CONFIDENTIAL

这样就好了，你可以自己去试试，然后看看效果。
如果有错误的地方请赐教。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

我的flex学习经验

J2EE&forever — Tue, 22 Jan 2008 11:12:12 +0800

作者: J2EE&forever 链接：http://yangzhiwen911.javaeye.com/blog/158255 发表时间: 2008年01月22日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

最近一直在做有关JSP开发的网站，重复的登陆验证页面，重复的语法以及重复的跳转页面，熟悉的不能再熟悉的struts构建流程。
做项目的期间，还自己学习了HIBERNATE,ajax，等等
所以在写JSP代码的同时，也考虑到了JSP可以不可以和特效结合起来，于是在工作完成的时候，自己会去看一些flex的东西，很有好的界面，很炫的组件，真是被flex所深深吸引。
1. Flex结合tomcat
Flex只是个运行库或者说是web application，用来处理mxml类型的文件，其运行库就是Flex.war，所以它可以部署到任何一个兼容的jsp服务器上：比如 Tomcat， weblogic、websphere、Jrun，Jboss等，而Coldfusion目前也是运行库或者说是web application，用来处理cfml类型的文件，其运行库就是cfusion.war，所谓standalone版本的coldfusion只是把 jrun和cfusion.war一起打包安装而已，所以就没有Flex和Coldfusion结合之说了。
所以要想tomcat做flex的服务器，很简单的说安装完Flex Dada Services，目前名字叫Adobe_LiveCycle_Data_Services，我本人安装的版本是（Adobe_LiveCycle_Data_Services_ES_2.5.1）
需要的话可以共享给大家，你也可以自己去下载，下载完不用去找序列号，因为我差了半天也没查到，默认可以有60天的试用期。
下一步需要做的就是把flex项目下的flex.war和samples.war拷贝到tomcat下的webapp目录里，考完后，tomcat会自动部署文件，不需操作，这样输入项目路径 : http://localhost:8080/samples 就可以看到里面的flex程序了，就是这么简单。
2.FLEX结合JSP
其实flex里夹杂了ajax异步调用的技术，因为本身ACTIONSCRIPT就和JAVASCRIPT有着异曲同工之妙。我做了一个例子是参考手册上面的，不过自己改了一下，大概的程序就是这样的，首页当然是flex服务器来解析hxml，然后后台通过jsp文件交互数据库，然后把数据动态的封装成xml格式，最后在把xml标签与flex程序绑定在一起，就可以了。这样当运行flex前端程序的时候，后台就会把绑定好的数据显示到了flex的组件里，看起来很有成就感。哈哈。。。。。。

我的mxml代码：

{test.text}

file:///C|/Documents and Settings/Administrator/桌面/banner.gif

注释：
(1).application里creationComplete="feedRequest.send()" 这一属性是每次程序运行时，调用httpservice 里的Send（）方法，在这个程序里实际上是请求http://localhost:8080/test/index.jsp，
把得到的数据以xml形式返回，把内容绑定到DataGrid 的组件上，flex是这样来绑定的：

(2).dataProvider="{feedRequest.lastResult.rss.channel.item}" 此句的语法，应该是，得到最后的返回结果，按照rss，channel，item此三层标签去绑定所遍历的数据，

以上代码就是创建分别叫题目和路径的2个列，title和url即为遍历出来的信息源标签。
(3).click="navigateToURL(new URLRequest(dgPosts.selectedItem.url));" linkbutton的属性，强调一点的是dgPosts是datagrid中所产生的选项，而navigateToURL（new URLRequest（url））此句就是另外打开一个url。

3. Flex 和数据库MYSQL（目前公司用的MYSQL）
这个时候可能有的人要问了，flex如何传值呢？后台怎么接收有FLEX界面提交的值呢？
带着这个问题，让我们进入下个简单的程序：
先写一个简单的flex组件，代码如下

这就是一个基本的用户交互界面，做完特效可以变成如下界面：

这个时候需要注意的是数据绑定，
数据的绑定也是通过FLEX标签来定义的。。

{username.text}

{password.text}

这个代码说明了，我本地项目的MyJsp.jsp会去接受此控件传过来的值，之前我测试是否接收到了FLEX传值的时候，是这样测试的：
在MyJsp.jsp页面打印
<% out.println(“success”); %>

结果半天就没看到jsp页面输出成功信息。

后来经过MSN里探讨，原来flex本身就有着异步调用的过程，所以它不会显示JSP页面的内容，

呵呵，，原来是这样，，浪费我半天的时间，还以为程序错误呢。。很感谢他。。

这样以来，我在jsp页面直接打印
<% System.out.println(username); %>
<% System.out.println(password); %>

这样在后台就打印出来了 username 和 password；

所以，可以得到了flex 页面传来的数据，这样后台就完全可以用 jsp 或者 struts 等来实现和数据库的交互过程。

看来flex入门真是不容易啊。。如果没有人引路，估计我还自己停留在某一个地方，原地不动呢，
所以总体看来，程序都是相同的，高人的指点也是必须的，呵呵
以上内容都是我自己总结的，希望能相互学习。。呵呵

4. flex 和 xml
以下内容是我查资料时候看到的，代码可以直接用，很快捷。。。。。。。

其实很久以前我就有过用Flash动态生成xml菜单的想法，可是…(种种原因)…没实现，当时非常不甘心。
现在有Flex了，我又想把xml菜单做一下，昨天搞了一天，终于小有成果，就来和大家分享一下，我认为代码其实写的不好，因为我是从网上七拼八凑拿来的代码，好的是一种思路，‘拖动式的思路’（暂且用这个词吧）
代码说明：主要代码段都在Panel组件里，而在Panel里Tree的作用举足轻重，Tree的功能很强大，在内部就拖动根节点和叶节点，任意拖动节点就免去了代码实现节点们顺序的问题，我当时就被它这点折服了，还又个垃圾箱，你可以将根节点或叶节点拖到垃圾箱里，这样也免去了删除节点的麻烦，我其实就只完成了个增加节点的功能，并且还只是在最后增加节点（不过由于其天生可拖动性，我这样就完全可以了，你可以把生成的最后节点拖到想要的位置啊！！）。好了，我也不多说了，取之于网民，给之于网民，代码和大体效果下面都有，(里面又很多效果，希望你都理解！毕竟flex太强大了)Enjoy it!!

import mx.collections.XMLListCollection;

[Bindable]
var companyList:XMLListCollection=new XMLListCollection();

private function addFolder():void
{
var newNode:XML =

;
companyList.addItem(newNode);
}

private function addLeaf():void
{
var newNode:XML =
companyList.addItem(newNode);
}

]]>

dataProvider="{companyList}" labelField="@label" dragEnabled="true" dropEnabled="true"/>

click="txt.text=''+XmlTree.dataProvider;menu.dataProvider=XmlTree.dataProvider;menu.labelField='@label'"/>

dataProvider="{[{label:'修改Label', data:'@label'}, {label:'修改Url', data:'@url'}]}"
change="XmlTree.labelField=cobox.selectedItem.data;panel.title=cobox.selectedLabel">

因为不是我写的，所以没有注释，关键是体会到了Flex强大，不过是就太占资源了，哎，，，如果有两全其美的本法该有多好啊。。。。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐