Comments (10)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 rcasey commented Permalink

Chris,<div>&nbsp;</div> This looks pretty cool! How would be the best way to implement a security mechanism to control access to the various modules? I was thinking that the primary application (Portal or AppSwitcher) could ask the user to enter their userid/password and validate it. Once validated, it could build the portal list or application switcher menu based on the options that were valid for the user. <div>&nbsp;</div> From your description, each module is a separate application level URL that can be developed, tested, etc by itself and then made available to the portal/switcher framework. How would I guard against someone specifying the application level URL directly and bypassing the security checking in the controlling application? I'm thinking I could use the InfoBus and have each module wait on a published message from the controlling application before starting. Would that be secure enough?<div>&nbsp;</div> Thanks for all your good work. This stuff is fun!<div>&nbsp;</div> Richard

2 ChrisLaffra commented Permalink

In cases like you describe, you would have to secure the individual portlets also. That means they have to authenticate themselves or ask the parent for a session cookie. In my previous blog entry (describing a Jazz.net mashup), I show how to login and keep a session cookie around. What the portlet would do when it starts up is register for cookie events on the InfoBus. Then it would signal a request for a cookie on the InfoBus. If it is used in a Portal, the portal will respond with the authenticated cookie. If it does not, the portlet won't be able to call any services as it does not have a cookie.<div>&nbsp;</div> Would that work?<div>&nbsp;</div> Chris

3 NikolaGereci commented Permalink

Chris, <div>&nbsp;</div> this looks very interesting, particularly the iframe "performance tuning" method, and the propagation of authorization credentials via cookies. <br /> But, I'm also interested in the WS Portal side of the story. I've been working on some issues regarding that for a while, and one of the questions that remain open is how to handle authorization in RUI "portlets" inside a WS Portal portlet. Specifficaly, I need a way to get the user credentials from the portal session into RUI, so I can handle authorization from there. Is something like that even possible? I haven't got the slightest clue how it could be, so I'm interested in your opinion on the subject. <br /> I'm also wondering, when (and if) will the deployment of RUI applications to WS Portal be supported?<div>&nbsp;</div> Anyway, I'm looking forward to a post concerning RUI inside WS Portal! <img class="jive-emoticon" border="0" src="http://www-949.ibm.com/software/rational/cafe/images/emoticons/happy.gif" alt=":)" /><div>&nbsp;</div> Nikola

4 rcasey commented Permalink

I did some playing around with the InfoBus. I took AppSwitcher and added a box containing userid, password, and a login button. The initialUI was then set to that loginBox. The login button's onClick function validates the userid/password. If a valid userid/password is entered, the Combo list is populated with the applications appropriate for the user, and the initialUI is then changed to the original Box containing the Combo list and the Frame.<div>&nbsp;</div> In each application, the initialUI was left as the "Welcome to application x" message. The actual UI was defined in a separate container. In the doHandler function, the initialUI is set to that container, making the actual UI visible.<div>&nbsp;</div> I also added an appExit function to the applications (tied to a button). That function publishes a message that is subscribed to by AppSwitcher. AppSwitcher sets the frame.src back to "test.html" as was originally displayed before any application was selected.<div>&nbsp;</div> Also added a "Signoff" application to the Combo list that sets AppSwitcher's UI back to the loginBox.<div>&nbsp;</div> Fun stuff!<div>&nbsp;</div> Richard

5 ChrisLaffra commented Permalink

That sounds really cool, Richard. <div>&nbsp;</div> When you actaully deploy each handler in EGL CE and load the main handler from Tomcat, each incremental load should be around 50K each.<div>&nbsp;</div> Chris

6 ChrisLaffra commented Permalink

BTW. mod_rewrite only works on Apache. If you are using Tomcat standalone, you can use something like UrlRewriteFilter.

 
I installed it in my workspace on my project. I placed the library in the WEB-INF/lib folder, right next to fda7.jar. Then I placed urlrewrite.xml in the WEB-INF folder, and added the following rule:
 

<rule>     <from>/com/ibm/egl/demos/application([A-Z]+).html</from>     <to type="redirect">/PortalWebProject/application$1-en_US.html</to></rule>
 
Then I restarted Tomcat, and AppSwitcher worked fine.
 
Chris

7 rcasey commented Permalink

Cool!<div>&nbsp;</div> I'll give UrlRewriteFilter a try this afternoon. Does Websphere have something similar?<div>&nbsp;</div> By the way, I like your idea of using a test handler better. That way, I don't have to remember to take out the 'InfoBus.publish("app.do.A", "test");' statement before deploying the application!<div>&nbsp;</div> I'm going to experiment with using a tab folder to display the available applications. I'll let you know how it goes!<div>&nbsp;</div> Thanks for your help.<div>&nbsp;</div> Richard

8 rcasey commented Permalink

My experiments with AppSwitcher work fine running from the Preview tab of the RichUI editor. However, when I try to deploy it to a Web project (with Tomcat), I have some file naming issues. All of the HTML files (AppSwitcher, applicationA, applicationB, etc) get created with "-en_US" at the end of the name. I know that has to do with supporting multiple languages, and I can run the application by specifying AppSwitcher-en_US.html in the browser. Is there a setting somewhere that would allow me to just specify AppSwitcher.html instead?<div>&nbsp;</div> Also, applicationA-en_US.html and the other application modules are stored in the root folder of the Web project. However, the showApplication function in AppSwitcher is expecting to find those HTML files in the com/ibm/egl/demos folder based on the package name of the RuiHandlers. In addition, the showApplication function expects the modules to be named xxxxx.html instead of the xxxx-en_US.html that gets generated.<div>&nbsp;</div> Any suggestions?<div>&nbsp;</div> By the way, it is easy enough to develop/test the individual application modules. All you have to do is add<div>&nbsp;</div> InfoBus.publish("app.do.A", "test");<div>&nbsp;</div> to the end of the start() function and the application thinks it has received the go-ahead from AppSwitcher! Once you get it working the way you like, just remove the Infobus.publish statement. As I get into more with user authentication, that process may change.<div>&nbsp;</div> Richard

9 ChrisLaffra commented Permalink

Hi Richard,<div>&nbsp;</div> Apache has a mod called "Rewrite". You can enable it as follows. Create a file called ".htaccess" and place it in the com/ibm/egl/demos folder. In that file say something like this:<div>&nbsp;</div> <pre class="jive-pre"> <code class="jive-code jive-plain"> RewriteEngine OnRewriteRule applicationA.html ../../../applicationA-en_US.html</code> </pre> <div>&nbsp;</div> That should tell Apache (the web server inside Tomcat) to rewrite the URL to pick a different file.<div>&nbsp;</div> More information on rewrite engines can be found here: <a class="jive-link-external" href="http://en.wikipedia.org/wiki/Rewrite_engine">http://en.wikipedia.org/wiki/Rewrite_engine</a>.<div>&nbsp;</div> The Apache rewrite engine is called mod_rewrite: <a class="jive-link-external" href="http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html">http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html</a><div>&nbsp;</div> I like the tip about testing. You can also make a separate test handler that loads applicationA and tells it to start. You could then include all your subapplications and have a combox to select them, for instance. If you put that in a separate test project, you would nicely manage your code and not accidentally deploy all your test code either.<div>&nbsp;</div> Chris

10 TheresaRamsey commented Permalink

Other portal examples are provided in RBD v8 in the Dojo sample project (see EGLSource&gt;utils.portal&gt;PortalSample) and a mortgage portal tutorial available from Help&gt;Help contents&gt;Tutorials&gt;Do and Learn. Enjoy!