Domino 11.0 does not support java.pol

When running Java and XPages on Domino it is sometimes required to loosen up the Java security restrictions by editing the jvm/lib/security/java.policy file or by adding a java.pol file with the required changes.

But on HCL Domino 11.0 it is no longer supported to use a java.pol file since the java.security file in Domino 11.0 on longer includes a reference to a java.pol file. This (unfortunate) change is related to the move from the IBM JRE to the AdoptOpenJDK JRE.

In a future release of HCL Domino this could be re-introduced if HCL adds support for it in the java.security file. I have created an idea on re-adding support for it.

Thanks to Daniele Vistalli for pointing out that you can use the option to add a modified java.policy file to the home directory of the user running the Domino instance since the java.security file still includes this option:

policy.url.2=file:${user.home}/.java.policy

On my Windows Server the Domino service runs under the local system account and the home directory of the local system account is C:\Windows\System32\config\systemprofile. So by adding a modified .java.policy file to this directory, it does indeed work (notice that the file must be called .java.policy according to policy.url.2 in java.security).

Update January 2022:

As of Domino 12.0.1 support for java.pol is back. The java.security file now contains a reference to a java.pol in the same directory as the java.security/java.policy files:
policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${java.home}/lib/security/java.pol
policy.url.3=file:${user.home}/.java.policy

IBM Domino and IBM Notes/Domino Designer 9.0.1 FP10 has been released: major update to the platform!

IBM Domino and IBM Notes/Domino Designer 9.0.1 Feature Pack 10 has been released today and is available for download on IBM Fix Central. This is a major update to the platform.

The most important updates for developers include:

  • Upgrade from Java 1.6 to Java 1.8 for both Domino Designer and the server
  • The Domino Designer Eclipse platform is now running version 4.6.2 (a major upgrade from Eclipse 3.4.2)
  • OSGi is upgraded

More details of changes are available at developerWorks. Details of all fixes will be available later in the usual Fix List database.

I’m a 2016 IBM Champion!

It has been a great year with focus on the 2 businesses that I am involved in: Sherlock Web and fmcg solutions.

I have not been involved with public speaking this year but still try to help the XPages developer community on Stack Overflow as much as I can.

It came as a pleasant surprise that I was elected as IBM Champion for 2016. I’m once again honored to be part of this amazing group of people!

I am going to the 52nd DanNotes conference

The 52nd DanNotes conference takes place on November 19 and 20.

The conference starts off with a keynote by Kramer Reeves. After the keynote the developers can then look forward to Christian Güedemann, Nathan T. FreemanJohn Dalsgaard and others. The administrators can look forward to Mikkel Heisterberg, Ben Menesi and others.

See you there?

XPages: Optimized partial refreshes for event handlers

Sven Hasselbach has created an optimized version of the XSP.partialRefreshPost() method. This works great to reduce the number of form fields that are included in the request for a partialRefreshPost.

But his version does not include support for running server-side actions because the the form fields included in the POST doesn’t include the server-side event handler.

So I have created an optimized version of his optimized version that supports this 🙂
My versions adds a ‘submitid’ parameter that should point to the id of the event handler that you want to execute on the server.

XSP.partialRefreshPost(
    '#{id:somePart}',
    {
      clearForm: true,
      submitid: '#{id:submitEventHandler}'
    }
);

Here’s an example of using the optimized partial refresh for an eventhandler:

<xp:button id="button1">
    <xp:eventHandler event="onclick" submit="false" id="submitEventHandler" refreshMode="partial" refreshId="somePart">
        <xp:this.action><![CDATA[#{javascript:someServerSideAction();}]]></xp:this.action>
        <xp:this.script><![CDATA[
            XSP.partialRefreshPost(
                '#{id:somePart}',
                {
                    clearForm: true,
                    submitid: '#{id:submitEventHandler}'
                }
            );
        ]]></xp:this.script>
    </xp:eventHandler>
</xp:button>

Here’s the complete code snippet (available as an OpenNTF XSnippets too):

	<xp:scriptBlock id="scriptBlockPROptimized">
        <xp:this.value><![CDATA[
			XSP.addOnLoad(function(){

			    // hijack the existing partial refresh method
			    if( !XSP.__partialRefresh ){
			        XSP.__partialRefresh = XSP._partialRefresh;
			    }

			    // add the new one to the XSP object
			    XSP._partialRefresh = function x_prfh(method, form, refreshId, options){

			        // clear the form?
			        if( options.clearForm ){

			            // create a new HTML form...
			            var newForm = document.createElement( "form" );
			            newForm.setAttribute( "method", form.method );
			            newForm.setAttribute( "action", form.action );

			            // ... and loop all existing fields
			            for( var i = 0; i<form.length; i++ ){
			                var field = form[i];
			                var fieldName = field.name;
			                var includeField = false;

			                try{

			                    // check for addition fields
			                    if( options.additionalFields ){
			                        includeField = dojo.indexOf(options.additionalFields, fieldName)!=(-1)?true:false;
			                    }

			                    // only add XPages relevant fields and addtional fields
			                    if( fieldName == form.id || fieldName.substr(0,2) == '$$' || includeField ){

			                        var newField = null;
			                        if( field.options ){
			                            // special handling for fields with options
			                            for( var j=0; j<field.length; j++ ){
			                                if( field.options[j].selected ){
			                                    newField = document.createElement( "input" );
			                                    newField.setAttribute( "type", "hidden" );
			                                    newField.setAttribute( "name", fieldName );
			                                    newField.setAttribute( "value", field.options[j].value );
			                                    newForm.appendChild( newField );
			                                }
			                            }
			                        }else{
			                            // default field handling: just clone the DOM element

			                            // check for $$xspsubmitid option
							            if( options.submitid && fieldName == "$$xspsubmitid"){
							                newField = document.createElement( "input" );
							                newField.setAttribute( "type", "hidden" );
							                newField.setAttribute( "name", "$$xspsubmitid" );
							                newField.setAttribute( "value", options.submitid );
							                newForm.appendChild( newField );
							            } else {
				                            newField = field.cloneNode( true );
				                            newForm.appendChild( newField );
				                        }
			                        }
			                    }
			                }catch(e){
			                    console.log(e);
			                }
			            }

			            // call the original refresh method with the new form
			            return XSP.__partialRefresh(method, newForm, refreshId, options);
			        }

			        XSP.__partialRefresh(method, form, refreshId, options);
			    };
			});
		]]></xp:this.value>
    </xp:scriptBlock>

Keep in mind that to optimize a partial refresh you need to focus on more than just the size of the POST request. You should also look at partial execution mode (execMode=“partial”) in order to reduce the amount of work that the server has to do.

Authenticating your IBM Domino and IBM XWork Server web apps against Active Directory (LDAP)

With IBM Domino and IBM XWork Server you can set up web authentication against an external LDAP such as Microsoft Active Directory. This is useful if you are deploying a web application and your users are already in an external directory. In this blog post I will show you how to set this up.

  1. Create a Directory Assistance application on the server based on the Directory Assistance application template
  2. Edit the server document in the Domino Directory and add the path to the Directory Assistance application from step 1 to the Directory Assistance database name field on the Basics tab
  3. Create a new Directory Assistance document in the Directory Assistance application and fill out the following:
    1. Domain type: LDAP
    2. Domain name: Company domain (notice: the domain name in the Directory Assistance document MUST not be equal to the Domino domain!)
    3. Company name: Company name
    4. Naming Contexts (Rules) – Trusted for Credentials: Yes
    5. Hostname: host name of Microsoft Active Directory (tip: use the Verify button to check access to the host)
    6. Optional authentication credential for search: If the Active Directory does not allow anonymous LDAP searches, then add username and password for a user with access to Active Directory
    7. LDAP vendor: Active Directory
    8. Base DN for search: DC=company,DC=com (use the Suggest button to find the correct format)
    9. Channel encryption: SSL or none (notice: if changing from SSL to none make sure that Naming Contexts (Rules) – Trusted for Credentials is not changed from Yes to No)
  4. Restart your server

It’s now time to test your your LDAP configuration. Start by creating a new application with access control set to Readers for Default and No Access for Anonymous. Try to access the application from a browser and you will be prompted for credentials. Now logon using a valid username and password. You will be able to access the application if your Directory Assistance setup is working. Congratulations – you can now deploy your web application and have users authenticate using Microsoft Active Directory – without having any user details stored on the IBM Domino/IBM XWork server!

If authentication fails, you should start with issuing the “show xdir” command on the server console. You should see two entries in the list – the first one pointing to the Domino directory (names.nsf) and the second one pointing to your LDAP configuration.

You can also use the webauth_verbose_trace=1 option to enable debug messages on the server console by issuing “set conf webauth_verbose_trace=1” on the server console.