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.
This, and nothing else, seems to get the ACT for Web interface working via SSL. If you hit the Mobile website, however, you'll see we're not quite done yet: the CSS is missing and you will receive an error about enabling Javascript, even if it's already enabled.
Setting up the ISAPI filter on the secure site
Digging into the HTML a bit, you can see that the mobile web interface links several javascript files that, if you follow the link, the server will report as missing. This is due to a configuration change the ACT install makes to the IIS site it installs on: It adds a custom ISAPI filter that parses these requests. This will have to be added manually to 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!
Testing the ACT for Web Mobile site worked on some, but not all the mobile browsers I tested. Though the CSS loaded properly thanks to the previous step, I still got warnings about enabling Javascript on some mobile browsers. Again looking at the HTML, I discovered the reason: the links to the off-site jQuery libraries are hard-coded to HTTP.
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
Disclaimer:
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:
<script src="http://code.jquery.com/jquery-1.8.3.min.js"></script>
needs to become
<script src="//code.jquery.com/jquery-1.8.3.min.js"></script>
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!
Once this is done, reload the mobile page in your browser of choice, and you'll see the Javascript warnings disappear and everything works properly.
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!