Skip to main content
jasong23450100
jasong23450100
Participating Frequently
February 9, 2016
Question

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

  • February 9, 2016
  • 1 reply
  • 769 views

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!

This topic has been closed for replies.

1 reply

Willam van Weelden
Willam van Weelden
Inspiring
February 9, 2016

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
jasong23450100Author
Participating Frequently
February 9, 2016

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
jasong23450100Author
Participating Frequently
February 10, 2016

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.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices