Can topics be password protected?

[sanjsrik]

Almost knowing the answer is no as most of the questions I'm asking is no,

<rant>
while Flare has come a long way, there are many things that I'm finding are a real day-to-day pain:

• variables are very frustrating to use, either they ALL pop-up as you are typing or the wrong ones pop-up and force you to stop typing, position your cursor somewhere else, reposition it where the cursor just was and voila, ALL the variables are restored
• Git integration. So, I count myself lucky that this week hasn't seen some odd message about files not being able to merge into the master branch. I only have a master branch shared between myself and the team, we all contribute, yet, when there are conflicts we NEVER see the conflict screen, it says (paraphrasing) "resolve the messages before merging", yet, there IS no conflict screen ever displayed
• no true editor when working with skins (LOTS of customization of the source .js files in Flare, LOTS), just to get the look and feel to be as we want, still can't move the search toolbar when using the left-hand navigation to show up in the topic, please, Madcap give us a real skin editor

</rant>

I have a single app, that must serve four types of users including admin users, yet, I am told I have direct each type of user to four different URLs because I can't use any rights management out of Flare to only show certain topics.
So, the question is, can I password protect certain topics or am I looking at "yes, but... you have to use a third-party javascript or application"?

**sigh**

[NorthEast]

Well, you already know that there's nothing built-in to Flare to handle this, but I don't think there's a generic answer either - it's going to be very specific to your situation.

First thing I would do is to ask my dev team how to do this - they write the app, they know how its authorisation works, and they presumably know the best method(s) to implement that authorisation to restrict access to certain web pages.

[MattyQ]

So, the question is, can I password protect certain topics or am I looking at "yes, but... you have to use a third-party javascript or application"?

To memory, you were looking for a way to do this via a website?

Best practice, security is really the job of the web server, not of Flare. You don't, for example, build a website using Adobe Dreamweaver and, in that context, create password protection for content (well, unless you want it to be terribly insecure, or you're hooking into some existing permissions system).

In this case (I'm making some organizational assumptions) you'd give a list of pages or paths to one of the administrators of the web server, and specify that you want them restricted by a login. The server would handle that before ever serving any of the content. Like, generally, if someone says, "This needs to be protected!" the best answer is, "That's for somebody else to handle!" (as painful an answer as that can be).

That said, there's a ton of ways you can try to implement a facsimile of password protection by adding code to your project. In the broad spectrum of these cases, it won't be real security, and there will be trivial ways to circumvent it. If you want real security, you need to make sure that content never gets to the user.

[RamonS]

It reminds me of this thread
viewtopic.php?f=13&t=26766

While I do not dismiss the desire to limit users to only see what they need to see going the password way in in my opinion the wrong approach. You could add JavaScript that requests authentication and a token from a security service, you could include a PHP script or the like that runs on the web server to do the same task, there may be other options, but they all are add-ons and essentially outside of Flare. Flare creates static web pages that upon request get served up.

One approach would be to use conditions and craft different output for each user level as it was suggested. That being a viable option depends on how the access levels are structured. If they are strictly hierarchical with a higher level getting access to more content then using conditions with four different outputs will get you where you need to be the fastest.
It gets tricky when the access levels add feature modules and a user can have any combination of these modules. In that case you'd need to create output for every possible combination and that becomes unmanageable quickly, especially when another set of permissions is added later.

I suggest to take a few steps back and evaluate again the reasons for wanting to restrict access to content. Is it solely because user who do not have access to all features need not to be confused with help content that does not apply? If that is the sole motivation then clearly separate that content out (stuff it into its own top level book in the ToC) and build one output for all. I am sure users are smart enough to understand that this part is for a different access level. They may find those topics in full text search, but for that case a small note below the topics header like "Admin only" or something like that is probably sufficient.

If the motivation is to prevent normal users to know about admin features then I'd ignore that as a tech writer. The app ought to have all the security in place to prevent a normal user from accessing any of these features. Means them knowing about it does not translate to them being able to use admin features. If anything, it makes them a more informed user of the app.

In the end do what the product owner / boss wants you to do (you don't really have a choice here). If it has to be a full fledged access control that goes back to the app's user store then it will need code of some sort, which is (IMHO clearly) outside of what Flare is designed to do.

[Paul_N]

This is an interesting topic for me too. I'm producing HTML5 help for a web based application and may want to restrict access to the administrator help pages from users not logged in as an administrator.

It looks like it may be something that the devs have to implement, else we may just have a policy of letting all users have access to all the help.

Any comments or observations are welcome.

[RamonS]

Give all users access to all of the help. The security needs to be implemented in the application, not documentation.

[LTinker68]

Give all users access to all of the help. The security needs to be implemented in the application, not documentation.

Normally I'd agree, but the example in the previous post is valid. There could be content you don't want end users to know about but that administrators do need access to. In this case, honestly, I'd probably do separate projects, one for end users and one for admins and publish to different locations, then you can use server-side code or Active Directory to restrict who can get to the admin help. (I'd probably do AD before server-side.) You could always have the end user version also publish to the admin location, if your admins don't want to jump between the two help locations.

[RamonS]

Admins are not end users? Security through obscurity never works...besides that, the security needs to be in app, not the help. I think it only makes for a better informed user when they know what an admin can do. It is up to the application security to prevent them from doing it when they are not admin.