Skip to Content

Portal Desktop Rule based on Hostname

This blog explains how to setup a desktop rule based on the requested hostname. By default it is not possible to setup a desktop rule based on hostname or url. My solution consists of two parts. First a custom login module which is executed at login of a portal user and second the actual desktop rule, which is the easiest part as you will see in a minute.

The scenario 

You have a user community which mainly consists of two groups. One group (I will call them usergroupA) can access Portal A, and the other group (usergroupB) can access Portal B. But, Portal A and B aren’t really different portals, they are just different desktops with different content. They are running on the same portal instance. There is also a group of users (usergroupAB) that is allowed to access both Portal A and Portal B.

Portal A can be requested using the url:

Portal B can be requested using the url:

Both connecting to the same ip address.

Custom Login Module

The custom login module is a subclass of The most important methods to implement are login() and commit(). The flow of the login process in this module is represented in the picture below:


So, the login() method handles the HTTP Callback to retrieve the username and the requested hostname:

((HttpGetterCallback) callbacks[0]).setType(HttpCallback.REQUEST_PARAMETER);
((HttpGetterCallback) callbacks[0]).setName(“user_name”);
((HttpGetterCallback) callbacks[1]).setType(HttpCallback.HEADER);
((HttpGetterCallback) callbacks[1]).setName(“Host”);

try {
} catch (UnsupportedCallbackException e) {
return false;
} catch (IOException e) {
throwUserLoginException(e, LoginExceptionDetails.IO_EXCEPTION);

//Returns an array of all request parameters with name “user_name”.
String[] requestParameters = null;
String headerParameters = null;
Object objReqParam = ((HttpGetterCallback) callbacks[0]).getValue();
if (objReqParam != null) {
requestParameters = (String[]) objReqParam;
Object objHeadParam = ((HttpGetterCallback) callbacks[1]).getValue();
if (objHeadParam != null) {
headerParameters = objHeadParam.toString();

if ((requestParameters != null) && requestParameters.length > 0) {
this.userName = requestParameters[0];

if (this.userName == null && sharedState.get(AbstractLoginModule.NAME) != null) {
this.userName = (String) sharedState.get(AbstractLoginModule.NAME);

if (userName == null) {
throwNewLoginException(“No user name provided.”);

if ((headerParameters != null) && headerParameters.length() > 0) {
hostName = headerParameters;


Now we have both the username and the hostname, we can check if the user is allowed to access the requested portal. When a user is at least in a group called PortalA-Users he is allowed to access PortalA, if he is not he is denied access to portal A (same applies for Portal B):

IUser user = userFact.getUserByLogonID(userName);

groupACheck = gf.getGroupByUniqueName(“PortalA-Users”);

if (hostName.toUpperCase().startsWith(“PORTALA”)) {
//Check authorization role.
if (!groupACheck.isUserMember(user.getUniqueID(), true)) {
throwNewLoginException(“No access to portal A.”);
return false;


In the commit() method the user is assigned to a group on which the Desktop rule will be based, and of course removed from the other group:

groupA = gf.getGroupByUniqueName(“ADesktop”);
groupB = gf.getGroupByUniqueName(“BDesktop”);



if (hostName.toUpperCase().startsWith(“PORTALA”)) {
//Remove from B group
try {
gf.removeUserFromGroup(modUser.getUniqueID(), groupB.getUniqueID());;
} catch (UMException e) {
//Add tot A group
try {
gf.addUserToGroup(modUser.getUniqueID(), groupA.getUniqueID());;
} catch (UMException e) {

Desktop Rule

Two desktop rules based on Group are created. 

IF Group=ADesktop -> com.topforce.ADesktop

IF Group=BDesktop -> com.topforce.BDesktop

The two desktops also have a different theme. So they look totally different.

The Result

UsergroupA has only access to and is denied access to PortalA is shown with its own desktop and portal theme.

UsergroupB has only access to and is denied access to PortalB is shown with its own desktop and portal theme.

UsergroupAB has access to both portala and portalb and is shown the content with the right desktop and theme. Of course usergroupAB is allowed to see content from both portal A and portal B, but we don’t want to mix content. So portal A should contain only content meant for portal A and vice versa.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.