Portal精华帖整理(四):Portal开发

来源:百度文库 编辑:神马文学网 时间:2024/03/28 20:15:03
Portal开发 、WebLogic Portal的portlet开发步骤
Q: 能不能用portal administration来管理已经在workshop中创建好的portal和在这个创建好的portal上的内容,在无需创建新的portal的条件。也就是说原来portal不变,但是可以管理原来portal 中的部分内容。能不能实现??行还是不行???为什么??
A: weblogic portal完整的开发过程有两个步骤:一在workshop中进行portlet和相关资源的开发,二、在admin tools中以此为基础进行组装
、在workshop 中怎样让portlet使用新建的*.jpf
直接将你新建的JPF拖放到你的portal页面上,就直接生成了jpf的portlet了
、如何在weblogic portal中配置calender portlet
使用weblogic portal中的例子,需要完成以下步骤:
1。按照帮助系统中关于sample 的使用方法的提示将相应的文件import进自己的工程中。
2。在你安装weblogic的时候有目录\bea\weblogic81\portal\db\pointbase\44下有一个文件sample_portal_create_tables.sql在pointbase里面执行它。
3。需要将web.xml中的相应配置拷入到你的web.xml中如果你按照上面的步骤执行,就没有问题了。
、如何把header.jsp和footer.jsp拖到相应的位置
在portal8.1可head和footed位置是由shell文件控制的,你可以为一个desktop选择一个shell文件,比如samportal中缺省的为header
FooterVisitor.shell


、在Portal 7.0中怎样在usermgt.jar中指向一个新生成EntityPropertyManager
修改ejb-jar.xml and weblogic-ejb-jar.xml.
在ejb-jar.xml中添加;
ejb/LdapPropertyManager Session com.bea.p13n.property.EntityPropertyManagerHome com.bea.p13n.property.EntityPropertyManager
在weblogic-ejb-jar.xml也作对应的修改就可以了
在http://dev2dev.bea.com/codelibrary/code/unified_up.jsp有一wlp7.0的例子你可以看看
、请问workshop开发的portlet是否能移植到websphere portal上?
bea portal支持jsr-168,如果用jsr-168写portal移植应该没问题,但是很多是用java page flow,估计要等到标准化以后才能移植
、Portal与Portlet中的Session与Request
Q: 在编写Portlet的时候,如果用session.setAttribute(),这个变量可以在各个Portlet中共享,有没有办法能够让session局限与一个portlet之内,也就是在一个portlet的页面流中,我如何传递自己的参数,别的portlet又看不到。request也是同样
A: session本来就是用来在一段回话中共享数据得,你这样的要求似乎太为难大家伙了。实在不行就在session中设定标志位区别吧;request的话,好像本来就是可以的吧,看看这个:
<%@page import="com.bea.wlw.netui.pageflow.scoping.ScopedServletUtils"%>
<%
HttpServletRequest outerRequest = ScopedServletUtils.getOuterRequest( request );
%>
、关于SSO和Weblogic Portal
本文讨论的只是基于Web的其他应用系统与的Weblogic Portal的SSO。
一、应用系统的验证
提到SSO,就不能不提到其他基于Web应用系统的身份验证。我们透过现象看本质,看看基于Web的身份验证的实质是什么。
无论后端是什么系统,例如Lotus Domino,BO等等,其实,基于Web的身份验证的实质无外乎就是有一个表单(FORM),表单里面让用户输入用户名称和密码,然后提交给验证的页面(Form中的action指定的),通过身份验证后,通过Session来储存用户的一些信息,然后每次访问页面时,从session里面读这些信息,如果存在,则进入登录后的界面,否则,就认为没有登录。
而Session的机制呢,我想大多数人都应该知道,它是与Domain还有Path相关的,是存储在服务器端的,服务器如何知道当前浏览器或者客户端对应的是哪个Session呢,主要是通过Cookie中的sessionid来对应的,session是有失效时间的,服务器一般都可以设置,也可以通过程序来设置。
Cookie的生命周期可以是一关闭浏览器就灭亡,也可以设置存在的时间,如果设置了存在的时间,就会以文件的方式存在于客户端,当客户端再访问服务器时,可以通过Domain对应关系从Cookie中读取相应的信息,一般我们在其他网站时,登录时如果设置了自动登录或者记录多长时间,就是使用的Cookie,一般会在Cookie中存储登录的用户名称和密码的密文,访问网站时,它如果读取到这些信息,就会使用这些信息自动登录了。
所以可以看出,无论对于什么Web应用程序,如果该浏览器曾经登录过,服务器端生成了session,客户端Cookie中记录了SessionID,该浏览器没有关闭,那么,即便该浏览器访问其他的站点后,再回到该应用系统,如果Session没有失效,那么应用程序还会认为你是登录的。
而对于身份验证的页面,一般是不做判断,判断你的用户名称和密码是通过POST,还是URL中参数方式提交的。除此以外,有的应用程序会从URL中参数判断你是否登录,这种方式由于不安全目前已经应用不多,早些年很多门户网站的邮件就是这种机制,用户登录时会根据一些特性生成一个很长的字符串,通过该字符串来判断是否登录了,所以当时会发生,如果在另外一台机器上拷贝了该URL,也会进入邮箱的情况。
还有一种特殊情况,这是HTTP协议支持的,就是BASIC认证方式,它会在用户初次访问时弹出对话框,用户输入用户名和密码后,浏览器会记住,然后每次HTTP请求时,在Header里面将用户名称和密码的BASE64位形式传给服务器,服务器就会知道该用户的身份了,之所以在这里单独提出这种方式,是因为下文介绍的自己编写的SSO实现很难对付这种验证方式,所以,如果后端系统(例如Lotus Domino)同时也支持Form身份验证,就需要改过来,如果不支持或者不能改过来,将是很棘手的一件事情。
二、SSO的实现-第三方产品
本节讨论的是基于第三方产品实现SSO。
目前,有很多产品支持SSO,使用Weblogic Portal,我们也主张用户使用这些产品,因为他们能够很好的通过配置,甚至是自学习的方式实现SSO,开发者需要完成的工作很少。
这些产品,一般实现的方式有两类:第一类是通过Agent的方式,即在后端每个Web应用系统,或者其他系统都安装一个Agent,由Agent来接管该系统的身份验证和访问控制,同时,需要有一台策略服务器,里面会放置Weblogic Portal的用户信息,以及这些用户与其他系统的用户对应信息,当然,Weblogic Portal也可以继续保留自己的用户,该策略服务器只是存放了用户的对应关系。这类产品对于不同的系统,Agent不同,这些Agent能够通过配置,轻松的接管了后面的系统的身份验证和访问控制,所以,举例来说,如果Portal中用户A对应系统1中的用户B,那么策略服务器中有此配置后,当从Portal访问系统1时,系统1的agent能够辨别portal用户A,就可以知道该系统对应的用户是B,让系统认为当前用户就是B,然后使用B的身份来访问和操作系统1。这类产品的使用方式还可以是,通过一个统一的LDAP,存放企业内部的用户信息,然后通过策略服务器,控制了后端所有系统的URL访问权限,这样也实现了单点登录。
这种方式的优点是:策略服务器不会存储其他系统的密码,密码还是保存在各个系统中,同时,各个系统的访问都由Agent控制,用户必须经过Portal作为入口,同时,可以通过策略服务器灵活的配置访问控制。缺点在于:需要在各个系统安装Agent;对于没有Agent的系统,需要通过安装Web Agent,然后进行一定的编码实现;Portal作为单一入口,一旦当机,无法访问后台系统。缺点解决:Weblogic Portal可以通过构建集群实现负载均衡和容错,避免单点故障。
第二类是通过Proxy的方式,即具有一个Proxy Server,由它来接管对于后端系统的访问,提交请求和读取数据,然后再返回给Portal,同时也有一个LDAP服务器或者策略服务器,该服务器可以存放用户信息以及用户的对应关系。Proxy Server的作用是接收Portal的请求,提交给后端系统,然后将返回的数据再写给Portal,Proxy Server会通过存储的用户对应关系和用户名和密码,自动完成后端系统的登录,然后就象一个浏览器一样,提取数据,返回数据给后端系统。
该方法的优点是:后端系统不用做任何改动。即便是没有Portal,其他系统还可以照常使用。缺点是:需要在策略服务器中存储用户名称和密码,密码会多处存放,同步困难;用户可以绕开Portal,直接访问后端系统。Proxy Server可能是单点故障。
缺点解决:目前有密码同步产品;Proxy Server也大多支持集群。
由以上两种方式可以看出,哪种方式的编程量都不是很大,大多可以通过配置来实现,而且功能也很强大,例如第一节说的BASIC登录方式,这些产品都支持。而Weblogic Portal通过其支持多身份验证提供者,以及良好的开发框架等的特点,能够完全支持这两种方式。如果客户银子大把,优先应该考虑使用第三方产品。
可是如果客户预算不大,后端系统又不多,有什么解决方法呢?答案当然是有,但不是万能的。
三、Weblogic Portal的用户
提到SSO,就不能不说说Weblogic Portal的用户信息。作为一个统一,简单,可扩展的企业级应用平台Weblogic Platform中的一部分,Weblogic Portal被容纳在Weblogic Platform统一的安全框架中,它使用的用户和组,就是weblogic Server的用户和组,但是与Weblogic Server不同的是,它的角色是Portal特有的,与Server是完全不同意义的,需要注意不要混淆了。
Weblogic Server安装后缺省时是使用自带的内嵌的LDAP来进行用户,组和角色的管理的,在身份验证提供者中,有一个DefaultAuthenticator,就是对这部分用户,组和角色来进行管理的提供者。
Weblogic Portal8.1.3可以支持多个用户身份验证提供者,配置是在Server的控制台中进行,在Weblogic Portal的管理工具中,在管理用户和组的时候,可以在多个安全提供者之间切换,进行管理。
在Weblogic Server控制台中,点击Security > Realms > myrealm> Authentication Providers,可以看到DefaultAuthenticator,同时,还能看到可以新建很多种类的身份验证提供者,包括:
Configure a new Default Identity Asserter...
Configure a new MedRec Sample Authenticator...
Configure a new Open LDAPAuthenticator...
Configure a new Novell Authenticator...
Configure a new iPlanet Authenticator...
Configure a new RDBMSAuthenticator...
Configure a new Default Authenticator...
Configure a new Realm Adapter Authenticator...
Configure a new WSRPIdentity Asserter...
Configure a new LDAPX509Identity Asserter...
Configure a new Active Directory Authenticator...
可以看到,Weblogic Server可以配置使用多种主流的LDAP服务器来存储用户和组,同时,也支持数据库和AD。通过设置,可以指定使用哪个身份验证提供者作为缺省的。也可以设置多个Provider直接的验证关系如何。
本文中不会对如何配置进行说明,感兴趣的朋友,可以查阅Weblogic Server关于Security的相关的帮助。使用数据库作为验证,可以参见笔者另外一个帖子:
http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=101&threadID=18563
由此可以看到,如果客户需要的SSO指的就仅仅是,能够使用他们企业内部已有的LDAP或者AD用户,进行Weblogic Portal登录和身份验证的话,那么,只要配置多个身份验证提供者就可以了,就可以使用那些已经存在的用户。但是,如果客户需要的SSO并不局限于此,还需要在Portal上登录以后,再访问其他一些基于Web的应用系统时,就不需要重复输入用户名和密码和重复登录了,那么,仅仅通过配置是无法实现的。即便那些系统和Portal理想状态下都使用相同的LDAP或者AD用户,由于每个系统验证用户是否登录以后的机制不同,还是需要进行定制开发的。
四、自己开发实现SSO
Portal作为统一的入口,将其他基于Web的应用集成到Portal中,方式可以是多种多样的,最简单的是Portal上提供链接,直接打开其他系统的界面,进行操作;再复杂一点的就是通过Frame或者Iframe的方法,将其他系统的界面嵌入到Portal中,但实质还是使用其他系统的界面,Portal只是从大范围(例如包含了其他应用的Portlet)来控制用户的访问权限,这两种主要解决的就是能够绕过其他系统的登录,然后让其他系统能够识别当前用户的对应身份,至于其他系统内部自己的个性化,权限等,还是由各个系统自己控制的。Weblogic Portal的Web应用集成还有其他方式,例如通过web clipping的方式,生成Portlet;或者通过HttpControl,取得Http回应的内容,组成Portlet;或者完全使用后端系统的API,重构Web内容,例如通过Lotus Domino的API,访问Lotus Domino的数据库,直接读取视图或者文档的信息等。但这几种方式都已经不再使用原来的系统界面,所以,涉及的内容在本文SSO讨论中没有包括。本节讨论的就是开始时提到的两种方式如何解决。
经过前面身份验证,Session,Cookie等方面的说明,我想,很多人大概已经知道如何自己编写程序来实现简单的SSO了,在论坛上笔者也看到有的朋友这样做了,其实说来很简单:
1、在数据库或者LDAP中存储Portal用户和其他系统用户的对应关系,包括其他系统用户名称和密码,根据不同系统的验证特点,有的可能还要存储密码的密文形式。
2、在Portal登录时,或者在切换到其他系统时,通过Iframe将用户名称和密码通过URL传递过去,进行后端的登录。
以后端系统为Dev2dev.bea.com.cn为例,可以通过查看登录页面的源文件,知道Form的action是login.jspa,那么,当Portal用户验证正确以后,可以在页面中加入

Dev2dev.bea.com.cn
将上面的YOURUSERNAME和YOURPASSWORD替换为Portal用户对应的用户名称和密码,打开页面后,点击该链接,可以看到,当前用户已经是登录以后的身份。
当然,可以去掉下面的连接,直接设置iframe的width和height为足够大,就可以将dev2dev.bea.com包括在其中。
以上应该是一个JSP页面(因为你要动态的设置名称和密码),通过该JSP页面产生Portlet,就可以嵌入到Portal中,正如我们前面所说,你不能通过Portal控制你登录以后的样式,个性化等属性,但是你可以通过控制用户访问该Portlet的权限,从而实现Portal内高层次的个性化和显示控制。(其实,通过JavaScript,也完全可以改变Iframe中的内容和样式,这个超出本文的主题,略过)
以上就是一个SSO的自己编程的简单实现,但是,这种方法具有很多需要注意的地方和局限性:
1、对方的登录表单,可能不仅仅是传递了用户名称和密码,可能还有其他的参数,需要多次尝试,如果能够看到对方验证的代码最好。
2、对方有可能进行了Form是POST还是GET提交的判断(例如,验证页面是Servlet),如果一定需要使POST,那么可以使iframe中src是一个相同的form表单,action指向对方的验证页面,然后,通过Javascript,进行隐式提交;更有甚者,有的验证页面还判断了是否是本服务器提交的请求,那么,就要嵌入对方的登录表单,然后在iframe所在的页面内,通过Javascript使iframe内的页面提交,完成登录。
3、有的系统为了安全,密码传输前已经在客户端通过Javascript进行了加密,注意检查。
4、有的系统很特别,一定要在浏览器的_top窗口中进行验证,或者验证以后在_top中打开后继的页面,对于这种系统,请修改对方的程序,否则很难解决。笔者曾经就遇见过此类案例,尝试多次无果,幸好后来发现对方系统能够设置后继的页面,将后继的页面设置为Portal,再转回Portal才可以。
5、Portal用户会和多个系统的用户有对应关系,需要设计一个好的数据结构,如果后端系统为多个,不一定非要在Portal登录验证后隐式登录所有的系统,可以在需要显示哪个系统时,再隐式登录。
五、小结
以上就是个人关于SSO和Weblogic Portal的实现的一些看法,经验和心得体会,希望能对相关朋友有所帮助。值得一提的是,Weblogic Portal通过Portlet源的多样性和灵活性,为自己开发编程实现SSO,提供了强有力的支持。
、Weblogic Portal8.1中实现分页显示
我们现在至少有三种以上的方案可以解决:
1、在JSP页面上用netui:anchor 来实现页面到action的跳转,在action中进行处理之后,在回到本页面。
2、如果将代码写到JSP中,我们可以通过取得当前的page的com.bea.portlet.PostbackURL 来进行定位。
3、参考workshop中由Control自动创建的JPF中的实现方式。
第一种方案思路如下:
页面流开始,在Action中取出所有要显示的数据,分页,并显示第一页。当在jsp中点击第二页时,页面流回到Action,在Action中首先得到页数,然后计算第二页应该load的数据,并load这些数据,然后跳向原先的jsp,但是在这个jsp中绑定的数据已经是第二页的数据了。
代码详见:testpageflow
第二种方案思路:
<% PostbackURL url = PostbackURL.createPostbackURL(request, response); int i = 1; while(i<10) { url.removeParameter("page"); url.addParameter("page",new Integer(i).toString()); %> >第<%=i%>页 <% i++; }%>
当jsp,自己调用自己的时候,url地址不要写文件名,而是利用portlet的类,根据当前环境(request & response)先创建一个url,然后跳转到这个url,置于不同页需要不同的参数(page)值,则在代码中使用url. addParameter方法,注意在add之前最好先清一下Parameter,否则可能加得很长。
代码详见:pageTest.jsp
Java page flow 是基于strus的,建议将逻辑代码都写到action中,使用workshop提供的NetUI,一般的功能都可以实现。在jsp中尽量不写代码,尽量不要jsp之间直接跳转。
以上两个例子您可以直接拖入您的工程,可以直接运行。形成portlet放入portal后也测试过了。
第三种方案思路:参考workshop中由Control自动创建的JPF中的实现方式。
附件:
http://dev2dev.bea.com.cn/bbs/servlet/D2DServlet/download/101-12443-65787-523/说明及实例.rar