IBM® WebSphere® Portal delivers a single point of access for applications and information within a customizable and extendable framework. It integrates an application deployment platform with team collaboration, content publishing, workflow, and enterprise application access services. For more information, see WebSphere Portal zone.
Question: How can I do redirection to custom pages in Custom Login command?
Answer: The idea behind WebSphere Portal is that you can customize and personalize pages for a user or group of users. This allows the same set of pages to perform different functions for different users and reduces the overall development and administration effort around the portal. If groups of users are radically different, or you need the portal to serve very different purposes, then virtual portals may be the answer. This allows you to separate the portal into different sets of pages that each appears to be a standalone portal to the end user. See Taking a step toward virtual portals in WebSphere Portal V5.
For a simple redirect upon login, you can use the configuration properties found in the
# Login redirect parameters # Default: true, false, <none> redirect.login = true redirect.login.ssl = false redirect.login.url = http://portal.houston.ibm.com/mypage/
These settings allow you to map a single page to all users (other then the default home page of the portal).
You might think that by extending the
com.ibm.wps.engine.commands.LoginUser class, you could force a redirect during the postLogin() method. Unfortunately, the postLogin() method is called before the portal sets up the redirect, either by using the redirect.login.url that you set in the properties file above or by generating a new dynamic URL.
Another option may be to use an external authentication reverse proxy to provide the login functionality for the portal. Using this approach, the proxy can forward the user to different pages depending upon some rules within the proxy itself. This would have to be setup in the proxy and maybe custom coded at that level.
Finally, you can recode the LoginUser class itself to add the correct login and redirects that are desired. This is not recommended and would require IBM Software Services (at the very least) to assist. The login process itself can take a long time and is the most evident to the user. Care must be taken when putting a set of rules in place to determine where a user should go. It is best to understand the requirements of a particular situation, so that a portal expert can try and bridge the gap with existing portal functionality, rather then re-coding the internal workings of the product. Anytime you take that route, you open yourself up to issues with support, performance, and who knows what else.
Question: Isn't there any way for administrator to update other users' static credentials (user ID/password) stored in shared or administrative portal credential vault?
Answer: When setting credentials for a user within a shared vault slot, you pass the username, password, and slotID of the slot you want the values stored in.
vaultService.setCredentialSecretUserPassword(slotId, userID, password.toCharArray(), portletRequest);
In addition, you pass in the portletRequest object, which the underlying service uses to extract the distinguished name of the current user to store these specific credentials. The approach for the vault is purposely designed in this manner so that the credential vault maintains its secrets from rogue programmers who could write and install a portlet that captured everyone's password. In highly secure environments, you would not want to use passive credentials to allow anyone to access any credential information.
Given this design, there are not many options to do what you are asking. Looking at different ways to approach this problem, however, there are some scenarios that may be viable. Accessing the underlying data store may be one option. In a simple "shared slot" scenario, the credential data is stored in a single table called VAULT_DATA.
Figure 1. Vault data
One option is to write a portlet that allows the user to edit the password data directly within this table. As you can see, the passwords are Base64 encoded. However, an implementation of this encryption class is available within the portal at
com.ibm.wps.security.Base64Coder. IBM never recommends editing the database directly with WebSphere Portal, as the database schema is likely to change with new releases.
You could try to adopt the existing code to handle your request, by extending the existing classes to pass in a DN directly, rather then extracting it from the portletRequest. As I mentioned above, anytime you go mucking around in the portal code, you open yourself up to support and performance issues. In addition, you may have to rewrite your implementation with each new release of WebSphere Portal. Again, you will want to engage IBM Software Services with this approach.
Another approach is to create your own vault adapter implementation. There are some vault adapters already available, for example, one for use with IBM Tivoli Access Manager.
Question: In Meet the Experts: Marshall Lamb on WebSphere Portal Programming, Marshall answered that a portlet and a servlet can be packaged in one WAR file. Is it still possible?
In another article, Developing and Invoking a Servlet from a Portlet using WebSphere Studio, I saw an example the "associated" servlet can process requests from its peer portlet via javax.servlet.RequestDispatcher, but I want to open a separate browser window rendered by the "associated" servlet directly.
Answer: Yes, you can do what you ask. We frequently see this when users want to display content in a separate window. In Figure 2, the list of content is displayed within a portlet. However, when the user clicks on a link, the specific piece of content is displayed in a separate window via a servlet.
Figure 2. Servlet popup
A servlet is within a portlet project and added to the web.xml. The following code snippet shows a sample web.xml with both a portlet and a servlet registered.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app id="WebApp"> <display-name>TestPortlet</display-name> <servlet id="com.ibm.wps.portlet.TestPortlet"> <servlet-name>com.ibm.wps.portlet.TestPortlet</servlet-name> <display-name>TestPortlet</display-name> <servlet-class>com.ibm.wps.portlet.TestPortlet</servlet-class> </servlet> <servlet id="Servlet_com.ibm.wps.servlet.TestServlet"> <servlet-name>com.ibm.wps.servlet.TestServlet</servlet-name> <display-name>TestServlet</display-name> <servlet-class>com.ibm.wps.servlet.TestServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>com.ibm.wps.portlet.TestPortlet</servlet-name> <url-pattern>/com.ibm.wps.portlet.TestPortlet/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>com.ibm.wps.servlet.TestServlet</servlet-name> <url-pattern>/TestServlet</url-pattern> </servlet-mapping> </web-app>
However, the portlet.xml file only contains a reference to the portlet, because the servlet could not be used by the portal. Deployment of the war should be the same as any portlet war file.
The next question is: how do I use the servlet? Because of the way that WebSphere Portal deploys war files with unique IDs, the servlet target gets lost. For example, to access the above servlet, I might need to use the URL
That's not very user friendly, I'll admit.
The simplest answer is to use a separate war file that contains your servlet and deploy that separately using WebSphere Application Server. This allows better control of the target URL that you are addressing from the portal. If you do deploy the servlet within a portlet, you can manually look at the installedApps directory and see the unique name of the directory. Another option is if you are calling the servlet from a portlet within the same war, then you can use the portal to give you the URL by doing something like:
<a href="<%=response.encodeURL("/TestServlet")%>" target="_blank">Launch Test Servlet</a>
This code in a portlet JSP launches the servlet described above in a new window.
Question: How can I use JDK 1.4 with WSP?
Answer: WebSphere Application Server 5.1 allows you to use the IBM Developer Kit, Java Technology Edition, Version 1.4.1. WebSphere Portal version 220.127.116.11 is now available, and it runs on WebSphere Business Integration Server Foundation 5.1, which is based on WebSphere Application Server 5.1. (WebSphere Business Integration Server Foundation is the new name for WebSphere Application Server Enterprise.)
Question: I am looking for simple Struts portlets messaging in different portlet applications and both are on the same page.
Answer: I do not often recommend Struts portlets because of the added layer of complexity, and problems using the WebSphere Portal API. I know that it is widely used, but most portlets are pretty simple. For you Struts zealots, I agree that there are compelling reasons to use Struts, so we'll leave it at that.
As far as portlet messaging between different portlet applications, we can look to cooperative portlets or Click-to-Action. Cooperative portlets subscribe to a model for declaring, publishing, and sharing information with each other using the WebSphere Portal property broker. Varad Ramamoorthy has written an article about Click-to-Action (C2A), including using it within a Struts portlet, called Passing complex data types between cooperative portlets.
Question: I am working on LDAP (IBM Directory server) configuration with portals. We have properly installed portal server, migrated into a DB2® database, and configured with LDAP (IDS) server. We are able to successfully create users and associate roles to the users in IDS and DB2, but we unable to login portal server and WebSphere Application Server console. If we give the wrong users, it shows the message: "Invalid userid and password". If we give the correct users, we are unable to login, it doesn't show any message.
Answer: A generic question like this without specific knowledge of the environment and configuration is very difficult to answer. I'm going to provide a list of general issues and debugging tips that people may use when configuring WebSphere Portal with an LDAP.
- The first place to look is in the WebSphere Portal Information Center. (I really like the Information Center, and often clients laugh at me because that's the first place I look when I have a question about an IBM product.)
- Next, take a look in the logs and turn on some tracing. Tracing is well documented (you guessed it) in the Information Center, along with what tracing commands should be entered to see what is happening during the logon process.
- Often it is a problem with LDAP permissions, with the portal not having permission to authenticate the user properly. You can test this by doing an LDAP search directly from the command line to test. The command should look like the following:
ldapsearch -b "dc=yourco,dc=com" -h <directory hostname> -D "uid=wpsbind, cn=users,dc=yourco,dc=com" -w "wpsbind" "(&(uid=wpsadmin)(objectclass=inetOrgPerson))"
Use the same username/password that the portal is using. If this shows a problem, then you can fix this by modifying permissions in the LDAP server itself.
- Finally, you can make sure that the migration to LDAP was done correctly. Make sure that you ran all the following commands correctly as documented in the Information Center:
WPSconfig.bat validate-ldap WPSconfig.bat secure-portal-ldap WPSconfig.bat enable-security-ldap
If you are getting a message about entering a valid userid and password, and receiving the logon page again, with no error message, it may be due to a problem with the SSODomainName property in the wpconfig.properties file. With WebSphere Portal, always use the fully-qualified host name, for example, always use "yourdept.yourco.com", never use just "yourdept". Also, check the DNS servers to make sure the fully-qualified host name is properly registered.
Question: Is there a war file or an easy way to grab all the files necessary to compile PeopleFinder in order to make modifications within WebSphere Studio?
Answer: Sorry, I'm not aware of it. I agree that it is troublesome to track down all the jar files that a project (any project) is dependent upon. For team development environments, I would set up a separate project that contains all the dependent files. This allows everyone to reference the same set of dependencies in a relative manner, including the build process.
That still doesn't help you find the jar files in the first place. There is a plug-in for WebSphere Studio called "Jar Class Finder" that can save you from opening up jar after jar to find the right one. It is available on AphaWorks. It is easy to use and not as slow as the manual approach.
Question: I started developing my portlets using state pattern. Now portlets support JSF and Struts. My question is should I move to the Struts framework, or I should move to JSF? What can I do for portlets developed using state patterns?
Answer: In general, unless there is a compelling need, I do not think you need to migrate all your portlets. If they work fine, then leave them alone. Why waste time, and money, to migrate them if it is not necessary? I do not use the state pattern myself because I think it generates too many classes. But, given the choice, I would prefer the state pattern over either of the other two options you mention because it integrates more easily with the portal API itself, and allows you to better take advantage of all the functions that are available to you as a portlet developer.
That being said, I think your long-term strategy would be to move to JSF, and all of your new development should slowly move in that direction. IBM is spending a lot of energy developing the tools to make this technology work seamlessly with WebSphere Portal, and you are in a good position to take advantage of this activity. Take a look at the following JSF articles by Roland Barcia, JSF vs Struts and Developing JavaServer Faces portlets using WebSphere Studio and the IBM Portal Toolkit.
Question: How to configure SSL on WebSphere Portal only for selected pages or possiblly selected portlet applications? The Information Center talks about setting up SSL for Login. How to setup it for only required pages after login, with the rest of the pages as non-secured?
Answer: The portal itself is pretty non-selective about SSL vs. non-SSL. You can specifically setup portal to use SSL during login by modifying the ConfigServices.properties file settings. Look at the login question above for the location and settings within this file.
Other than that, you could possibly redirect the user to HTTPS using a proxy or IBM HTTP Server mod_rewite rules. It is difficult to define each URL independently within the portal to HTTP or HTTPS. Within a portlet application, you can use HTTPS within the links to redirect specific applications through SSL, but it will do so for the entire page, and continue until you redirect the user back to non-SSL mode.
Question: If I want the user to only move the portlet and not add any portlet to the container, how can I do that?
Answer: Editing page layout can be a bit frustrating to understand at first. What you are talking about is locking the container contents within a page layout. In Figure 3, I have locked the container for the first column of the page. You can see that the delete boxes are all grayed out and if you go to the Content page, you do not see an Add Portlet button under this column.
Figure 3. Locking container contents
When you lock the contents of a container, you restrict the ability to add, remove, or move portlets within a container, and also the ability to add, remove, or modify sub container positions and widths. The permissions are not available at a more granular level where you can restrict the add/remove permission, yet allow the ability to move. WebSphere Portal V5.1 which is to be announced soon, may add some additional functionality to this section.
Question: We have a SSL secured Web application running on WebSphere Application Server 5.1. We will use WebSphere Portal for our next application. However, we want to link the existing Web application in the portal without any code change, so that when a portal authenticated/authorized user clicks on the link, the application will open in a new browser window, without asking the user to log in again. The Web app and portal server use the same LDAP server. My questions related to this scenario are as follows:
- How do I make it work without using TAM? Is it possible? All the online materials I found talked about single sign-on with TAM.
- When will WebSphere Portal support WAS v5.1?
- WAS v6 is out on the market. When will there be a new portal that runs on it?
Answer: Web users can authenticate once to a WebSphere Application Server and then access any other WebSphere Application Server in the same Domain Name System (DNS) domain that are enabled for SSO without logging on again. This authentication is accomplished by configuring the WebSphere Application Servers to share authentication information. Make sure all the servers are within the same domain, for example, the first server should be part of server1.mycompany.com and the other would be server1.mycompany.com. All servers have to use the same registry, either an LDAP or a custom user registry. For more informartion on this process, see IBM WebSphere V5 Security WebSphere Handbook Series.
WebSphere Portal V18.104.22.168 can run on WebSphere Application Server 5.1. See the earlier question about using JDK 1.4 with WebSphere Portal.
I cannot speak about the availability of a WebSphere Portal version running on WebSphere Application Server v6. My best guess is to look for it sometime next year.
Question: We cannot reuse our portlet-page setting after we restart the portal test environment. We add a portlet to a portlet page, everything is ok. However, after we restart the test environment, we should re-add the portlet to the portlet page again, because the configuration did not save to the Cloudscape database.
Answer: I'm assuming that you are running the portal test environment within WebSphere Studio. Because of the way the Portal Toolkit and the test environment work within WebSphere Studio, the portal gets reset every time you shutdown the Portal Test Environment. The environment is designed to be a simple testing facility to allow you to run a portlet within the portlet container. In the next version of WebSphere Studio, which is being rebranded as Rational Application Developer Version 6, this functionality is greatly enhanced with the ability to create pages and layouts within the environment.
Question: I am working on an engagement using WebSphere Portal 5.0. We have a requirement for conditionally displaying portlets based on a setting in the portlet application. For instance, if the user performs a particular action in a use case, the visibility of one or more portlets may need to change. Are there any recommendations for customizing the skin to handle these cases; or some way of controlling many portlets' visibility in the portlet application code (besides using Portlet Messaging)?
Answer: I'm confused as to whether you want the contents in the portlets to change, or if you need some of the portlets to disappear and reappear based on some settings. For changing content in various portlets, portlet messaging is your best bet. But, this would not necessarily allow you to hide an entire portlet.
For removing a portlet from the page entirely, consider writing a JSP tag library and using the tag to wrap your portlet skin. You need to determine some way to set a flag that the tag library could check and see if the portlet should actually be displayed. I've seen people use the User Object, or perhaps a Portlet Service, that provides some getters and setters to work like flags.
Question: Why is it not possible to have the more than one concrete portlets in the same concrete portlet application based on the same portlet? In other words, when a portlet is cloned from the portlet admin-->Portlets-->Manage Portlets, why should it create a new concrete portlet application also? We have a custom content publishing portlet application, which we would like to place in 20 pages and 5 instances of the same viewer portlet on each page. But each of these 100 concrete portlet instances would display a different preset information based on a flag the admin sets. The user has no control. To achieve this, as of current portal design, it needs 100 concrete portlet instances backed by 100 concrete portlet applications, to give the configure mode for each. Instead, we would like it to work like Edit mode but for the portal administrator, but still persist the settings for any back up or recreation, which is not possible. Please comment and suggest any workarounds.
Answer: WebSphere Portal does not allow you to reference a Concrete Portlet more then once per Concrete Portlet Application. However, this should not be stopping you from what you want to accomplish.
I suggest that you use the Configure mode and make your settings within the Portlet Settings. This is a very common approach that has been used successfully many times. You can setup the settings within the portlet.xml and the deployment of the WAR file will configure the multiple Concrete Portlets and the settings for each. An XMLAccess export of the portlet also provides information on the settings that have been made. You can use Edit Mode to have an administration make some setting changes that can be seen by all users. However, backing up and restoring these configuration settings will be more difficult.
On another note, you can put some thought and design effort into efficiently displaying the data within your portal. 100 portlets all displaying data from a single source can quickly overwhelm the content repository that you are accessing. Caching considerations will be useful as you continue with your design effort.
The author wants to thank the following people for their help in preparing this article:
- Kirk Davis
- Julia Weatherby
- Varad Ramamoorthy
- Skyler Thomas
- Brad Bouldin
- Steve Linn
- John Barron
- Taking a step toward virtual portals in WebSphere Portal V5
- Passing complex data types between cooperative portlets
- IBM WebSphere V5 Security WebSphere Handbook Series
- WebSphere Everyplace Mobile Portal: Part 1: Extending WebSphere Portal to a Mobile Audience
- Wiring Click-to-Action portlets for inter-portlet communication in WebSphere Portal V
- WebSphere Portal V5.0.2 Extend Collaboration Installation Guide
- IBM Software Services for WebSphere
- developerWorks WebSphere Portal zone
- developerWorks WebSphere Application Server zone
About Meet the experts
Meet the experts is a monthly feature on the developerWorks WebSphere Web site. We give you access to the best minds in IBM WebSphere, product experts and executives, who are waiting to answer your questions. You submit the questions, and we post answers to the most popular questions.
Dig deeper into WebSphere on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.