语源科技BlogJava-枫言枫语

世界各国主要货币名称（英文简称）

玉澍淋枫 — Mon, 24 Dec 2007 08:05:00 GMT

各国货币简称

英镑 GBP
比利时法郎 BEF
新西兰元 NZD
港币 HKD
意大利里拉 ITL
奥地利先令 ATS
美元 USD
日元 JPY
挪威克朗 NOK
瑞士法郎 CHF
加拿大元 CAD
泰国铢 THB
德国马克 DEM
澳大利亚元 AUD
丹麦克朗 DKK
法国法郎 FRF
西班牙比塞塔 ESP
菲律宾比索 PHP
新加坡元 SGD
欧元 EUR
瑞典克朗 SEK
荷兰盾 NLG
芬兰马克 FIM
澳门元 MOP

全部货币

阿富汗尼Afghani AFA
阿联酋迪拉姆Dirham AED
阿尔巴尼亚Albania Lek ALL
阿尔及利亚第纳尔 DZD
安道尔法郎 FRF
亚美尼亚 AMD
安第列斯群岛盾 ANG
安哥拉 AON
阿根廷比索 ARP
奥地利先令 ATS
澳大利亚元 AUD
安圭拉东加勒比海元 XCD
阿鲁巴岛弗罗林 AWF
安提瓜和巴布达岛东加勒比海元 XCD
阿塞拜疆 AZM
波斯尼亚和黑塞哥维那 BAK
巴巴多斯元 BBD
比利时法郎 BEF
保加利亚列弗 BGL
布隆迪法郎 BIF
巴哈马群岛元 BSD
文莱元 BND
玻利维亚 BOB
巴西 BRL
不丹卢比 BTR
博茨瓦纳 BWP
洪都拉斯元 BZD
加拿大元 CAD
贝宁法郎 XAF
刚果法郎 CDF
瑞士法郎 CHF
智利比索 CLP
中国人民币 CNY
哥伦比亚比索 COP
哥斯达黎加 CRC
捷克克郎 CZK
古巴比索 CUP
佛得角 CVE
塞普路斯镑 CYP
英镑 GBP
德国马克 DEM
丹麦克郎 DKK
多美尼加比索 DOP
布基纳法索 XAF
厄瓜多尔 ECS
缅甸元 MMK
爱沙尼亚 EEK
埃及镑 EGP
厄立特里亚 ERN
西班牙彼萨塔 ESP
柬埔寨 KHR
埃塞俄比亚 ETB
喀麦隆 XAF
欧元 EUR
芬兰 FIM
斐济元 FJD
法国法郎 FRF
中非共和国 XAF
乍得 XAF
乔治亚 GEL
加纳塞第 GHC
直布罗陀 GIP
冈比亚 GMD
几内亚法郎 GNF
希腊 GRD
危地马拉 GTQ
圭亚那 GYD
港币 HKD
新西兰元 NZD
克罗地亚 HRK
海地 HTG
匈牙利福林 HUF
印尼卢比 IDR
爱尔兰 IEP
以色列 ILS
印度卢比 INR
伊拉克第纳尔 IQD
伊朗里亚尔 IRR
冰岛克郎 ISK
荷兰盾 NLG
意大利里拉 ITL
牙买加元 JMD
约旦第纳尔 JOD
日圆 JPY
肯尼亚先令 KES
萨尔瓦多El SVC
朝鲜 KPW
赤道几内亚 XAF
韩国 KRW
埃塞俄比亚 ETB
科威特第纳尔 KWD
哈萨克斯坦 KZT
老挝 LAK
黎巴嫩镑 LBP
斯里兰卡卢比 LKR
利比里亚元 LRD
莱索托 LSL
立陶宛 LTL
卢森堡法郎 LUF
拉托维亚 LVL
利比亚第纳尔 LYD
摩洛哥迪拉姆 MAD
摩尔多瓦 MDL
马达加斯加 MGF
马其顿第纳尔 MKD
加蓬 XAF
冈比亚 GMD
蒙古 MNT
澳门 MOP
毛里塔尼亚 MRO
马耳他 MTL
毛里求斯卢比 MUR
马尔代夫 MVR
希腊德拉玛 GRD
墨西哥比索 MXP
格陵兰 DKK
马来西亚 MYR
莫桑比克 MZM
纳米比亚 NAD
尼日利亚奈拉 NGN
尼加拉瓜 NIO
危地马拉 GTQ
挪威克郎 NOK
几内亚 GNF
尼泊尔卢比 NPR
新西兰 NZD
阿曼 OMR
巴拿马 PAB
秘鲁 PEN
菲律宾比索 PHP
巴基斯坦卢比 PKR
波兰 PLZ
巴拉圭 PYG
卡塔尔 QAR
罗马尼亚 ROL
俄罗斯卢布 RUR
卢旺达法郎 RWF
沙特阿拉伯 SAR
苏丹 SDD
瑞典克郎 SEK
新加坡 SGD
斯洛文尼亚 SIT
斯洛伐克 SKK
塞拉里昂 SLL
约旦 JOD
索马里 SOS
叙利亚 SYP
斯威士兰 SZL
泰铢 THB
塔吉克斯坦 TJR
土库曼斯坦 TMM
突尼斯 TND
拉托维亚 LVL
汤加 TOP
土耳其 TRL
台湾 TWD
坦桑尼亚 TZS
乌克兰 UAH
乌干达 UGX
乌拉圭 UYU
美圆 USD
乌兹别克斯坦 UZS
委内瑞拉 VEB
越南 VND
瓦努阿图 VUV
也门 YER
南斯拉夫 YUN
南非 ZAR
赞比亚 ZMK
津巴布韦 ZWD
尼加拉瓜 NIO
尼日利亚 NGN

玉澍淋枫 2007-12-24 16:05 发表评论

应聘外企，怎样的求职简历吸引眼球

玉澍淋枫 — Mon, 15 Oct 2007 05:28:00 GMT

应聘外企，必须先投送自己的求职简历，求职简历通过了，才会进入下一个招聘程序，否则会被挡在外企的大门之外。那么，应聘外企，什么样的求职简历最容易通过呢？

1 柯达：内容符合职位要求

柯达公司认为，简历上提供的信息是否符合职位要求将起决定性作用。一份简历，需要列明应聘的职位，提供本人的基本信息、教育背景、工作经历以及所接受的培训。如果所列相关经历和专业背景符合应聘职位的要求，并且来自相近的公司，那么这些简历就比较容易受到青睐。

例如公司曾经要招聘一位重点客户代表，有一个应聘者的简历写得非常有针对性。因为柯达的部分产品属于快速消费品，该应聘者能始终围绕着这一行业的特点来写，对于自己先前在快速消费品行业的工作经历写得很详细，比如如何联系超市、大卖场，如何与相关部门沟通，如何洽谈业务，如何指导布置货柜等等，而其他信息如个人基本情况、教育背景、培训经历、个人特长等，都简单列明。可谓详略得当，一看就知道该应聘者对于相关行业的熟悉程度，这种简历就很受招聘人员的欢迎。

又如柯达曾经要招聘一位技术市场代表，该职位需要具备数码知识。大多数应聘者在自己的简历中只是简单地提及一句：本人具有一定的数码知识。但有一份简历却与众不同，他所附的一张报名照片就是他自己运用数码技术制作的，他在简历中详细写明了其所使用数码相机的品牌、技术参数、冲印设备，以及不同设备之间的优劣差别等等。虽然简历中显示他目前并不在相关职位任职，但显然他已具备了较强的相关技术背景，从而为他本人赢得了面试的机会。

2 惠普：亮点特点鲜明突出

惠普公司希望应聘者能够用最短的时间吸引招聘人员，多了解公司招聘的职位，多了解职位的要求，然后在自己的简历里强调自己适合这个职位的东西，让招聘人员知道你有这方面的能力、经验和知识。所以，一般来说应该有一个亮点或者最突出的部分，概述性地交代自己是什么学校毕业，有几年工作经验，有哪些证明等等，让招聘人员看到这几条就觉得这个人是我想要的。这样，招聘人员也节省时间，对路不对路马上就可以区分出来。

另外，应聘者要写明自己与别人不同的地方在哪里，什么方面是特别适合惠普公司所招聘职位的。很多人投简历时是千篇一律的，不管投什么样的公司和职位都用一样的简历。可能对一个大学毕业生来说，他也只能这个样子，因为他基本的经验和教育就是这些，这样投还是可以理解的。但是对有几年工作经验的人来说，他还是应该针对不同的公司和不同的岗位做简历，这样才会有比较好的效果。

3 ibm：充分表述职业能力
ibm公司招聘人员表示，他们在看简历的时候，对于内容版式比较清楚、各个段落比较分明的简历，会比较容易有良好的第一印象。另外，主题要明确一些，寄简历最好是分析招聘启事以后，针对这个工作的要求，表达自己的能力是不是符合ibm公司的要求，把能够表达自己能力的重点写得突出一些。在简历中，讲到自己做过一些什么样的工作的时候，最好不要只说明做过什么工作，而且要强调自己是怎么样做到的，业绩如何。总之，主题明确一点的简历比较容易通过。

4 微软：简单明了有针对性

一般来说，微软希望简历既简单又明确，能让读到它的人感觉清楚明了，不复杂不麻烦。具体来说，微软主要有四个职能部门，包括全球的技术支持中心、亚洲研究院、研发中心和销售市场部，各个职能部门的要求不太一样。像技术性的职位，如技术支持中心、研发中心或研究院，微软希望能够在简历中罗列出参加过的学术会议、研究成果，这样会比较受欢迎，而且，要列出自己的技术特点，比如像“我熟悉java编程语言”或“我对微软的windows平台是专家级的了解”等，也就是说要能够注明自己的优势。像市场销售的职位，希望简历中有一些对自己优势的总结，比如说“我是一个做市场非常强的人，我的优势是做销售”或者说“我在某一方面有自己的特长”，这样很容易引起读简历的人甚至招聘人员的重视，这样的简历很容易被从一大堆简历中挑选出来，至少让人有兴趣看，有兴趣看了才可能有参加笔试或者面试的机会。

玉澍淋枫 2007-10-15 13:28 发表评论

如何让你的简历更吸引人？

玉澍淋枫 — Mon, 15 Oct 2007 05:16:00 GMT

写一份动人的简历也是找工作中最难的一部分，但是，通过下面十二步，这件事不再那么难了。

1. 使用"从事事件=结果"这种格式

内容就是一切，所以一定要突出你的能力，成就以及过去经验，使你的简历更出众。仅有漂亮的外表而无内容的简历是不会吸引人的。

仔细分析你的能力并阐明你能够胜任这份工作。强调以前的事件，然后一定要写上结果，比如："组织了公司人员调整，削减了无用的员工，每年节约￥550000。"

2. 让简历醒目

简历的外表不一定要强调，但它应该醒目。审视一下简历的空白处，用这些空白处和边框来强调你的正文，或使用各种字体格式，如斜体，大写，下划线，首字突出，首行缩进或尖头。

用计算机来打印你的简历。

3. 尽量使你的简历简短，只使用一张纸

雇主可能会扫视你的简历，然后花30秒来决定是否召见你。所以一张纸效果最好。如果你有很长的职业经历，一张纸写不下，试着写出最近5-7年的经历或组织出一张最有说服力的简历，删除那些无用的东西。

4. 为你的简历定位

雇主们都想知道你可以为他们做什么。含糊的，笼统的并毫无针对性的简历会使你失去很多机会。为你的简历定位。如果你也有多个目标，最好写上多份不同的简历，在每一份上突出重点。这将使你的简历更有机会脱颖而出。

5. 写上简短小结

这其实是最重要的一个部分，"小结"可以写上你最突出的几个优点。没有什么应聘者写这几句话，但雇主们却认为这是引起注意的好办法。

6. 强调成功经验

雇主们想要你的证据证明你的实力。记住要证明你以前的成就以及你的前雇主得到了什么益处，包括你为他节约了多少钱，多少时间等，说明你有什么创新等。

7. 力求精确

阐述你的技巧、能力、经验要尽可能的准确，不夸大也不误导。确信你所写的与你的实际能力及工作水平相同。还要写上你以前工作的时间和公司。

8. 使用有影响力的词汇

使用这种词汇，如：证明的，分析的，线形的，有创造力的，和有组织的。这样可以提高简历的说服力，每句都用点这种词汇。

9. 用词要注意

在调查中许多官员都说到了这个问题。他们最讨厌错字别字。许多人说："当我发现错别字时我就会停止阅读。"所以，认真写。雇主们总认为错别字说明人的素质不够高。

10. 不要写上个人爱好

现在，在简历上写上个人信息如婚姻状况，血型，身高等已不在是必须。许多公司都乐意接受没有个人信息的简历。

11. 最后测试

记住，你的简历应该回答了以下问题：它是否清楚并能够让雇主尽快知道你的能力？是否写清了你的能力？是否写清了你要求这份工作的基础？有东西可删除吗？

尽力完善你的简历直到最好。

玉澍淋枫 2007-10-15 13:16 发表评论

广域网中的计算机为什么采用层次结构方式进行编址?

玉澍淋枫 — Wed, 19 Sep 2007 04:04:00 GMT

广域网中,分组往往要经过许多结点交换机的转发才能到达目的地.每个结点交换机都有一个转发表,结点交换机根据转发表决定该如何转发分组,如果转发表中存放了到达每一主机的路由,显然广域网中的主机数越多,查找转发表就越浪费时间,为了减少查找转发表所花费的时间,广域网采用层次结构的地址。

把一个二进制数表示的主机地址分成两部分，第一部分的二进制数表示该主机所连接的分组交换机的编号，是第一层地址；而后一部分的二进制数表示所连接的分组交换机的端口号，或主机的编号，是第二层地址。

这样转发表可简化为二部分内容：分组要发往的目的站的交换机号，以及下一跳交换机号。

玉澍淋枫 2007-09-19 12:04 发表评论

配置Apache

玉澍淋枫 — Tue, 07 Aug 2007 09:52:00 GMT

配置Apache

一、配置文件

　　Apache是一个后台运行的程序，没有界面。所有的配置，都包含在配置文件里。主配置文件是：

　　　　C:\Program Files\Apache Group\Apache\conf\httpd.conf

　　如果要修改Apache的配置，可以用任何一个文本编辑工具（例如记事本）编辑这个配置文件。在配置文件里，以“#”开头的行是注释行。

二、配置选项

　　在配置文件里的主要选项如下：

#Listen 3000
#Listen 12.34.56.78:80

　　Apache的IP地址和端口。一般来说不需要设置，Apache会绑定在本机所有IP地址的80端口上。

Port 80

　　Apache的端口。默认值是80。

ServerName user.dns0755.net

　　Web服务器的名字。安装时输入的“Server Name”就是保存在这里。

DocumentRoot "C:/Program Files/Apache Group/Apache/htdocs"

　　这是网站的根目录。如果您想把网站文件存放在“D:\myweb”目录下，可以把DocumentRoot后面的目录修改为“D:/myweb”。

Options Indexes FollowSymLinks MultiViews

　　为了安全起见，请把上面的“Indexes”删掉。否则别人可以浏览到您网站里的所有文件。

DirectoryIndex index.html

　　默认首页文件名。在浏览器里输入一个地址（例如http://user.dns0755.net/）的时候，Apache会查找这个默认的首页文件打开。如果要配置多个默认首页文件名，请用空格分开。

ScriptAlias /cgi-bin/ "C:/Program Files/Apache Group/Apache/cgi-bin/"

　　CGI文件存放路径。

三、高级配置

1、设置虚拟目录

　　在配置文件中找下面这行：

　　在这行下面添加如下内容：

　　　　Alias /vdir/ "c:/comexe/"

　　　　c:/comexe/">
　　　　Options MultiViews
　　　　AllowOverride None
　　　　Order allow,deny
　　　　Allow from all
　　　　

　　这样，通过访问 http://user.dns0755.net/vdir/，就可以访问到c:\comexe\目录下的内容。

　　Apache默认开设了两个虚拟目录：“/icons/”和“/manual/”。这两个虚拟目录没有用，可以在配置文件中删除。

2、如何解决中文网页显示乱码

（1）在配置文件中找包含“AddLanguage”或“AddCharset”的行，在这些行最前面增加一行：

　　　　AddDefaultCharset GB2312

（2）养成良好的习惯，在每个网页的里加入这行：

　　一般的中文版网页编辑工具（例如FrontPage、Dreamweaver等）都会自动加上这行。

3、如何解决中文文件名无法访问

　　在ie中选择工具 -> internet选项 -> 高级 -> 取消“总是以UTF-8发送URL”。

　　这个方法很麻烦，请尽量不要使用中文的网站文件名。

请注意：

1、Apache配置过程中最关键的两点是：网站根目录和默认首页文件名。必须要把网站文件放在所指定的网站根目录下，而且默认首页文件名必须要设置正确，否则将看不到您的网页。

2、每次配置文件更改后，要重新启动Apache才会生效。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=179564

玉澍淋枫 2007-08-07 17:52 发表评论

使用Struts Menu实现权限管理

玉澍淋枫 — Mon, 06 Aug 2007 05:10:00 GMT

Struts Menu也是Matt Raible的作品，我以前一直在找能够在Java里面指定实现页面上树形菜单和下拉菜单的东西，我去年找到一个JS的东西，可以从XML文件中读取结构，我使用XSLT来生成显示的菜单，后来感觉不灵活，也没有用到项目上，2004年11月开始接触AppFuse，发现里面有个Struts Menu，从例子看起来外观还不错，用起来，发现更不错，可以在配置文件中指定那些角色可以看到当前的链接，如果roles中没有指定的角色进入系统后，则自动隐藏。我在去年的一个小项目用了一下，发现还行，至少不用我把逻辑嵌入到一堆JS里面。

因为今年上半年要对以前的一个系统进行升级，要根据用户或者角色的权限把一些菜单隐藏起来，如果使用Struts Menu的roles的话，则角色是写死在代码里面的，就是"硬编码"(hardcode)，而且这里的角色是Application Server上配置的，在Tomcat上配置还算简单，在WebLogic等大型的服务器程序上配置，必须使用他们提供的Console软件，否则，要自己写好几个文件，比较繁琐，而且这些角色是在安装是就指定的，如果用户以后想添加新的角色名字，还要修改应用服务器的配置文件（不管是手工，还是代码处理）。

如果你的系统负责处理权限，如生成用户、角色，还要为角色、用户指定有操作哪些模块的哪些操作，一个系统很可能有几十个或者上百个角色（往极端情况去想，呵呵），那么如果能够动态的控制显示哪些菜单项是我们系统中必须解决的问题，而Struts Menu完全胜任这样的要求，具体实现可以参看Struts Menu的下载文件中的文档，需要重点看的是http://demo.raibledesigns.com/struts-menu/dynamicMenu.jsp(动态构建菜单结构)和http://struts-menu.sourceforge.net/security.html（这篇文章我视而不见，以为没有用处，谢谢倦兔的提醒，^_^）。这两篇文章的用法是独立的，并不一定都要实现，如果你的菜单项是固定的，短期不会有所变动，那么可以写死到配置文件中，然后用第二篇文章中说的那样，写一个类，实现接口PermissionsAdapter，isAllowed方法中传入菜单项的名字，然后决定是否显示该项菜单，

String[] menus = request.getParameterValues("menuNames");

注释：menuNames是从数据库中读出的记录的集合（数组），你也可以用其他机构，

然后放入使用request.setAttribute("menuNames", String[] 变量) 放入request中。

       PermissionsAdapter permissions = new SimplePermissionsAdapter(menus);//menus是菜单名字的数组
       request.getSession().setAttribute("YourAdapter", permissions);} //"YourAdapter"随便起的名字，
       //但要和配置文件中的permissions="YourAdapter""部分的一致。

在里面添加permissions="你的类名"(上文中是"YourAdapter），如果此处的perssions的值为 "rolesAdapter"，则Struts Menu不会从寻找你的Adapter类了，而是直接创建一个RolesPermissionsAdapter实例，然后使用这个实例处理角色(根据配置的rolse的角色名字判断是否显示菜单项)。其实PermissionsAdapter是RolesPermissionsAdapter类的一个具体的实现，如果你不写自己的适配器，则Struts Menu使用自己的这个适配器处理菜单显示。

后一篇文章的最后还举了一个过滤器实现上述功能的例子，你可以参考一下，这个试验并不是完全由我实现的，是由倦兔提供思路和文档的URL，我只是把思路整理一下，让其他同事实现，我把它记录下来，以免以后再看的时候忘了。^_^

另外，我还发现Struts Menu的例子里面还有关于Tab页的实现脚本，如果我早点发现它，我就不会在上一个系统中每个JSP页面都嵌入一大堆同样的Table垃圾代码了！！！

另外，这种做法并没有完全实现控制用户操作的作用，因为用户只是不能看到某个功能的菜单链接而已，如果，他记住了有操作权限的人员操作时发出的请求的 URL，比如:http://rabbit8.blogchina.com?edit?method=delete&sid=5，那么，他就可以手工输入URL，同样可以删除、修改、查看某些他不应该看到的东西，这有些属于Web安全方面的东西了，呵呵，如果想实现更加完善的权限管理功能，还应改在执行操作前进行用户身份和权限的验证，从而避免上述方法的攻击或者破坏。如果你对这方面的内容感兴趣，可以查看一些相关书籍，如《Web安全大曝光》、《J2EE安全大曝光》系列，我春节期间看了这2本书，对于跨站脚本攻击还不太明白，如果哪位明白，请不吝指教，谢谢！^_^

玉澍淋枫 2007-08-06 13:10 发表评论

基于Struts的权限实现

玉澍淋枫 — Mon, 06 Aug 2007 04:59:00 GMT

基于Struts的权限实现

作者:Javazealot(转贴) 来源:justjsp.com 入库时间:2004-07-11 点击数:327

基于Struts的权限实现
一：概念介绍

1:)资源
可以使用的系统资源.比如注册用户是一种资源，修改用户信息也是一种资源.
资源在系统中呈现为一棵树.假如用户管理是一个节点.用户注册，用户信息
修改为用户管理的叶子。叶子具有不可分割性.

2:)角色
绑定可操作资源的集合。
比如系统管理员，可以使用全部资源.
一般用户，可以注册和修改查看自己的信息.
角色可以有依赖角色。也就是说现在系统中存在
RoleA,RoleB,RoleC ,RoleD 四种角色.
RoleD 倚赖RoleA
假设一个用户的角色是RoleD.
根据倚赖关系。默认有RoleA 的可使用资源.

3:)用户
系统中的使用者，因为角色可以倚赖，所以一个用户只有一种角色.

二：资源的分配
上述三个概念之间的绑定关系为用户绑定一个角色，角色绑定若干资源.
角色绑定资源有两种绑定，一种是绑定叶子，一种绑定节点。绑定节点有
两种一种只绑定节点下的叶子，一种绑定节点下所有的叶子.在系统中权
限的分配需要做到一个角色可以访问整个资源树中的任意节点和叶子的组合.

三：资源树的构造
我们使用namespace的方式去构造一棵树.根节点为空。
下面形如:sysytem.user.useradd,system.department.add,system.common
上面的可以理解为system是一个节点,并有两个子节点user,department,
一个叶子common

四：Struts中的资源标识
在Struts中一个Action的配置通常如下:

type="org.apache.struts.webapp.example.EditSubscriptionAction"
attribute="subscriptionForm"
scope="request"
validate="false">

为了使没一个Action绑定到一个跟节点下,我们加一个选项把上面的配置修改为
type="org.apache.struts.webapp.example.EditSubscriptionAction"
attribute="subscriptionForm"
scope="request"
rights="system.user"
validate="false">

为了在xml parse的时候可以加载上面的配置，我们需要修改一下Struts的源代码
修改org/apache/struts/config/ActionConfig
增加如下代码

protected String rights="common";

public String getRights(){
return this.rights;
}

public void setRights(String rights){
if (configured) {
throw new IllegalStateException("Configuration is frozen");
}
this.rights=rights;
}

假如修改成功后我们把ActionMapping 打印出来会看到相关的配置

五：权限分配的实现
1:)实现角色资源的绑定
在我的实现中我使用xml文件去配置如下：

2:)权限的判断
这一部分有很多中实现方式，一种所有的Action继承BaseAction
在BaseAction里面实现，并在没一个Action里面去调用判断.

另外一种交给Struts去判断
org.apache.struts.action.RequestProcessor
里面有一个processActionPerform
调用Action的execute去执行Action
我们可以修改processActionPerform让其在执行execute前先执行权限检查
如果是这样的话，必须修改org.apache.struts.action.Action
让一个方法去实现权限判断.

如果使用第二种需要修改蛮多源代码，不建议对Struts不熟悉的人使用

玉澍淋枫 2007-08-06 12:59 发表评论

基于struts项目权限解决方案的探索

玉澍淋枫 — Mon, 06 Aug 2007 04:50:00 GMT

前一段时间我曾专门阅读过一些关于JAAS的资料，网上这方面的资料不多，篇篇文章都是侧重于讲述一些核心的JAAS类（不过讲的蛮不错的，呵呵。。。对于这方面的入门极好），而对于应用方面给我的感觉就像：

“天啊，几乎没有人用到它~！”

还好chinaxp论坛的源代码中涉及了这方面的应用，而且它们就是那样做的，这其中给了我不少启示。

目前在我参与的一个项目（正在开发）中，我采用JAAS的验证机制（其中的授权部分因为没有非常熟悉的掌握所以暂时没有采用，而暂时采用另外一种方法来解决，这种方法再接下来的部分涉及。）

先说一些我以其为背景的这个项目：

它算是一个比较大的项目（省级高速公路路政工作平台），大的划分可以分为10个大模块26个子模块，具体分为基本信息维护、路政案件、路政审批等等大模块；权限主要是（对某一模块的维护、浏览以及打印等）

经过讨论我们在设计权限的时候是这样考虑的：

分为三个“角色”：用户、用户组、权限；

他们的关系为：用户属于某个用户组；权限下放到用户组。（这一切都是和“当场客户代表”共同讨论决定的。）

如下表是权限的内容：

rightID
rightName

00100
维护基本信息

00101
浏览基本信息

00500
维护路产信息

00501
浏览路产信息

……
……

其中系统模块用xml配置，如：

module_config.xml

维护基本信息

00100

维护路产信息

00500

……

(采用单例模式在容器启动的时候进行解析)

把具体的权限绑定到每一个*.do请求：

request_source.xml

useradmin.do

显示用户信息维护主页面

00100

……

（也是在容器启动的时候解析并放到容器中）

系统中权限流程控制基本上我把它分为两个步骤：

1．利用filter以及JAAS来进行非法用户的过滤

其中所有的*.JSP也要通过*.do来引导，这样就能确保整个系统中没有权限“盲点”，也即可以保证每一个*.do都是“干净的”。

这其中涉及到以下几个文件，具体的代码在此不给出：

（1）iRoadLogin.config

IRoadLogin{

com.ifreeway.iroad.security.DataBaseLoginModule required debug=true;

};

这个文件在创建LoginContext对象的时候根据这个文件来确定该加载哪个LoginModule对象。

（2）ParseRequestFilter.java
对每一个请求进行非法用户的过滤。

（3）DataBaseLoginModule.java

（4）SimpleCallbackHandler.java

上边的几个类的介绍涉及过多的JAAS核心类的内容，建议阅读下面连接的内容：

http://www.yesky.com/20030114/1648365.shtml这篇文章对于你了解JAAS绝对有帮助，你也可以通过我的站点来阅读更多的JAAS资料： http://plateau.sicool.com

2． 2. 在确保是合法用户（已经通过1。的过滤的用户）请求*.do的时候再来判断该用户是否拥有请求该do的权利。
可以在每个action的父类BaseAction中创建一个方法来判断是否合法，如：

public Boolean validateRight(String _request_do) throws ErrorRequestException{

//取得user所在的组:a

//根据_request_do,假设其为：useradmin.do

//获得其所在的组:b

//然后根据两次组(a 和 b)是否是同一组来判断该请求是否合法

//此时的a和b都是很容易在容器中获得的，不会损失效能。

}

前提：项目中的又一个公共的BaseAction，其他的action都要继承它。这一点我想使用struts开发项目的开发员都是很容易理解的。

如：有一个UserAdminAction.java

那么在这个执行它的时候首先调用validateRight(“useradmin.do”)来进行权限判断，如果返回false，那么跳转到error页。

其实我上边所写出的解决方法在我现在的项目中是够用的。是谁说过：“够用为原则”？项目的权限设计这部分实在是个非常大的讨论题目，这里算是抛砖引玉，希望给你一点提示，也希望你可以给我一些更好方法的提示，

玉澍淋枫 2007-08-06 12:50 发表评论

独乐乐不如众乐乐，->让FS的3个盾。换成玫瑰环绕。

玉澍淋枫 — Sat, 04 Aug 2007 04:05:00 GMT

独乐乐不如众乐乐，->让FS的3个盾。换成玫瑰环绕。

工具：winhex 或是 ultraedit 就是16进制编辑工具。很容易找到的。这里我们用ultraedit来介绍
方法：
1,进入完美世界游戏目录。找到elementskill.dll并备份他，它应该类似于D:\完美世界\element\elementskill.dll

2.用 ultraedit 打开目录中的：elementskill.dll

3.按下ctrl+r 或是选择菜单：搜索->替换

4.以。把土盾换成菊花为例：

在查找中输入：C5CDCAAFBBA4BCD72E676678
在替换中输入：BED5BBA8BBB7C8C62E676678

然后按下替换按钮。然后保存。就可以了。

注意。字串前后不要有空格。详细代码如下：
土盾C5CDCAAFBBA4BCD72E676678
水盾BAAEB1F9BBA4BCD72E676678
火盾C1D2D1E6BBA4BCD72E676678
菊花BED5BBA8BBB7C8C62E676678
百合B0D9BACFBBB7C8C62E676678
玫瑰C3B5B9E5BBB7C8C62E676678

本来还有康乃馨的。不过字数超过了。顺便放上吧
康乃馨：BFB5C4CBDCB0BBB7C8C62E676678

PS:不能修改此DLL的长度不然进不了游戏，替换时也不能改变他的长度。如把FS的盾。换成MM.MG的盾是行不通的。
此外。那些以技能为名字扩展名为.dds 的请不要乱改。那是技能图标。。
别人看的还是正常的。

因为别的职业多少没有盾的存在。所以替换有些麻烦。现在解决方法：
用玫瑰环绕替换霜刃状态的效果就可以了。这样找FS上了霜刃。就会玫瑰缠身了。
代码：
霜刃状态CBAAC8D0D7B4CCAC2E676678

万蛊食天CDF2B9C6CAB3CCEC2E736763
火海刀山BBF0BAA3B5B6C9BD2E736763
神火符C9F1BBF0B7FB2E736763
万蛊食天CDF2B9C6CAB3CCEC2E736763
火海刀山BBF0BAA3B5B6C9BD2E736763
炙炎阵D6CBD1D7D5F32E736763
烈火炽翼C1D2BBF0B3E3D2ED2E736763
涌泉D3BFC8AA2E736763
润泽C8F3D4F32E736763
寒露BAAEC2B62E736763
霜刃CBAAC8D02E736763
玄冰水龙D0FEB1F9CBAEC1FA2E736763
落石术C2E4CAAFCAF52E736763
飞沙术B7C9C9B3CAF52E736763
泰山压顶CCA9C9BDD1B9B6A52E736763
缩地术CBF5B5D8CAF52E736763
冰雹BAF9BAA22E736763
般若心经B0E3C8F4D0C4BEAD2E736763
石破天惊CAAFC6C6CCECBEAA2E736763
烈火符C1D2BBF0B7FB2E736763
火煞天灯BBF0C9B7CCECB5C62E736763

芒果:替换烈焰为百合  女MG最佳

查找:  C1D2D1E6D6AECAB82E676678

替换:  B0D9BACFBBB7C8C62E676678

给大家发过来,FS朋友们没事可以玩玩.

[ 本帖最后由极度§嚣张于 2007-8-4 11:19 编辑 ]

图片附件: 2.bmp (2007-8-4 10:36, 45.54 K)

screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='点击在新窗口查看全图\nCTRL+鼠标滚轮放大或缩小';}" onmouseover="if(this.resized) this.style.cursor='hand';" onclick="if(!this.resized) {return false;} else {window.open('attachments/month_0708/20070804_18b3b1ba1481f4b8cfc4ASdJyJFJMS4m.bmp');}" onmousewheel="return imgzoom(this);" border="0">

图片附件: 6b30.bmp (2007-8-4 10:36, 47.91 K)

screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='点击在新窗口查看全图\nCTRL+鼠标滚轮放大或缩小';}" onmouseover="if(this.resized) this.style.cursor='hand';" onclick="if(!this.resized) {return false;} else {window.open('attachments/month_0708/20070804_20e188d7d2e5021d3c8caCEJEweaR9oa.bmp');}" onmousewheel="return imgzoom(this);" border="0">

图片附件: c.bmp (2007-8-4 10:37, 45.04 K)

screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='点击在新窗口查看全图\nCTRL+鼠标滚轮放大或缩小';}" onmouseover="if(this.resized) this.style.cursor='hand';" onclick="if(!this.resized) {return false;} else {window.open('attachments/month_0708/20070804_9c4bfeef7a4168994f24078TEC4JGUa6.bmp');}" onmousewheel="return imgzoom(this);" border="0">

玉澍淋枫 2007-08-04 12:05 发表评论

关于权限的数据库设计

玉澍淋枫 — Fri, 03 Aug 2007 12:43:00 GMT

关于权限的数据库设计

不管是在网站开发还是MIS系统开发中，涉及到多用户的软件系统都会遇到这个问题，如何比较优雅的解决这个问题也一直是大家经常探讨的热门话题，本文试着谈论一下自己的观点，希望和大家共同切磋。

方法一：

用户表：
T_UserInfo
   id
   name

对象表:
T_Object
   id
   name

权限表
T_Access
   accessid
   userid（外键，来自用户表）
   objectid（外键，来自对象表）
   access(用代码记录用户的权限组合：
       1000 浏览
       1100 浏览、添加
       1110 浏览、添加、编辑
       1111 浏览、添加、编辑、删除
       等)

方法二：

用户表：
T_UserInfo
   id
   name

对象表:
T_Object
   id
   name
   access1(代表浏览，保存用户的id号，用逗号分隔)
   access2(代表浏览、添加)
   access3(代表浏览、添加、编辑)
   access4(代表浏览、添加、编辑、删除)

孰优孰劣？
---------------------------------------------------------------

我們用的是第一種
WINDOWS系統用的也是第一種

---------------------------------------------------------------

方法2不可取，用户增加的时候非常麻烦，而且access1--access4的长度很难确定。

下面我要说的是MIS系统权限管理的数据库设计及实现，当然，这些思路也可以推广开来应用，比如说在BBS中用来管理不同级别的用户权限。

权限设计通常包括数据库设计、应用程序接口(API)设计、程序实现三个部分。

这三个部分相互依存，密不可分，要实现完善的权限管理体系，必须考虑到每一个环节可行性与复杂程度甚至执行效率。

我们将权限分类，首先是针对数据存取的权限，通常有录入、浏览、修改、删除四种，其次是功能，它可以包括例如统计等所有非直接数据存取操作，另外，我们还可能对一些关键数据表某些字段的存取进行限制。除此，我想不出还有另外种类的权限类别。

完善的权限设计应该具有充分的可扩展性，也就是说，系统增加了新的其它功能不应该对整个权限管理体系带来较大的变化，要达到这个目的，首先是数据库设计合理，其次是应用程序接口规范。

我们先讨论数据库设计。通常我们使用关系数据库，这里不讨论基于Lotus产品的权限管理。

权限表及相关内容大体可以用六个表来描述，如下：
1 角色（即用户组）表：包括三个字段，ID，角色名，对该角色的描述；
2 用户表：包括三个或以上字段，ID，用户名，对该用户的描述，其它（如地址、电话等信息）；
3 角色-用户对应表：该表记录用户与角色之间的对应关系，一个用户可以隶属于多个角色，一个角色组也可拥有多个用户。包括三个字段，ID，角色ID，用户ID；
4 限制内容列表：该表记录所有需要加以权限区分限制的数据表、功能和字段等内容及其描述，包括三个字段，ID，名称，描述；
5 权限列表：该表记录所有要加以控制的权限，如录入、修改、删除、执行等，也包括三个字段，ID，名称，描述；
6 权限-角色-用户对应表：一般情况下，我们对角色/用户所拥有的权限做如下规定，角色拥有明令允许的权限，其它一律禁止，用户继承所属角色的全部权限，在此范围内的权限除明令禁止外全部允许，范围外权限除明令允许外全部禁止。该表的设计是权限管理的重点，设计的思路也很多，可以说各有千秋，不能生搬硬套说某种方法好。对此，我的看法是就个人情况，找自己觉得合适能解决问题的用。

先说第一种也是最容易理解的方法，设计五个字段：ID，限制内容ID，权限ID，角色/用户类型（布尔型字段，用来描述一条记录记录的是角色权限还是用户权限），角色/用户ID，权限类型（布尔型字段，用来描述一条记录表示允许还是禁止）

好了，有这六个表，根据表六，我们就可以知道某个角色/用户到底拥有/禁止某种权限。

或者说，这么设计已经足够了，我们完全实现了所需要的功能：可以对角色和用户分别进行权限定制，也具有相当的可扩展性，比如说增加了新功能，我们只需要添加一条或者几条记录就可以，同时应用程序接口也无须改动，具有相当的可行性。但是，在程序实现的过程中，我们发现，使用这种方法并不是十分科学，例如浏览某个用户所拥有的权限时，需要对数据库进行多次（甚至是递归）查询，极不方便。于是我们需要想其它的办法。使用过Unix系统的人们都知道，Unix文件系统将对文件的操作权限分为三种：读、写和执行，分别用1、2、4三个代码标识，对用户同时具有读写权限的文件被记录为3，即1+2。我们也可以用类似的办法来解决这个问题。初步的想法是修改权限列表，加入一个字段：标识码，例如，我们可以将录入权限标识为1，浏览权限标识为2，修改权限标识为4，删除权限标识为8，执行权限标识为16，这样，我们通过权限累加的办法就可以轻易的将原本要分为几条记录描述的权限放在一起了，例如，假定某用户ID为1，库存表对应的限制内容ID为2，同时规定角色类型为0、用户类型为1，我们就可以将该用户具有录入、浏览、修改、删除库存表的权限描述为：2,15,1,1。

确实很简单，不是吗？甚至还有更过激的办法，将限制内容列表也加上一列，定义好标识码，这样，我们甚至可以用简单的一条记录描述某个用户具有的对全部内容所具有的全部权限了。当然，这样做的前提是限制内容数量比较小，不然，呵呵，2的n次方递增起来可是数量惊人，不容易解析的。

从表面上看，上述方法足以达到实现功能、简化数据库设计及实现的复杂度这个目的，但这样做有个弊端，我们所涉及的权限列表不是相互独立而是互相依赖的，比如说修改权限，其实是包含浏览权限的，例如，我们可能只是简单的设置用户对库存表存取的权限值为录入+修改+删除（1+4+8=13),但事实上，该用户具有(1+2+4+8=15）的权限，也就是说，在这种方案中，13=15。于是当我们调用API询问某用户是否具有浏览权限时，就必须判断该用户是否具有对该数据表的修改权限，因此，如果不能在程序中固化权限之间的包含关系，就不能利用应用程序接口简单的做出判断。但这与我们的目的“充分的可扩展性”矛盾。

这个问题如何解决？我想到了另外一种设置标识码的方法，那就是利用素数。我们不妨将录入、浏览、修改、删除、执行的基本标志码定为 2,3,5,7,11，当遇到权限互相包含的时候，我们将它的标识码设定为两个（或多个）基本标志码的乘积，例如，可以将“修改”功能的标志码定为3*5 =15，然后将所有的权限相乘，就得到了我们需要的最终权限标识值。这样，我们在询问用户是否具有某项权限的时候，只需要将最终的值分解成质因子，例如，我们可以定义一个用户具有录入+修改+删除库存表的权限为 2*15*7=2*3*5*7，即表示，该用户具有了对库存表录入+浏览+修改+删除权限。

当然，对权限列表我们使用上述方法的前提是权限列表记录条数不会太多并且关系不是十分复杂，否则，光是解析权限代码就要机器忽悠半宿：）

我希望以上的分析是正确且有效的（事实上，我也用这些的方法在不止一套系统中实现），但无论如何，我觉得如此实现权限管理，只是考虑了数据库设计和应用程序接口两部分内容，对于实现，还是显得很费劲。因此，我恳请有过类似设计、实现经验的同志们提出建设性的意见和修改建议。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1536110

玉澍淋枫 2007-08-03 20:43 发表评论