Preventing Help File from being exposed to the Web (Help File visible to authenticated Users)

[jasong23450100]

We have been using RoboHelp off/on for client projects for a decade, but these tools usually sit behind a corporate firewall so the help file itself is never exposed to the Internet. We have an application we are launching soon and we want to ensure that only authenticated users can access the Help File as well as the Training File (which is actually a separate RH file).

The primary goal is this:

• When a User logs into the main application, there is a Help File link on the top navigation ribbon. When the User clicks this button, it opens a new tab in the User's browser so they can navigate the Help File. .
• Our goal is to ensure that the contents of the Help File are restricted to authenticated users only.
  • This means that the Help File can only be accessed in two ways:
    • General Access. Basically, the idea is, if the User launched the Help file from the application, we could use the security token to automatically log them in and simply open the Help file - the user wouldnt need to log in a second time, since we already know they are a valid user.
  • URL Access. This covers us if a User bookmarked the Help File URL for some reason. If a user bookmarked that URL, then tried to access the Help File directly, they would be required to log-in first. (This could come in handy later, when we offer Training Certifications as a service to support the product.)

I am sure we are not the first company to want to protect the content of a help document from being exposed to the web, but we are stumped.

Our original plan was to place the Help file in an iFrame so we can use the authentication token to prevent the URL from being accessed by non-authenticated users. However, we are reading about issues where RoboHelp doesnt play well with iFrames. I'm reading up on RoboHelp Server, but Im not sure this is the solution for us, since on the surface, it appears that RH Server has its own independent authentication database and I am not sure if this can be connected to our existing application database. (We dont want to maintain the user list in two places, and Im not sure how RH server would deal with the encrypted passwords.)

I've scheduled a private demo with RoboHelp Server, and will post back anything fruitful from that meeting. I am not entirely clear what RoboHelp Server does - their marketing info is more hype than substance.

Thanks in advance for any input/insight!

[Willam_van_Weelden]

I believe RoboHelp server (separate product!) has features for this. But I'm not an expert, so I'm hoping that johndaigle‌ will bud in. RH server is quite old so I wouldn't recommend this route myself.

For regular help, the authentication is something you set up on your web server. RoboHelp creates a static HTML that you put on any webserver. With Apache, you can use the .htaccess file to control acces and IIS has all kinds of authentication. Basically: based on the server you are using, check whether the user is logged in within your application. Ask your server guy about the possiblities.

Security is always a pain and more so when you take a static website that you want to publish. But even if you don't have a site, you would have to program the integration yourself on the server.

[jasong23450100]

Thanks for the response William. This one is definitely a little tricky. From what I'm reading about RH Server, I dont know if it is a good fit or not. (But at $1,000... it's cheaper than some of our other alternatives, which include just building the pages manually so we can get the security and features we need.)

1. We have considered making the default RoboHelp landing page point to something we set up in IIS, where we can deal with the User to authentication.
   • It's not a very elegant solution and Im a little concerned about how RoboHelp would handle that, since it essentially a "Framed" website, a la the 1990s.
   • The upside is we can use the same authentication mechanism we are using now. And I dont have to worry about decrypting passwords for the RH Server.
2. At one point, we were looking at using IIS with some javascript, but they ran into some kind of problem there. (I'm not entirely sure what the issue was... I'd have to get one of my App Architects to explain what he encountered.)

I just got off the phone with an Adobe Rep and we are setting up a call (hopefully for this week) so we can talk with someone on the tech side of things. Apparently there is something in RoboHelp 2015 that they believe will align with our goals, which enables you to publish some content while protecting other content. I'm not entirely sure how that would work and havent been able to find any info about this in the RH 2015 features list, but we will see. (I probably need to update to RH 2015 anyway, but am hesitant to do that until I know for sure what we are going to do here.)

Conceptually, this is pretty simple, but in practice it gets a little more difficult. I was hoping someone had gone through this before, but maybe not.

I will post back with what I find out. My development team is pretty sharp, so if there is a way, we'll find it.

[jasong23450100]

Just following up on this.

An Adobe rep called me yesterday. We talked. She said she would send me an email (yesterday) and set up a meeting to talk with their technical support team. Still no email.

[johndaigle]

Hi, I belatedly noticed that Willam tagged me on this, so let me see if I can sort this out until Adobe gets back to you.

As you know, RoboHelp (the authoring tool) can generate numerous outputs:

1. WebHelp - plain framed web-based help published to a conventional web server
2. Responsive HTML5 layouts using the latest technologies for desktop and mobile devices (along with the new Dynamic Content Filtering capability)
3. WebHelp "Pro" - which is designed for publishing to a RoboHelp Server exclusively

As far as authentication is concerned:

1. WebHelp is limited to the ideas Willam outlined earlier (his second paragraph).
2. Responsive HTML5 can work on desktops, tablets and smartphones of various screen sizes. There is no built-in password-based authentication baked in, *but* there is a handy way to filter the content "on the fly" based upon certain audiences (for example, the London office would not see the New York office content which is not relevant to them.) However, this filtering is not authenticated. Rather it is for the convenience of the end-user to not have to sort through content that does not apply to them.
3. WebHelp Pro - This is published to a RoboHelp Server (optional). It has a very robust authentication system which allows for username/password authentication that can even be applied to certain content "Areas" which have been set up by the author. For example, perhaps all employees could look at general policies and procedures, but if they try to access information about Human Resources information that is private, a dialog would come up requiring them to put in their username/password before they could view it. For convenience, the users can be authenticated using LDAP.

Hopefully this will help a bit until Adobe gets back to you.

Thanks

John Daigle

Adobe Certified RoboHelp and Captivate Instructor

Evergreen, Colorado

www.showmethedemo.com