"Some Things MankindUsers are Not Meant To Know"

I am of the opinion that this is not a SF B-movie cliche.

There are some things the ordinary wiki user is not meant to fiddle with.

Summary: Don't show menu items that the user cannot access

Yes, I know PeterThoeny advocates open access, but TWiki's architecture makes a great deal of the configuration visible as regular topics. Lets not argue if this is a flawed design decision or not, it is there and we live with it.

I also realise that TWiki.Org, but its nature, is an exception to what I'm proposing.

I myself and I imagine many others restrict access to key configuration components using the TWikiAdminGroup and TWiki's access control features. All well and good. It is these access control features that begin to make TWiki acceptable in corporate environments.

But many environments also work on a need to know basis. So if you don't have access you shouldn't even know it exists. It is these environments I wish to address the following proposal to.

I've already worked out modification to the PatternSkin view template that hides things like "edit" and "attach" for non authenticated users. I'm proposing we go a step further and make the capability to disable site management topics from teh menus rather than just have the ALLOW = TWikiAdminGroup. The idea is that if a user can't use or access it they don't need to be told about it.

Let me use as an example the WebLeftBar from the TWiki web. It has a section "Admin Maintenance" and an admin tools category. Suppose we want to make those only available to authenticated users. That is we deny it to casual visitors. We can wrap them with

   %IF{"context authenticated" then='<div class="twikiVisible">'
                               else='<div class="twikiInVisible">'}%
        * [[AdminDocumentationCategory][Admin Documentation]]
        * [[AdminToolsCategory][Admin Tools]]
   </div>

I suppose if we were more sophisticated we could even check to see if the authenticated user was in the TWikiAdminGroup.

Just to clarify:

I am not proposing that the baseline TWiki or PatternSkin or WebLeftBar have this change made, just that the CSS capability is there in the baseline and documented for the admins who want to strap down access to match corporate policy.

In many situations there simply isn't a need to know. The application users don't even need to know details of the infrastructure They only need to know that thinks work and that keeping them working is someone's responsibility. Most users are not geeks. Lets not tempt them to play with production systems and inadvertanly vandalise them.

"Security is a chain within the infrastructure and is as secure as its weakest link. It is not a product nor a series of technologies but a process of solutions measured against the business needs of the organization."
Walter S. Kobus Jr., ISSPCS, CISSP, CISM, NSA-IAM
http://www.TESS-LLC.com
Author "Application Security", Handbook of Information Management Security, (Auerbach, 2003)

Arthur has created a number of cookbook topics. Removing the left bar, the top bar or centering the page, or as I've done for one site, removing them all and making the "portal" look quite different are all possible. PeterThoeny has illustrated a couple of portals that are quite different. See TWikiNewsPortal and HomePageNavigation . I've done a similar once for one of my sites, see the attachement.

Finally, there is a very simple and ROI-sensitive reason to hide options (even things like edit) that the user can't use be use of downstream access control limitations. Good user interface design advises not to offer menu options to which the user gets a response "Sorry you're not allowed to do that". Its frustrating and results in calls to the help desk and the concomittant costs and frustrations.

User:       "Why can't I edit?"
Help desk:  "Because you're not logged in"

That is the most common complaint my clients' support report as problem with Wiki.

But IT and policy and BASEL 2 and SarBox and FFIEC won't allow anonymous updates. Hence this capability needs to be supplied so that it can, at the site admins discression, be deployed to fulfil these regualtory requirements. See http://www.ffiec.com and http://www.gao.gov.

TWiki needs this capability in order to have modern corporate acceptance under these constraints. We TWiki-Geeks know it can be done (we pretty much know anyting can be done if we can imagine it), but the ordinary admins who are not as sophisticated as us need to be shown. Arthur's PatternSkin cookbooks in Dakar are womderful. We need more like that! Being able to say "Yes we can do that, we can meet those regulatory requirments with TWiki" is key to its acceptance in many corporate settings.

For effective security, risk must be mitigated at all layers of an organization, from physical, application, networking, social engineering etc. Any weakeness in any layer exposes an organization to risk. I do not see how a single solution can touch all layers. - Lance Spitzner

-- AntonAylward - 01 Jan 2006

For those of us with limited attention spans, could you please summarise the proposed changes?

-- CrawfordCurrie - 03 Jan 2006

-- FranzJosefSilli - 03 Jan 2006

What this boils down to is adding

1. Two (unused) CSS definitions
2. A cookbook page that explains how to use them and where using them might be suitable to comply with corporate policy.

A "would be nice to have" is a mechanism that determined if a user was a member of a group but with low overhead that could be used in the =%IF{}% clauses. Yes I realise it can be done with SpreadSheetplugin but ti represents a serious performance hit if it is to be used in the WebLeftBar.

-- AntonAylward - 03 Jan 2006

twikiVisible is a bit hard: you cannot just set the style of a div to display:block, because it might have been set to display:inline before.

I think you would come a long way with the style display:none;", that is available with the twiki class =twikiHidden:

   %IF{"context authenticated" then='<div>'
                               else='<div class="twikiHidden">'}%
        * [[AdminDocumentationCategory][Admin Documentation]]
        * [[AdminToolsCategory][Admin Tools]]
   </div>

But to make things more generic, you could think of a (new) style twikiRestricted, that can be set to hidden by one skin author, and to grayed out by another:

   %IF{"context authenticated" then='<div>'
                               else='<div class="twikiRestricted">'}%
        * [[AdminDocumentationCategory][Admin Documentation]]
        * [[AdminToolsCategory][Admin Tools]]
   </div>
<style>
.twikiRestricted {display:none;}
</style>

-- ArthurClemens - 05 Jan 2006

So, twikiHidden exists in PatternSkin's layout.css. But you have to be using PatternSkin.

Your example twikiRestricted is the same as PatternSkin's twikiHidden. However twikiGrayText is in PatternSkin's colors.css.

Now, Arthur, do you want to make up a cookbook page for this?

-- AntonAylward - 05 Jan 2006

Its called twikiHidden (with prefix twiki) because it is above skins. Each skin may/should implement its own.

twikiGrayText is not necessary for twikiRestricted, but the same color can be used.

-- ArthurClemens - 05 Jan 2006

Just a personal opinion: I think that whatever the design choosen, it should respect SameUrlSameContent

-- ColasNahaboo - 06 Jan 2006

I added content on SameUrlSameContent also relevant to this topic. I agree strongly with Colas against hiding.

-- KennethLavrsen - 06 Jan 2006