Requiring user to have our license file to access help content

[Rocky_XYZZY]

On Colum's blog, he references a process by which his team used their product's license file as a way to limit access to RoboServer-hosted help. Specifically, he stated:

"My team and me have had to build a series of hoops and then jump through  them in order to get the documentation into a production environment.  This includes displaying the documentation in a secure browser and with  an application that uses basic authentication to pass (unbeknown to the  end user) a userid and password to display it. The basic premise being  that if you don’t have access an application license you won’t get  access to the documentation."

This sounds like an approach that may be exactly what my team could use. We require a license file for our product (even during its demo period) and requiring a valid license file for one to access the help content would ensure that only authorized users see the help.

Obviously, we would want this process to be as painless and transparent to the customer as possible.

Has anyone done this? Can anyone provide some additonal details about the effort and process required? I'm looking for enough info to take this to development so we can examine the feasibility of doing so and I'd like a somewhat clearer idea of the process before I bring it up for discussion.

Thank you!

[RoboColum_n_]

Hi Rocky.

That was a old blog post and as you no doubt know things move quickly in this wonderful career of ours.

I really should update that post to state what happened in the long run. In short we tested a Java browser (our app is written in Java) that did as I described plus tied down all the usual browser functionality (e.g. visible URL, right click menu, etc.). However, and it was a big however, the browsing history was still recorded on each end user's PC. There was no way that we could find to stop this. Therefore despite all the effort we had gone to, there was nothing to stop anyone from interrogating their browser history and accessing the help via one of the URLs recorded there.

In the end we decided to ignore the Java browser solution and allow the users to access to help in their default browser. We even sacrifaced the user authentication on the grounds that it required a lot of coding effort and did not offer us the security we originally required.

---

The RoboColum(n)

@robocolumn

Colum McAndrew

[Rocky_XYZZY]

Thank you very much for your response!

I notice that in the Admin tool for RoboServer 9 I can create a protected area, upload a help system to that area, and define users who have access, even limiting users solely to read-only access of the help content.

The biggest problem with this is that it's not seamless. It requires that the users authenticate themselves to the help server and that we, behind the scenes, generate, distribute, and maintain user credentials for each user. I guess this is where the LDAP or database solution that the RoboServer manual discusses comes into play?

If we were to magically create some sort of mechanism by which we generated credentials based upon the user's unique license file and automatically authenticated the user with roboserver when the user logged on, it appears that would satisfy the "seamless" requirement and would conceivably still thwart the casual user who attempts to distribute just a URL. This, of course, doesn't stop an authorized user from intentionally discovering and discosing login credentials to an unauthorized user, but that's an entirely different discussion.

With this logic, I'm guessing that the process would be something like: have our license server automatically generate user authentication data for each license generated, communicate credentials to the user's machine as part of the license file, and also communicate that information to the RoboHelp LDAP server or database. Then, when the users clicks F1, the magic somehow happens and the user's browser automatically authenticates itself to the RoboHelp server, which received the credential data  from the license server. When the license file expires, the license server can inform the RoboHelp server and the authentication process will then fail.

Does this sound like a reasonable course of action to pursue?