I want to make sure that the HTML5 Top Nav online help I create with Flare is not easily stumbled upon by any Internet user, or competitor.
My Online Help users will be using a direct link from the application, to get to the Online Help homepage, without needing to log in.
I'm hearing that I may add this to all master pages, as a way to prevent google from indexing any of the online help I publish:
Is there a recommended way to set up the web server target in preparation for an online help system?
Are there any other methods to make this Online Help system even more hidden (except by intended users)?
We do this for our help by just editing the robots.txt file on the server, which is a bit easier.
You can use the allow and disallow commands with the folder path. http://www.robotstxt.org/faq/prevent.html
The robots.txt directives are nothing else than friendly recommendations. Most of the commercial bots adhere to these directives, but there is nothing in any standard (or law) that requires them to do so.
What can happen is that your users share the link to the help or your competitors target a web crawler at your site. If you offer trial versions of your app to download rest assured that your competitors already did that (potentially in disguise). To believe that the measures you are taking make the online help not be accessible for anyone is, sorry, rather naive.
Anything open to the public is, well, open to the public. What might work is crafting a web app that requires an access token. That access token is dynamically created by a security service (you may have already one in place) and expires after a set time (30 minutes or so) unless the app resets the expiration timeout. When accessing online help the help call passes the topic file name/alias/map ID AND the access token to an app that first checks with security services if that token is still current. If yes, dynamically serve up the web help content using the topic file name/alias/map ID for CSH. This approach will give some acceptable level of security and access control.
Other ideas are installing help locally on the customer's system. If it is a desktop app you either use CHM or serve up help using the file system. In a client/server setting you can also have the server app run a web server if IIS/Apache are not already a requirement. That at least will remove the help out of public access.
Generally, if you do not want the public to know then do not publish the content, otherwise consider it public knowledge. If that is not an option either add or piggyback help on to an NDA. That at least gives some legal leverage in case you can pinpoint a leak.
I would not restrict access to the help at all. If competitors want to look at it, fine. If they can only excel by copying you things are not that bad. In some markets that may not be as easy. In that case, do not add that info to the help and provide it on an as needed basis under NDA.
RamonS wrote:The robots.txt directives are nothing else than friendly recommendations. Most of the commercial bots adhere to these directives, but there is nothing in any standard (or law) that requires them to do so.
What can happen is that your users share the link to the help or your competitors target a web crawler at your site. If you offer trial versions of your app to download rest assured that your competitors already did that (potentially in disguise). To believe that the measures you are taking make the online help not be accessible for anyone is, sorry, rather naive.
Anything open to the public is, well, open to the public. What might work is crafting a web app that requires an access token. That access token is dynamically created by a security service (you may have already one in place) and expires after a set time (30 minutes or so) unless the app resets the expiration timeout. When accessing online help the help call passes the topic file name/alias/map ID AND the access token to an app that first checks with security services if that token is still current. If yes, dynamically serve up the web help content using the topic file name/alias/map ID for CSH. This approach will give some acceptable level of security and access control.
Other ideas are installing help locally on the customer's system. If it is a desktop app you either use CHM or serve up help using the file system. In a client/server setting you can also have the server app run a web server if IIS/Apache are not already a requirement. That at least will remove the help out of public access.
Generally, if you do not want the public to know then do not publish the content, otherwise consider it public knowledge. If that is not an option either add or piggyback help on to an NDA. That at least gives some legal leverage in case you can pinpoint a leak.
I would not restrict access to the help at all. If competitors want to look at it, fine. If they can only excel by copying you things are not that bad. In some markets that may not be as easy. In that case, do not add that info to the help and provide it on an as needed basis under NDA.
Hey, great feedback! I agree, although sometimes it's hard to get an entire team to believe open access is just fine.
You mentioned "you can also have the server app run a web server if IIS/Apache are not already a requirement" - I'm not in IT, but I'd have to describe that option to someone. Are there any tips for configuration or setup you'd have?
You are only serving up a simple website, so IIS with standard configuration will be fine. Dropping the files in inetpub\wwwroot ought to do it. For Apache I use XAMPP from ApacheFriends. You can turn off all the non Apache parts since you only need the web server. See also https://httpd.apache.org/docs/current/p ... .html#down
Both IIS and Apache are rather bulky, I know there are a few other lightweight web servers available that may be easier to deploy. I'm sure your web search skills are as good as mine, if not better.