I want to host my help files on our company server. I've almost got a green light, except for one thing: the company does not want people other than our software users to be able to find the help online.
Does anyone else have this problem? What have you done to keep the help hosted on a Web server but hidden except for authorized users (without having them log into something). Did you place some sort of authentication key with the software that was recognized by the Web server? Did you take a different route?
I'd appreciate any suggestions about ways to secure the help from the prying eyes of competitors while still providing seamless access to our users!
Security (authentication) for Webhelp
Security (authentication) for Webhelp
Victoria Clarke
-
RamonS
- Senior Propellus Maximus
- Posts: 4293
- Joined: Thu Feb 02, 2006 9:29 am
- Location: The Electric City
Re: Security (authentication) for Webhelp
Yes, I ran into the same problem where people don't get that anything on a web server can be accessed, but it can be made more difficult for the casual user. The easiest way is to use the authentication that is build into web servers, speak the .htaccess and .htpasswd files.
One other way is to use a gateway application, for example a PHP script that checks logins against a database and then pulls files from the local file system. In that case you do not even have to put the help files into the htdocs folder. As long as the script runs under an account that can access the file location you can get to it. That means that there is no other way to get to any of the files other than through the script. The problem here is to pass on all files that are needed and doing that quickly. That way you can also track license keys and IPs, which allows checking if the same license is used at the same time from five different networks.
But if the powers in charge are that paranoid, don't even put it on a web server. I really can't think of any reason why one would want to restrict access to the help in such a way, but there may be valid reasons that I just don't know.
One other way is to use a gateway application, for example a PHP script that checks logins against a database and then pulls files from the local file system. In that case you do not even have to put the help files into the htdocs folder. As long as the script runs under an account that can access the file location you can get to it. That means that there is no other way to get to any of the files other than through the script. The problem here is to pass on all files that are needed and doing that quickly. That way you can also track license keys and IPs, which allows checking if the same license is used at the same time from five different networks.
But if the powers in charge are that paranoid, don't even put it on a web server. I really can't think of any reason why one would want to restrict access to the help in such a way, but there may be valid reasons that I just don't know.
New Book: Creating user-friendly Online Help
Paperback http://www.amazon.com/dp/1449952038/ or https://www.createspace.com/3416509
eBook http://www.amazon.com/dp/B005XB9E3U

Paperback http://www.amazon.com/dp/1449952038/ or https://www.createspace.com/3416509
eBook http://www.amazon.com/dp/B005XB9E3U
-
KevinDAmery
- Propellus Maximus
- Posts: 1985
- Joined: Tue Jan 23, 2007 8:18 am
- Location: Darn, I knew I was around here somewhere...
Re: Security (authentication) for Webhelp
The only reason I've encountered is to try to prevent people from reverse engineering your app. This isn't much concern for software with a wide distribution, but in cases where a company is basically providing consulting services and using proprietary software to deliver those services, it can be a major concern. You don't mind your customers reading it, of course, but you don't want your competitors getting an idea how you're delivering your solutions.
Until next time....

Kevin Amery
Certified MAD for Flare
Kevin Amery
Certified MAD for Flare
Re: Security (authentication) for Webhelp
Do you users access your software off your servers as well, or do they run it from their local computers? If it's the latter, then the most secure thing is to not host the help on your servers at all but to bundle it and install it with your software so that it runs from the end user's computer.
Lisa
Eagles may soar, but weasels aren't sucked into jet engines.
Warning! Loose nut behind the keyboard.
Re: Security (authentication) for Webhelp
They run the software from their local computers, but they access data via an online service, so we know they have to be connected to an Internet. I wanted to host it via the Web service to enable me to add updated information, fix errors (if discovered), provide later information (if it wasn't on time for release), provide workflows (in the case where there is a particular section of the software being asked about a lot to support), and to install google analytics for internal analysis.
Tinker is right - we're not a mass distribution software house. We're developing some cutting edge technologies. However, a user could purchase a license and gain access to both the software and the help, but that could be cost prohibitive - or at the very least - inconvenient.
We don't want to "give away" the information in the help to anyone casually browing online. Sigh. Security - hey.
Tinker is right - we're not a mass distribution software house. We're developing some cutting edge technologies. However, a user could purchase a license and gain access to both the software and the help, but that could be cost prohibitive - or at the very least - inconvenient.
We don't want to "give away" the information in the help to anyone casually browing online. Sigh. Security - hey.
Victoria Clarke
Re: Security (authentication) for Webhelp
At that point you have to do a benefits analysis as to which way to go. Do you host it from your server so you can easily update the help and get stats (and perhaps use Feedback Server), knowing however that you'll need to set up some type of restricted access login so that only registered users can access the help? (And users don't like to have to login to get stuff.) Or, do you install it along with your software on the user's computer (with MOTW enabled, BTW) and set up some type of function to update the help when changes are made? Which users may or may not install as often as you want, unless you push the updates. You can still use Feedback Server to get some feedback, I think, although you'd have to double-check that since I don't use that product.
You might also want to check out the SDK for Flare, which would allow you to link DotNet Help to your .NET app, if your software is designed in .NET. I think the SDK gives you the option to "embed" the help in your application. So you could theoretically set up it to only allow the help to be accessible when the application is running, and it still pull the help from your web server. Of course, that requires an active Internet connection all the time -- if the Internet is down or if they're using your app in a location where they don't have Internet access, then they can't use the help. Which is another factor in the benefits analysis.
You might also want to check out the SDK for Flare, which would allow you to link DotNet Help to your .NET app, if your software is designed in .NET. I think the SDK gives you the option to "embed" the help in your application. So you could theoretically set up it to only allow the help to be accessible when the application is running, and it still pull the help from your web server. Of course, that requires an active Internet connection all the time -- if the Internet is down or if they're using your app in a location where they don't have Internet access, then they can't use the help. Which is another factor in the benefits analysis.
Lisa
Eagles may soar, but weasels aren't sucked into jet engines.
Warning! Loose nut behind the keyboard.
Re: Security (authentication) for Webhelp
I'm guessing you're making WebHelp and that they currently access the help via a browser?
One possible solution is for your software to launch the help in its own custom window (i.e. a window with a browser component, displaying your online help), rather than opening it in a standard browser window. As your software controls the window displaying the help, you can stop people seeing the address where the page is hosted (also disable the right-click menu). It's not hard to do either, it's a pretty easy job for a developer.
One possible solution is for your software to launch the help in its own custom window (i.e. a window with a browser component, displaying your online help), rather than opening it in a standard browser window. As your software controls the window displaying the help, you can stop people seeing the address where the page is hosted (also disable the right-click menu). It's not hard to do either, it's a pretty easy job for a developer.