Tuesday, September 30, 2014

Don't What it, Hitch It

Async callbacks and closures is an incredible thing about JavaScript.   This is what makes environments like nodejs possible, a topic of many blogs to come.  Many of the JavaScript frameworks like my favorite framework Dojo have the ability to deal with closures and callbacks.  One of the issues that one needs to deal with is getting a handle to the current scope within a closure.

We discussed this and how to deal with it in Dojo in a previous blog.

http://dominointerface.blogspot.com/2014/03/when-is-this-is-this-and-what-is-this.html


The nice thing about Dojo is how extensive the library is.  This is also a negative thing since there is so many features that you might not beware of. As I am converting our iPhora library from Dojo 1.53 to Dojo 1.10.0, I realized there is also another method that you can use to get a handle to the current scope within a closure and that is dojo.hitch which has been around for a long time. 

In our previous example, we had a simple widget.

<div class="widget" id="happy">
<ul>
<li id="1">
  <a href="#" tabindex="-1"><i class="icon-tools"></i>Hello</a>
 </li>
<li id="2">
  <a href="#" tabindex="-1"><i class="icon-tools"></i>Hello</a>
 </li>
<li id="3">
  <a href="#" tabindex="-1"><i class="icon-tools"></i>Hello</a>
 </li>
<li id="4">
  <a href="#" tabindex="-1"><i class="icon-tools"></i>Hello</a>
 </li>
<li id="5">
  <a href="#" tabindex="-1"><i class="icon-tools"></i>Hello</a>
 </li>
</ul>
</div>

To get handle to this within the closure, you can use this method
dojo.query('ul > li',this.domNode).connect('onclick',this,function(e){
 alert(this.id);
});


or define "what" equal to "this" to get a handle
var what=this;
dojo.query('ul > li',this.domNode).connect('onclick',function(e){
 alert(what.id);
});


With Dojo, you can also provide the current scope "this" by using dojo.hitch
require(["dojo/_base/lang","dojo/query"],
  function(lang,query){
    query('ul > li',this.domNode).on('click',lang.hitch(this,function(e){
       alert(this.id);
      }));
});


Though you can use dojo.hitch in this way to replace the previous methods, one of the best ways to use dojo.hitch is with async xhr callbacks.  dojo.hitch provides an elegant approach when you need to do a callback during an async request.  I use this all the time for populating widgets or in the case of the MVC terminology, controllers.

If you try this.
require(["dojo/_base/xhr"], function(xhr){
  var args = {
    url: "hostnameurl",
    load: this.callback
  };
  xhr.get(args);
});


you will get an error because "this" is not defined within the closure of the xhr request. You could define var what=this provide a handle as we did before. However, dojo.hitch is a better solution.

require(["dojo/_base/xhr","dojo/_base/lang], function(xhr,lang){
  var args = {
    url: "hostnameurl",
    load: lang.hitch(this,callback)
  };
  xhr.get(args);
});

Now, you can get a handle to your current scope "this" and your callback will not bomb.

Monday, September 29, 2014

Installing Nginx Reverse Proxy on CentOS for Domino Our Experience

Over the past few weeks there has been a significant number of discussions about Domino and the lack of SHA-2 support.  Jesse Gallagher had an entire MWLUG 2014 session on this very topic.  When I ask Jesse to present on this topic, unbeknownst to me what a hot topic this would become and so timely.  First, IBM should have fixed these problems years ago.  For us this is a critical issue that if not addressed will kill the market for Domino.

Thanks to Jess efforts and contributions, there is a workaround that he presented and published recently in a series of blog articles on this very topic.  His solution is to configure nginx as a reverse proxy for Domino so that SHA-2 certificates can be used with Domino. nginx is not just a Linux solution but can also be a Windows solution since it is available for the Windows platform.

Jesse's article focused on setting up nginx reverse proxy on a Ubuntu server.  My comments here are about the differences between what Jesse explained for the Ubuntu server and what you will encounter in configuring nginx on CentOS in particular CentOS 6.5.

A great resource to guide you through the process of installing Nginx on CentOS can be found here:

http://www.rackspace.com/knowledge_center/article/centos-installing-nginx-via-yum

By default the installation will not create site-available and site-enabled directories as it would in Ubuntu.  And they are not needed. A series of default SSL configure files will be created in the /etc/nginx/config.d directory including a ssl.conf template file and default.conf.   Make a copy of the ssl.conf file with the suggested renaming convention that Jesse explained and edit it in accordance to Jesse's instructions.  One thing to remember is that you need to rename the default.conf file in order for your new conf file to work.  If not, the default.conf file will override your new conf file settings.

After installing nginx you will need to create a request key for the SSL certficates

1. Create a directory for the SSL certificates, # sudo mkdir /etc/nginx/ssl

2. Switch to this directory # cd /etc/nginx/ssl

3. Create the request

# sudo openssl req -new -days 365 -sha256 -nodes -keyout example.com.key -out example.com.csr -newkey rsa:2048 

Notes: 
leave out -sha256 for a SHA-1 request.
the -keyout parameter is the filename is the name of the key file that will be created
the -out parameter is the name of the request that will be sent to the certificate authority
in response to this command, you will asked to provide the organizational information and address, etc.
if the certificate expiration is to be different than one year, change -days 365 to the desired number of days

4. Limit access to the key , # sudo chmod 400 portal2.phoragroup.com.key

5. Send the .csr file to the certificate provider for signing. They will send back a crt file.

6. Limit access to the signed certificate, # sudo chmod 400 example.com.crt

7. The certificate authority may send back multiple files. If so, then concatenate them:

# sudo cat example.com.crt  root1.crt > example.com.combined.crt

Notes:
The CRT file with your hostname.crt should be first. If there is more than one root or intermediate certificates, not sure of the order of those (try it and see).


After concatenating the keys to create the combined file, make sure you have a carriage return between the beginning and ending of each certificate. If you do not do this you will get an ERROR.

# sudo vi example.com.combined.crt 


The process is relatively easy even for a Linux newbie like myself.  We are planning to add nginx as our reverse proxy for all our installations of Domino.  One advantage of having nginx as reverse proxy is that by having Domino connect using http instead of https for the reverse proxy, there is less loading on the Domino server and the system as a whole can handle more https connections.
 
The installation process of the SSL certificate follows the standard convention used by most solutions rather than the specific approach required by Domino.  Therefore, there is much more documentation available.

Additional articles I suggest one read is:
 
http://www.nginxtips.com/hardening-nginx-ssl-tsl-configuration/

Please note, that if you have Network Solutions, they still do not have SHA-2 certificates available yet.  Can't believe that.

To learn more on how to install CentOS and Domino, Devin Olson has a series of great videos and pdfs on Youtube. 

http://www.youtube.com/watch?v=geBE13qqz7w


If you want to chat with the ICS Linux, sign up for the ICS Linux Chat on Skype that was started by our friend Bill Malchisky. 

Thursday, September 25, 2014

Gotcha, Creating Dynamic Script Blocks Using SSJS

For our iPhora applications we only use one XPage and dynamically create the content that appears.  We do this by storing the dynamic content in Notes Rich Text fields and using SSJS to read and generate the HTML/JavaScript during runtime. 

Since we are moving to an single page MVC model, we were adding a few addition xp:scriptBlock to generate the initial loader and pulling the information from a NotesRichText field.  We were using doc.getFirstValueString('richtextfield') to pull and create the script. No problem until, we had a JavaScript object declaration that was longer than 72 odd characters.

Unfortunately, there is an issue with Notes Rich Text fields that we encountered in the past using LotusScript that I forgot all about.  When you read a Notes Rich Text field it will automatically add a carriage return after 72 characters and this can drive you crazy. If the carriage return occurs between a JavaScript object declaration then you will get an JavaScript error.

To resolve this you need to switch to doc.getFirstItem("richtextfield").getUnformattedText() to read it.  The automatic carriage return that Domino/Notes pulls in is filtered out, but the carriage returns that you put in remains.