Railo 4 and IIS

So it has been a long, strange year of intensive Ruby on Rails development and I am glad to say I got both projects live and on to maintenance plans. I've been steadily releasing updates monthly and managing the feature list. Next I will be making a fork of one of the projects to make a similar app for a different department. That will require much more server and deploy issues, which I may talk about when that comes around.

However, now that I have had time to clear those up, a new project is to get our ColdFusion code from our old and hastily build Adobe ColdFusion 9 server to a new Railo 4 box. I've spent about a week working with a test IIS 7 box provided to me and have been allowed to build and fail and make a mess of things and I think I just about have it right.

There are documentation and discussions all over the place so I thought I should record my notes here. In general our server serves 4 sites and we had used multiple instances in Adobe's CF. I had wanted to replicate that process as well as lock down the Administrative interface from being accessed from the web (local access only). I don't think Railo does Multiple Instances as we have known them, but I wanted to run multiple web apps from the one server, which is nearly the same thing, almost. Not really, but for our purposes the technical differences are not meaningful. We want multiple sites/apps and no Admin access from the internet.

Prepping IIS

Ok, so the systems team built me a virtual server and he made some C-Names so that I could test multiple sites on the one box: app-testrailo.unm.edu and mobile-testrailo.unm.edu. I used my remote console and created the Web Server (IIS) role and included basic Web Server services and the Application Development services (ASP, .Net, CGI, ISAPI Extentions and Filters).

We keep our web files on a different drive from the C: so I created my sites: app and mobile and bound them to the urls and the path was set to z:\app and z:\mobile. Then I dumped in some sample apps so I would have something decent to test. Then I tested out the web server and viewed the successful HTML pages.

Prepping Railo

I read and followed the install instructions for Railo. The installer does it's thing very quickly. Up comes the basic Railo welcome page and links to my administrator. However, this is the Default root that lives in the default C:tomcat... Railo... Root folder. My regular web applications just gave me 500 errors. To link up my apps I needed to edit the Tomcat Host Config and restart the Railo service. Near the bottom of the Host Config file I needed to add these entries near the bottom:

         <Host name="hsc-testrailo.health.unm.edu" appBase="webapps">
             <Context path="" docBase="E:\hscapp" />
        </Host>

        <Host name="mobile-testrailo.health.unm.edu" appBase="webapps">
             <Context path="" docBase="E:\hscmobile" />
        </Host>

I also commented out the "localhost" entry since I was not using C:\inetpub\wwwroot\. I'm not sure if that was useful, but it seemed like a good idea. After a restart I am getting my apps to process the ColdFusion. Yay! Even cooler is seeing my sites in the list of Web contexts in the administration page. Double Yay!

Secure the Administrator

Now, I run some tests and the server administrator is available on the open internet. Boo! So we must secure the context. There are a number of Apache fixes discussed, but the key is to address the Bon Code Tomcat Connector for IIS. A Google Groups post gave me a hint. There is a "BonCodeAJP13.settings" file in the C:\railo\ajp13 directory where I can set the

<EnableRemoteAdmin>True</EnableRemoteAdmin>

to False. However this file is just the sample one, in my case the real one lives it the C:\Windows directory. It also administrative protected, so updating it was kind of a pain: file saved, Railo restarted, and my sites still work. And the url "http://app-testrailo.unm.edu/railo-context/admin/server.cfm" produces this error:

Access from remote not allowed (2).

Success!

Client and Server Side Form Validation Pt. 3

So, with a nice looking form, and some decent JavaScript processing my form works very nicely. However, I need to make sure that the server receives good data even if the JavaScript was turned off or not in play. All that form niceness is to help the user, now it is time to help the server.

Currently, my thinking on this isn't very solid. I'm asking the server to do a lot of work to double check the form and then determining if it should pass on the information to be processed or if the form needs to be displayed again.

This is not too bad if the form is small and has a predetermined set of fields. However, many of these forms are dynamically generated, so the processing has to be dynamically processed as well. This is where I try to take advantage of frameworks and partials to keep my display code in modular chunks- breaking out the form from the rest of the page.

Basically, I try to cfparam all the form fields and then validate the results and report them with the form. So if JavaScript does its job on the original form, great. If not, it still is taken care of before it hits the server. Regardless of the amount of work the server or I have to do, it is probably for the best.

Client and Server Side Form Validation

Something that has bothered me for a while is how to combine Client and Server Side form validation as painlessly as possible (as a developer) while still maintaining a pleasant user experience. Its not just about being able to fall back when Javascript is not available, but having secure input to the database. I like to consider the Ajax-y/jQuery to be mostly in service of making data entry more efficient.

To that end here is my form design thoughts.

1. Writing clear and concise labels and instructions (too many instructions means that my form has business logic problems)
2. Scripting input events to alert the operator to problems as they enter data and as they submit
3. Checking and sanitizing the data on the server before making changes to the database
• If the form is deemed valid, proceed to processing
• If there are problems, re-post the form and repopulate the data with error messages

From the reading I've done, there will always be some amount of duplication of code. This is the nature of web applications. This can be mitigated by having reusable code, both as JavaScript libraries and having modular server side code. How to do this will be the subject of this experiment.

My starting point is the article by Ben Nadel from December 2011 called How Client-Side Validation Is Changing The Shape Of Server-Side Validation. Part of the issues will be integrating the code into our style of FuseBox, finding a decent jQuery plug-in, I may have to buckle down and figure out how CFCs really work, figure out how to use Ajax and standard posts with the same code (probably related to CFCs) and lastly how to deal with dynamically generated forms.

Tall order. I should have done this years ago.