Can DotNet Help pull its topic files from a server?

[itauthor]

I'm looking for a way of providing server-based online help and I'm hoping Madcap DotNet Help might be the answer.

The obvious solution for server-based help would be WebHelp, but the requirement for customers to run a Web server is an additional installation/maintenance overhead we'd rather avoid. We can't host the help ourselves because the end users won't always have internet access. For reasons of security, the help must be server-based and mustn't leave behind help topic files on the client PC.

The application I'm documenting is a client/server system. The desktop software connects to a server within a secure environment to pull down data and elements of the application. So it would make sense for the help also to pull down topics from the same server.

My question is:
Can DotNet Help be configured (or reprogrammed using the SDK) so that it fetches its topic files from a network location, rather than from a local directory relative to the location of the .mchelp file?


Any help/advice/suggestions would be much appreciated.

Thanks in advance
Alistair Christie
http://www.itauthor.com

[RamonS]

Welcome to the forums!

For reasons of security, the help must be server-based and mustn't leave behind help topic files on the client PC.

Is that the only reason for going server based? If yes, how is the client supposed to display the content? As far as I know there is no client / server protocol for displaying files in a browser without first downloading the content to the client and then displaying it. So the topic will end up on the client machine no matter what. Sure, it can be cleaned up afterward, but the files will be on client system no matter what and thus can be accessed, copied, and distributed without control. So if the security mandate is really that strict you need to look at other options.

Aside from that, I think it would be quite difficult to show help on the client without trace. What I could think of doing is to write a custom browser component for the application that is capable of displaying WebHelp that was both obfuscated and encrypted. The WebHelp would be local (and WebHelp does not need a server), but in a proprietary format that without having the algorithm and key to read it will be useless. Placing it on a server adds more complexity as you then need to secure both the client and the server.

[KevinDAmery]

I'm having a hard time figuring out how you're intending to have a server-based help system without requiring the customer to run a web server. The help has to run on something....

The application I'm documenting is a client/server system. The desktop software connects to a server within a secure environment to pull down data and elements of the application. So it would make sense for the help also to pull down topics from the same server.

What kind of secure environment? Is this a remote desktop session or something else? If it's a remote desktop session, I've had success using CHM as the help format. The CHM runs on the server the same as the application does, and the end user just sees a bitmap stream of what's on the session's desktop.

[itauthor]

Thanks for commenting guys. I think I wasn't being very clear.

The security issue is one reason we're looking to put the help content server side if we can. This is because some of our customers use shared computers from which users with different privileges should be able to log in and see different help depending on the parts of the system they can access. We don't want to have to install a superset of all .chm files used by all users of that computer, allowing users to browse the local application directory and open, or uncompile, .chm files for help they shouldn't have access to.

Typically customers like this will have desktop environments where temp directories and caches are cleared on logout, but we don't want to install help files in such locations, requiring these to be reinstalled each time the user loads our application or calls the help for the first time in a session (e.g. via ClickOnce, or possibly AIR). Anything that makes users have to wait to get help is a bad idea.

The other reason for wanting to keep the help content server side is that we have customers who want regularly updated help, but who have to pay every time they have to push changes out to hundreds of client machines - so, for them, client-side help content is expensive to keep up to date.

Web Help is the most obvious solution, but apart from the unwanted requirement that customers must install and maintain a Web server, there is also the security issue of publishing help as Web pages that all users within the organisation can access (e.g. user A has access to module X and its help, user B does not have access to this module, so shouldn't have access to the help - but with Web Help user A can just mail user B the URL).

Kevin asks, "What kind of secure environment?"
What I mean is that, for anyone other than application administrators, there is no access to the server except from within the client-side application. So it seems like a good, secure place to locate the help topic files - although we'd need to allow directory-specific access for the help viewer application.

How I'd imagined client/server help happening - and I guess it depends whether the .NET Help SDK is open enough to allow this, or there's some other way of working it - would be:
* we install the Madcap .NET Help redistributable on all client machines when we install our application
* when a user logs in to our client, our application downloads a collection of .mchelp files to a temp location on the client (it already does this for other files and the .mchelp files are nice and small)
* when a user clicks a Help button our client-side app calls the appropriate .mchelp file
* the .mchelp file launches the client-side Help viewer application
* the Help viewer loads its content files from the server

Of course this may all be pie in the sky.

I'd be very interested to hear if anyone has done anything like this with .NET Help, or if anyone can think of a better way of running a help viewer locally on the client, pulling the topic files from the server as needed by the help viewer, but not storing them in any permanent way on the client.

Thanks

Alistair Christie
http://www.itauthor.com

[RamonS]

How I'd imagined client/server help happening - and I guess it depends whether the .NET Help SDK is open enough to allow this, or there's some other way of working it - would be:
* we install the Madcap .NET Help redistributable on all client machines when we install our application
* when a user logs in to our client, our application downloads a collection of .mchelp files to a temp location on the client (it already does this for other files and the .mchelp files are nice and small)
* when a user clicks a Help button our client-side app calls the appropriate .mchelp file
* the .mchelp file launches the client-side Help viewer application
* the Help viewer loads its content files from the server

Yes, but that is absolutely in way different than what a web client (speak browser) does. Especially the last point negates the plan of keeping everything only on the server. You have to download the content in order to display it on the client. You really have to worry about three things then:
- securing the server (which is kinda easy)
- securing the data transfer (after all, anyone capable of running WireShark could capture the packets), so use at least SSL or something better
- securing and ideally destroying the content downloaded to the client after use

Given the mandate to have it updated in one spot (for charge, which doesn't matter here really, but why on earth would you want your customers pay for the help file?? Having them call your support costs them and you way more money) you are looking most likely at WebHelp. Using DotNetHelp doesn't do anything. The content files are still plain simple HTML files and you'd need some service that serves up the .mchelp files. So you are looking at (T)FTP, file shares (oh yes, very secure!), an RPC/DCOM solution (don't do it!), or yet again at the easiest of all: a web server.

Does the application contain any server components such as a central database or an application server? If yes, then the customers already need to maintain some sort of server box. Just for ha-has go to http://www.apachefriends.org/en/xampp-windows.html and download XAMPP. Run the installer and see the magic unfold. Within a matter of minutes you get a fully configured web server, an (enterprise class) SQL Server, an FTP Server, and with some tinkering even a mail server, plus the most impressive server side scripting language PHP. XAMPP is just to illustrate how easy it is to package and deploy Apache, the web server application that runs 2/3rd of the WWW. So installing a web server is gosh darn simple...unless you deal with IIS, which is for no purpose whatsoever gosh darn difficult, but it has a purdy admin console. There are also other much more lightweight web server applications. I could rattle some names down, but I never used any of them.

Leaves the issue of securing the content. The problem here is that you need to come up with a clever way to remove the temporary files dropped through the help requests. One way would be to delete the temporary files upon logout from the application. Or the option I proposed earlier to obfuscate and encrypt the files, download those, and decode them using a special browser, which obviously cannot open anything from the file system and also does not support drap'n'drop so that even if left over files are found an unauthorized (or basically any) user cannot open them.

That would get your security to be as good as the user. Ideally, you want to prevent printing as well and taking screenshots (redirect PrintScreen and ALT+PrintScreen to do nothing). With that the only means to access the restricted content is to either have someone walk away while logged in, have someone pass credentials, or have someone guess user names and passwords (you really should look at biometric verification as well such as hand geometry readers or finger print scanners, passwords alone are just not secure enough).

I was faced with this type of paranoia several times and in the end doing all that for securing help content never panned out for us or the customers. What we rather did is reduce the help content to a bare minimum and provide specialized training instead, for which to charge dearly never was a problem. Still, doesn't address the security aspect in the best way, but in our cases it was more that the customers were concerned about the security of their data than we were concerned about the security of our stuff. Especially now when cheap virtualization tools can virtualize physical systems within a matter of minutes you have no control over anything after leaving the customer's site.

If there really is something that would be absolutely disastrous to fall into false hands, then don't even publish it. Otherwise it will get copied and distributed, even if it is via handwritten notes and a good ol' copy machine. Who am I kidding? Digital cameras are much better for that. Comes with any decent cell phone these days.
What I'm getting at is that you really should take several steps back and really investigate deeply if this form of protection is necessary. Is the extra level of paranoia worth the trouble?

[Robotman]

They call me "the Simon Cowell of the Flare Forums"....

Really?

Good post that. Learnt a lot.

[RamonS]

Yea, a MadCap support group member cooked that one up and I found it quite an honor to be recognized like that for straight talk...which sometimes ruffles some feathers.

[itauthor]

Ramon - you make a lot of interesting points, thanks.

Yes, there are a variety of Web servers (from mini ones to full blown, all singing & dancing ones) that we could require customers to use, or just bundle, distribute and run on a non-standard port. This looks increasingly like the way we'll have to go. Web Help would be my preference because:
* it offers all the functionality end users need
* end users are used to being zapped away to a browser when they click for Help these days
* I'm comfortable producing WebHelp.
However, there is a feeling from certain quarters of: "oh, no - if we need a Web server then that's just another thing the testers need to test, the Professional Services guys need to install/configure, the customer admins need to maintain and the Support guys need to support."

If client/server .NET Help is a non-starter and we have to use Web Help then what we may have to do is display it in a .NET browser component within our application, so that users don't get to see a URL they can pass on to others. There are levels upon levels of security issues, as you suggest, and we can only go so far into that, but preventing just anyone getting a URL and browsing around *all* the help is one we'd need to do something about. We leave it to our customers to prevent screen capture (because some of them want it), and there's nothing we can do about photographing the screen, copying information using good old pencil & paper, remembering stuff & passing it on verbally ...

Incidentally, you asked "why on earth would you want your customers pay for the help file?" We don't. Most of our customers are on support contracts so they don't pay extra for updates. The cost I was referring to was from 3rd party infrastructure support companies who typically handle making any sort of change to client machines for our large customers. We include in our existing .chm-based merged help system the facility for customers to drop in their own customer-specific .chms that provide help topics for forms etc within our application that the customers have changed or added themselves. However, for our bigger customers, they have to pay their 3rd party infrastructure support company every time - as a result of them making a configuration change - they update the help and want to roll out the update to all the client machines. They also have to book this work in advance and it can take several weeks before it gets done. As a result - understandably - these customers would prefer the help to be on the server where they could update it day to day without any charge from the 3rd party and in a way that would make it immediately available to end users.

Anyhow, thanks again for your input. It looks like Madcap DotNet Help is not going to work for us if the help viewer can't go get its content off a server.

Alistair Christie
http://www.itauthor.com

[RamonS]

However, there is a feeling from certain quarters of: "oh, no - if we need a Web server then that's just another thing the testers need to test, the Professional Services guys need to install/configure, the customer admins need to maintain and the Support guys need to support."

Huh? QA doesn't do a full system test of all Windows versions and all variations of the DotNet runtime either. Or does QA test the CHM Viewer, IE, or the hardware itself (why stop at the software level)? Most applications use third party components that are assumed as working as designed. So in this case using a web server that was selected through apply reasonable process doesn't need to to be tested. Of course, what does need to be tested is the deployment and function of the help system (content and application). QA should take the approach of testing to the extent that is reasonable and customary. Especially the "reasonable" mandate comes to play here. I am very sure that Microsoft will not do anything about the CHM viewer or IE just because some QA team found a bug. Besides that, more and new functionality is to be added one way or the other, so why have the unreasonable expectation that QA can get away with not testing that?

Thanks for the clarification on the help charges. So it is not that your company charges for help to be provided, but the expense comes for deploying and maintaining the help files on the client machines...which should be quite easy to do with login scripts that pull the file from a network share and plop it in the designated folder on the client box. I wonder how much a service company could charge for that? 40$ for the hour that it takes the IT admin to write the few lines of script? Besides that, given that the customers use Windows clients, they do exactly the same thing on every Patch Tuesday (or shortly after). Do they complain to Microsoft that pushing bug fixes to all the clients is too expensive? I wish they would. I know we all would like to be able to fix the customer, but I guess with that we just have to deal with the different metrics applied to the same thing.