login screen to access Flare online help site

[thawkins]

I have a help site and the company I work for feels that the site should not be available to the general public. Does anyone have any ideas on the best way to make it private?

Is it possible to add a login screen to the site? If so what is the best approach to achieve this?

Many thanks in advance
Tess

[RamonS]

This question comes up every other month and while the question is easy, the answer is not. The technical implementation is fairly easy. Web servers have means to require a user name and password. Apache makes it easy using .htaccess files or better Directory settings in the main config file (see https://httpd.apache.org/docs/current/h ... ccess.html). IIS is a bit more complicated, but these articles might help: https://technet.microsoft.com/en-us/lib ... 10%29.aspx and https://docs.microsoft.com/en-us/iis/ge ... nts-in-iis
Of course, help is just another part of the static web content. If the application already has authentication and authorization in place then developers can stuff the help under that umbrella. That means unless a user is logged in to the application they cannot access the help content.

The real question is what the benefit is to your company and its customers? Typically, the motivation for password protecting help is for restricting access to non-customers and competitors. That is easily circumvented by finding the one customer who has no problem with grabbing all the help content and passing it on. With little technical skill the entire help content can be wrapped into a PDF and shipped to who knows where.
I also assume that the help is currently publicly accessible. The content is already out there and indexed by search engines, downloaded by web archives, and potentially printed in part or in its entirety. Adding password protection now will not make any of that disappear.
Adding a password protection will also negatively impact the user experience. At the time the users need assistance quickly they are forced to enter a user name and password that they may or may not recall. It really is the worst time to ask users for credentials. The fix for that is what I suggested above, wrap the help content into the application if it has a user and access concept. The users will already be logged in by the time they need to access help.
Does management have concerns about some of the help content being used by competitors? If yes, maybe that content should not be in the help file to begin with. Anything served up on the WWW is to be considered public, even with password protection. User names and passwords are easily guessed or cracked, especially when the user name is something like an email address. Proprietary information needs much better protection. Depending on what it is you may want to craft Technical Bulletins that are distributed to users on an as needed basis or not at all. The Technical Bulletins can help support with providing user assistance and reveal only as much detail as necessary in order to satisfy the user. Nevertheless, I think competing with innovation and domain expertise is much more successful long term than depending on obscuring information.
Lastly, the password protection requires significant amounts of overhead. Aside from implementing the technical pieces someone has to assign the passwords (and potentially user names), remove them once a user is no longer eligible, change them when users forget the passwords, and secure and backup the password storage. Someone or something also has to frequently monitor usage patterns, otherwise you cannot find out if someone passed on access to another entity. If users can access the application from anywhere you are facing a tough task because there is no way to tell if the access was legitimate or not. And even if, all you know that someone entered the credentials from an expected place on the web, but you still do not know who that is and if the owner of the credentials knows about that access. Password only or user name and password combo is also 1960s tech. For more effective protection you need two factor authentication with expiring tokens and credentials which makes the entire thing even more complicated and more annoying to users.

While I understand the motivation, password protecting help is the wrong solution to a problem that probably doesn't even exist. If you have something in the help that reveals too much information then remove it and call it done. What might help a bit is adding a directive to the robots.txt file to keep the more popular search engines from indexing your help, but robots.txt directives are only a friendly recommendation, not mandatory to follow. After that change the URL for the help and pass that information on to customers. That, too, is not without risk. Customers may have bookmarked or noted the old URL and get frustrated when they see a 404 instead of a help page.