R9

Lowering your ODS – an oldie but goodie

Marky Roden R9, XPages

After Connect this year I tried to post my Ext JS sample database on my demo site and most users were reporting unsupported notes version. I did some digging and it turns out that amongst everything else R9.0.1 has a newer ODS (52) and therefore would not run on a lower than R9.0.1 server/client.

So after much idiocy and locally encrypted stupidity on my part, I did a search around and found/remembered that you can reduce the ODS aaaaaall the way back to 20 by doing this

  • File – Application – New Copy
  • Name the file .NS4 (backwards compatible to R4 no less)
  • Rename the .ns4 as a .nsf
  • and it worked !!

Obviously XPages will not work on an R4 server – but by reducing the ODS it make it compatible with the R8.5.x servers

Bizarrely enough it was also quite significantly smaller than the nsf copies I was creating ODS 52

XPages ND9 (Dojo 1.8) does not work with other AMD loaders (and the work around)

Marky Roden dojo, JavaScript, jQuery, R9 , ,

Today I took a new jQuery plugin that I was playing with from an R8.5.3 environment where it worked, to an R9 environment and it failed – I figured it had something to do with something I had been reading about over the last month and in fixing my problem this lead to a more serious realization that I KNOW other people are also going to come across.

Background

A brief scan of the last month’s discussions on Xpages and jQuery Mobile 1.3 reveals a number of posts started by Dave Leedy regarding the use of IBM Notes Domino 9 and jQuery Mobile 1.3

http://notesin9.com/index.php/2013/04/20/jquery-mobile-seems-incompatible-with-xpages-in-domino-9-0

http://hasselba.ch/blog/?p=1216

http://stackoverflow.com/questions/16058039/jquery-mobile-in-xpages-passing-parameters

http://www.eknori.de/2013-04-21/followup-jquery-mobile-seems-incompatible-with-xpages-in-domino-9-0/

What’s going on?

I saw the following Tip from Sven Hasselbach (very smart man!) on Dave Leedy’s blog post

Looks like an AMD loader problem with Dojo & JQM. I have tried out to disable the Factory scan in a test page and this worked for me. To do this I have added the following parameters in the xsp.properties:

xsp.client.script.dojo.djConfig=dojo-amd-factory-scan: false

Maybe this can help you with your problems in ND9.

This lead me to this bug report

https://bugs.dojotoolkit.org/ticket/15616

make dojo work with other AMD loaders

Which then lead me to the realization that this is a bigger issue than just JQM 1.3 and I solved my problem and here is how.

Solution (ND9)

Within the Package Explorer  (Window—open perspective –> xpages) in the WebContent folder for your database you will find the xsp.properties file (as described http://heidloff.net/home.nsf/dx/06172011015521AMNHE8Y7.htm)

xsp1

Click to open the Source Tab

and enter the following

xsp.client.script.dojo.djConfig=dojo-amd-factory-scan: false

And Save – that’s it

Result

If you look at the source code of the created XPage you will see that the new parameter has been added to the script tab creating the dojo.js as a djConfig property

xsp3

doing a quick search explains what this property does

http://dojotoolkit.org/documentation/tutorials/1.8/dojo_config/

“For example, we could disable the amd factory scan (scanning the module for CommonJS require(module) statements to load as deps) with…”

Not only does that solve the problem with jQuery Mobile, it also solved my problem with the jQuery Table plugin which I wanted to use, which used require.js to load the jQuery dataTable plugin.

GENIUS

thank you Sven Hasselbach (again!)

Domino R9 – now FIPS 140-2 compliant – necessary for doing business with the DoD

Marky Roden Just Marky, R9

As revealed in this years IBM Connect – ID109 IBM® Notes® and Domino® – Security Strategy – Domino R9 is now FIPS 140-2 compliant

About time too !!

The presentation can be downloaded from here

http://www.socialbizug.org/communities/service/html/communityview?communityUuid=0b366f56-cdf9-43d0-a5d3-4b2b96d86598#fullpageWidgetId=W3467cdf91608_40f1_b9fd_d0d2dcf37b05&file=b40036cc-ea99-4f44-9a60-6c3a93016816

From – http://en.wikipedia.org/wiki/FIPS_140
The 140 series of Federal Information Processing Standards (FIPS) are U.S. government computer security standards that specify requirements for cryptography modules. As of December 2006, the current version of the standard is FIPS 140-2, issued on 25 May 2001

FIPS-140 – what’s that then and who cares?

The bottom line is that the US government wants to be able to encrypt their networks and the FIPS compliance structure was created to ensure that all parts of the government could do business with the same encryption rules – still sounds like a good idea. The Notes/Domino architecture was years ahead of its time in realizing this corporate need !

I worked as a contractor to the DoD some years ago and they shut down their entire Notes R6.5 Intranet (13 years in the making) because it was not FIPS compliant. They moved to SharePoint (which for the record was not FIPS complaint but got “grandfathered in”….) and ended up with significantly less functionality. Some were happy about some were incensed, but it happened and the reason was justifiable (to them at least).

This means that FIPS compliance can no longer be a convenient excuse as to why Notes should be dropped in favor of another technology and it also brings it back to the table as a viable option for deployment in a  secure environment.