Page 1 of 1

Securing Access to Flare HTML5 Output

Posted: Mon Sep 14, 2015 12:59 pm
by Tatton
Has anyone come up with a good method for delivering and securing web output from Flare? I'm trying to find a stable way to be able to deliver Flare's HTML5 output on a public web server behind a user authentication system. Ultimately I want to be able to provide our users (who external customers) access to our HTML5 output without opening it up to the outside world. I've looked at Pulse and for this and it's not secure enough to be able to solve our problem since it doesn't block unauthenticated access. Does anyone have any experience or suggestions to share? Thanks in advance!

Re: Securing Access to Flare HTML5 Output

Posted: Mon Sep 14, 2015 11:11 pm
by devans
Our HTML5 output is only available to our customers. I can't tell you much about how it's done but I change the default.htm file to default.aspx and then users are forced to login with credentials we supply to them. Obviously our developers have written some code which does this authentication.

Re: Securing Access to Flare HTML5 Output

Posted: Mon Sep 28, 2015 4:25 pm
by Ken Fredric
The (HTML5) online help for our software resides on an IIS web server, which is not publicly available. Also, we don't allow browsing directly to the online help, and only provide access via the software.
The web server is configured to not allow access unless the call to help contains a token, which is generated by the software. Once you have access to the help system you can then browse any other topics as required.
The key here is the security token that is generated by the software. Not sure from the information you've given whether this would be possible for you.

Re: Securing Access to Flare HTML5 Output

Posted: Tue Sep 29, 2015 10:14 am
by Ineffable
I smell a feature request for Flare. Maybe some sort of built-in authentication system, akin to the Pulse stuff but for the entire system, not just for commenting, something that can sync up with existing corporate systems (Exchange would be ideal; login using your existing Office login).

My online help is "top secret" as well, and I was provided with some code that I add to every page of my output. The code in question calls home to a server whose sole job is to authenticate. It then returns a cookie that allows the page to be viewed by the user. From what I'm told, it's not a very sophisticated authentication system (something about using a 1px-by-1px iframe injection?), but since my content does not contain nuclear launch codes, it's satisfactory.

I considered activating .htaccess on my CentOS server, but the problem is that my user base already has an Oracle login; I didnt' want to have to my users create a new account solely for viewing my content. As it stands, the aforementioned iframe system is authenticating an already-existing user. One caveat in my help system is that it's served from a non-corporate server (Rackspace), so there is a lot of cross-domain stuff going on, which IT/security people don't particularly like, but, like I said, we're dealing with low-flammability content.