Community
Showing results for 
Search instead for 
Do you mean 
Reply

Notes on moving Act v16 for Web to SSL and resolving Mixed Content Blocking problems

New Member
Posts: 1
Country: USA

Notes on moving Act v16 for Web to SSL and resolving Mixed Content Blocking problems

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!

Silver Super Contributor
Posts: 2,328
Country: USA

Re: Notes on moving Act v16 for Web to SSL and resolving Mixed Content Blocking problems

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.

 

Stan


If you would like to get more out of ACT! you can find an ACT! Certified Consultant near you by going to:www.act.com/acc.
-------------------------------------------------------------------------------------
Stan Smith
ACT! Certified Consultant
ADS Programming Services, Inc.
(205) 222-1661
www.adsprogramming.com
www.actwebhosting.com
Click Here to Purchase Act!
Bronze Elite Contributor
Posts: 2,546
Country: New_Zealand

Re: Notes on moving Act v16 for Web to SSL and resolving Mixed Content Blocking problems

Good information, Act! development team could do well to make the changes suggested and acknowledge the generous contribution by J Rogers.   

Graeme Leo
Xact Software - consultants and developers
Follow us on Twitter and check out our Blog


New Member
Posts: 9
Country: Canada

Re: Notes on moving Act v16 for Web to SSL and resolving Mixed Content Blocking problems

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.

Mike Johnston, ACC
www.keystroke.ca
Copper Contributor
Posts: 55
Country: USA

Re: Notes on moving Act v16 for Web to SSL and resolving Mixed Content Blocking problems

[ Edited ]

Thanks so much for taking the time to share your knowledge!  Swiftpage support told me in advance that they would not support the SSL configuration, so I was SO happy to find your detailed post.  I didn't find those ISAPI files you mentioned, but just changing the http:// to //  in the 2 cshtml files fixed the Javascript errors.



Wendy Cummins
ACT! Certified Consultant
Patricia Egen Consulting
New Member
Posts: 5
Country: United States

Re: Notes on moving Act v16 for Web to SSL and resolving Mixed Content Blocking problems

[ Edited ]

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.