11-12-2013 01:44 PM
I've recently set up a web-access configuration for a local company. Although unfamiliar with Act specifically, I'm very familiar with databases, servers, web apps and IT in general.
This company handles sensitive customer data, so setting up Act for Web using SSL was an absolute must. Since the documentation regarding this is a bit sparse, I thought I'd share some of my discoveries, as well as the fixes for some of the problems I encountered. Obviously this is my own personal experience and you may encounter different problems.
All of the following took place on a Windows 2012 server using Act Premium Version 16.0.291.0, Hot Fix 4.
This assumes you are already somewhat familar with IIS Manager and that you already have a secure site with a working certificate.
Moving the ACT for Web application to the secure site
During the initial setup, Act did not prompt me for which IIS web site I wanted to use; it automatically installed to "Default Site", which did not have an SSL binding. This meant I needed to use the IIS Manager to move the ACT applications to the secure site. The official Web Administrator Guide glosses over this process.
Fortunately, this was fairly straightfoward. ACT v16 creates 4 application folders: AFWValidationSrvc, APFW, APFWMailMergeSrvc, and APFWOutlookSrvc. Although IIS Manager does not have a "move" function for applications, you can copy the path settings from the existing applications (select the application folder and chose "Basic Settings") and re-create them on the target site. After you've re-created all 4 application directories, restart the the secure site.
Setting up the ISAPI filter on the secure site
Again, this is a fairly straightforward process. Open the Default Web Site and take a look under "ISAPI filters". There may be several entries present here, but we're looking for the one called "IIRF". Double-clicking that will get you the path to the file (C:\Program Files (x86)\ACT\Act for Web\IIRF.dll on my system). Copy this path, then go to the target website, open ISAPI filters, and choose "Add...". Put IIRF for the filter name, and for the executable, paste the path you just copied from the other entry. Hit okay, then restart IIS. Now the mobile site should load properly.
BUT WAIT, THERE'S MORE!
Mixed Content Blocking and ACT!
This is fine when you're not using SSL, but some browsers (most notably Firefox) will refuse to load non-SSL resources on an SSL page, as there is a possibility of data being leaked from the SSL session. This is called "Mixed Content Blocking" and it is either in the patch pipeline or already implemented for ALL major browsers, including mobile browsers. You can see this error by visiting the mobile version of the Act for Web site at https://<your server name>/APFW/M using Firefox, Chrome, or IE9+.
In other words, this isn't a major problem now (as the default mobile browsers are not yet patched with MCB), but it will become one with time, and Swiftpage would be wise to fix it quickly. In addition, fixing it allows you to use any modern mobile browser with Act for Web, not just the officially supported (and outdated!) Safari and Android browser.s
Got all that? Great! Now on to the actual fix, which is dead simple. We need to modify the source files to use so-called “protocol relative” links to the jQuery CDN. Since jQuery is kind enough to host their files on both secure and non-secure servers, this is a very simple change for us to make.
Making the mobile site use protocol-relative links for jQuery
This involves changes that are almost certainly going to be unsupported by the good folks at Swiftpage, and if you mess around with this, don't expect them (or me!) to pick up the pieces if it goes pear-shaped! I shouldn't even need to say this, but... try this on a test setup first, NOT in a live/production environment! If you are AT ALL uncomfortable with ANY of the steps listed here, DO NOT ATTEMPT THIS and instead wait for an official fix from Swiftpage.
This involves modifying two of the source files for ACT!'s web interface, which I'll refer to by their default location.
In each file, we want to remove the prefix http: from the line. Fox example:
needs to become
It should be safe to do a find/replace of "http://" with "//", but check the total number of replacements made for each file.
The files to be modified are:
C:\Program Files (x86)\ACT\Act for Web\APFW\Views\Account\Index.cshtml (lines 12, 14 and 15)
C:\Program Files (x86)\ACT\Act for Web\APFW\Views\Shared\_Layout.cshtml (lines 11, 31, 32, 38, and 39)
BACK THESE FILES UP BEFORE MODIFYING THEM!
Now it should be safe to remove the APFW application folders from the Default Web Site, and run exclusively on HTTPS!
I hope some of this information is useful to other people!
11-12-2013 02:57 PM
Thanks for sharing! I've saved it for the next time someone wants to set up ACT! for Web on an SSL machine. It doesn't happen very often but it will be handy when it does. Especially the jQuery notes.
11-17-2013 03:25 PM
01-24-2014 07:39 AM
Thanks for the help, this was a fantastic and very helpful post. I was on the right track when I noticed the CSS in the source was missing but you connected the dots for me and saved me a big headache. Though I'm hopeful I won't run into this again your help deserves much recognission. Thanks again.
03-11-2014 01:06 PM - edited 03-11-2014 01:15 PM
05-08-2014 07:04 PM - edited 05-08-2014 07:05 PM
Thank you for the info on the hard coded http:// references for jQuery, very helpful.
SP1 for Act Premium Web v16, which was released on 5/6/14 does not address the harder coded http:// references.
I find it to be EXTREMELY poor on Swiftpage's part to hard code http:// references, and even worse to be telling customers they won't support an SSL deployment. This is a product that should always be accessed through SSL if done over the public internet.
If they don't want to "support SSL" (not that they need to do anything except make sure they have no hard coded http:// references), they should update all their Act Premium Web documentation to indicate that a VPN connection should be used if accessing the product over the internet.
I guess I shouldn't be too surprised here. Swiftpage's own Act Premium Web demo site is not SSL and I wonder if their paid hosted environment is not SSL either, that would be...hilariously sad.