I've been asked to work on a system message on an intranet where by there are various URLs (linking to lists of content) that have permission rights attached to them, so only certain users have access to the content.

Currently it's spec'ed so that if a user without permission clicks on one of these URLs a message appears which says 'You do not have Permission to view this content'.

I'm wondering is there a better way to handle this?

I was thinking of maybe disabling the links (the user has no permission for) altogether.

There are pro's/cons here.

Pro:

It will stop users clicking on said link and receiving a message which may leave them feeling stupid and maybe annoyed they don't have permission.

Con:

Maybe the user needs to/would like to be aware that this content exists (so needs to be recognizable as a URL) even if he/she cannot view it.

Yes. Nothing would be more annoying than having to randomly click on things and deal with message boxes just to find out if I have permission or not.
–
Kris HarperJan 30 '12 at 14:23

9

I greatly prefer the second approach - Imagine a new supervisor trying to approve a timesheet and dealing with instructions that refer to missing links because the roles database hasn't been updated yet.
–
Steve JacksonJan 30 '12 at 15:33

2

Note that this current website violates the 2nd rule, like arrow up and down are shown to non-logged-in users, and it's quite annoying.
–
smackfuJan 30 '12 at 15:38

5

@smackfu; in the context of this site, I believe the arrows are shown to entice users into either signing up or signing in - potentially increasing conversions.
–
codeintheholeJan 30 '12 at 16:28

2

@LarsH: The difference, I would say, lies in being told you need a visa when you buy the ticket, versus when you're on your way off the airplane, in Australia.
–
SvishJan 31 '12 at 13:01

+1, but I would still make it a black hyperlink, linking to information on where to obtain such access if you feel you need it.
–
user606723Jan 30 '12 at 16:30

5

Fair enough! That could indeed be a welcome addition. One could also include it in the tooltip. Say, the tooltip contains the following text: "You do not have permission to view this page. More information"
–
Nick van der WildtJan 30 '12 at 16:45

@NickvanderWildt I would have better indicating in the tooltip the reason of the block, complete with "click on padlock to request access to this content".
–
RiduidelJan 31 '12 at 8:37

1

@user606723, note that if you change the color of the link as the only difference, people using certain accessibilitiy affordances (that change text colors) won't see that. Better to annotate the link (text, icon) than to just change its color.
–
Monica CellioJan 31 '12 at 15:54

@user606723 ...but why? Why take me on a wild goose chase and trick me into clicking a link instead of not making a fake link? That just means I have to click, then read a page, then click back and find where I am again instead of just seeing not a link, with a tooltip explaining why.
–
Ben Brocka♦Jan 31 '12 at 19:31

I worked on a very similar project to yours where users could only view the content based upon their access permissions. Though the initial reaction from the stakeholders was to just show content, to which the users had access, there was also feedback that users might have wanted access to specific content. Thus, hiding unauthorized content would have lead to the impression that it didn't exist. In our project, the content was supposed to be surfaced as search result links as shown below:

However, to highlight the content, which was there but to which the users didn't have access, we just replaced the Preview | View in browser with a request access link, which would launch a request form. Then, the user would have to specify their business need and info would be sent to the content owner via email.

The advantage of this process is that you are allowing potential stakeholders access as long as they can provide a justification. However, the apparent disadvantage is that the content owner can end up with a lot of requests if the content is very desirable.

Bravo! Not only letting users know (1) the content exists, and (2) the nature of the reason they can't access it, but even (3) the next step toward getting access.
–
LarsHJan 30 '12 at 17:38

@LarsH ,technically we didnt tell them the reason why they didnt have access (since the reasons could be so many) ,the request access link was just a visual indicator that they didnt have access but could request access if they desied
–
Mervin JohnsinghJan 30 '12 at 18:49

understood. But merely indicating that they didn't have access (but could request it) is leaps and bounds beyond withholding the information that the user is in the right place to find a link to the resource.
–
LarsHJan 30 '12 at 21:30

Thats true ,we just wanted to ensure there was no dead end
–
Mervin JohnsinghJan 30 '12 at 21:31

If a user has no rights to see something, security dictates that they should not even be made aware of its existence.

Is a user does have rights to see something, (s)he should always see it, but it may be disabled if circumstances require. For example a service / printer / whatever not being available; or a form still being in an invalid state for submitting.

I've updated my answer (a) because I realized that the OP's suggestion ("disabling" rather than "hiding" links) was quite different from the rule we faced; and (b) to say that the big problem we faced was not because we were told links should be hidden in certain situations, but because of a blind across-the-board rule.

We went through a related issue with our intranet several years ago. We had a leader who was sold on the concept of "no access, no link," and it was adopted (without much thought about the implications) as a principle for our intranet web applications. This variant included the case where the linked-to item had no data (e.g. a link to a user by ID who is no longer in the system), as well as cases where the logged-in user should not have access to the data. In other words, in this leader's conception, the link should not ever appear if it will not lead to accessible, existing data.

I can see how this practice would appeal to some people who just don't like being told "no." But as a general rule it was a really bad idea.

The biggest problem, which others have already mentioned that it seriously impairs the UX principle of discoverability.

Suppose a help page tells me to click on this and that link. I go to the page but can't find the link. How do I handle this situation?

Did I misunderstand the help, and I'm on the wrong page?

Do I not have permission to access the link? (Knowing about this option requires that I'm already educated about the "no access, no link" principle, which imposes a training requirement on the user population.) If so, is it because I really shouldn't have permission? or because some roles database hasn't been properly updated for me yet?

Is that link not applicable for some reason that is not clear from the help, and therefore has been "helpfully" removed from view?

Does the help page refer to an older (or newer) version of the app, and needs to be updated?

Am I encountering some sort of browser incompatibility issue?

You can see how the confusion and the inability to diagnose the problem can lead to all sorts of frustration. And that's just on the user side. (Not to mention the burden put onto documentation maintainers to try to explain to users that every link might not show up, and how to find out why and what to do about it.)

On the developer side, adhering to this rule imposes a new load.

For every link I emit, I need to consider:

Not only the target app, but also the source app, need to understand the mapping from user identity and roles to permissions based on scope, sensitivity, and other criteria.

This make the target and source apps tightly coupled, either by sharing code for evaluating access criteria, or by not sharing code. In the latter case, the apps can get out of sync, in which case the source app could inadvertently omit links to information that actually should be available to the user!

This makes it a good deal harder to upgrade the source and target apps efficiently and correctly.

Performance is impacted, because databases need to be queried when generating the links on the source page, as well as when verifying access privileges on the target page. If the source and target apps are hosted in different locations, the performance impact can be substantial.

When the source and target pages are in different systems, this means that credentials for accessing the target app's database of roles have to be shared among potentially several different source apps, making it more difficult to keep these credentials synchronized and secure.

When this principle is important, it can be implemented, at significant cost. But it should never be applied as a broad rule.

The principle was never fully implemented in our intranet web sites, because it was impractical. Eventually it was dropped. (And there was great rejoicing.)

I support the compromises suggested, such as not providing a link but providing some indication that there would be a link if the user had access (i.e. "disabling"). However the development costs of this feature can be substantial, and should be weighed against the benefits (vs. clicking on the link and getting an informative error message on the target page). I feel that the benefits are small, but I can see cases where it could be important (e.g. when presenting a long list of links, many of which will lead to "no access" or "not found" errors). It depends on the user's task, and their need for hand-holding.

One situation where I could see a case for completely hiding the information from the user would be if the very existence of a resource is sensitive information. In that case, you're not hiding a link because the user doesn't have permission to access the target data; you're hiding metadata (the existence of the resource) because the user doesn't have permission to access that metadata.

Granted, there is a case for reducing useless or less-useful clutter on the screen so that the useful stuff is easier to find. Especially if the links that lead to nothing useful are likely to be numerous and frequent. But hiding is not the only way to mitigate clutter... that can be accomplished by making "doomed" links smaller, grayed out, disabled, or moving them to the bottom of a page. Omitting one of two links on an uncrowded page is not reducing clutter, it's blindfolding the user.

I think you're making some very specific assumptions about the how the links in question will be utilised. It might be un-constructive to answer the question based on a false premise.
–
codeintheholeJan 30 '12 at 19:13

@codeinthehole: You may be right. I've tried to make my assumptions explicit (aside from the situation described in the question) but I may have missed some. Please feel free to point them out and help clarify.
–
LarsHJan 30 '12 at 21:32

2

This is NOT the right answer. A usability concern should not be hamstrung from the aspect of "it's to hard for our poor developers to code." This kind of access control is accomplished without destroying the DB and performance every day by engineers who understand how to do it properly. Your answer is full of "its hard for us" so lets make the user do all the work by leaving links all over the place that they won't know until they click that they don't have access. In some situations it is appropriate to hide the link and in others to disable the link with tool-tip to inform the user why.
–
Chris JanssenFeb 1 '12 at 18:27

@Chris, my answer includes UX reasons, developer costs, and other issues. Developer costs, as always, should be a factor in deciding on features, but I agree they should not be the only factor. However people often don't realize that hidden complexity not only takes extra development time before the first release, it also takes much more effort to maintain correctly, resulting in slower/fewer/buggier updates to the software - which hurts UX. I agree with your last sentence, but I think the 1st case is rare, and there is a 3rd case: enable the link.
–
LarsHFeb 1 '12 at 23:22

1

@LarsH if this was product management forum my response wouldn't be so harsh, but the fact of the matter is this is a ux forum and we should strive to suggest the best user experience, unless given explicit design constraints. I simply disagree that this is the best answer as it suggests don't do UX things that are hard. I think you overstate the developer issues and underestimate the effect that not telling the user they can't do something has on the users experience, trust in the system, and it just wastes their time. Your answer adds to the discussion but is not the best answer.
–
Chris JanssenFeb 1 '12 at 23:46

I think that I would suggest not giving them a link at all, but instead styling text to be similar to the link, while making it easy to discern as being inaccessible. Then, I would have some kind of link next to each non-link with something akin to "tell me why I can't access this content, and what I can do about it". If I wanted to be really proactive about it, I might do a little easily recognizable icon next to non-links where, when the non-link is rolled over, a little tiny tooltip pops up over the icon to indicate that they can learn more about non-links by clicking the icon.

As others have noted, non-accessible pages should both not be linked to, and should also be protected with server-side validation on the page itself to protect against smart users.

If the situation permits, I might have the "what are not-links" page/modal include a form where the user can select from a list of departments and submit a permissions request under certain circumstances (ex: user has high enough permissions that they may be able to get access to more content by contacting Joe Somebody, so the page allows them to do so immediately and easily).

The decision to show partial content should not be based on whether it's harmful to show the content exists; it should be based on whether it's useful to show the content exists.
–
codeintheholeJan 30 '12 at 16:24

@codeinthehole, I would argue those are the same. If it's not useful to show the content exists, then showing that it exists should be considered harmful
–
user606723Jan 30 '12 at 16:28

Because showing elements without taking account of need, potentially creates noise and distraction. Aim to provide your users with clarity and focus to help them achieve specific tasks and goals.
–
codeintheholeJan 30 '12 at 16:41

1

and how is "potentially creates noise and distraction" not harmful...?
–
user606723Jan 30 '12 at 16:42

If you are using easily guessable RESTful URLs (e.g., http://example.com/page/1/) and a user has permissions to see pages 1-3, but not 4, merely not giving the user the option to click a link to get to page 4 is not secure (or changing the link to a JavaScript pop-up).

A skilled attacker can easily enter the missing URL name themselves. You need to make sure that your web server will not serve the forbidden pages to the user without privileges. (And you should check for permissions in a sane way, i.e. that they have logged in to the system and have an unguessable session-token.) You should not check based on the last page they viewed or their IP address (especially if accessing a forbidden section can do some sort of action, like create a user).

Even if your URL is not easily guessable, an attacker may be able to browse user history's, find server logs, eavesdrop on unencrypted http connections, to find the URLs.

Your answer doesn't address the question. The security of the URLs is a different matter than how the User Experience is affected by various means of handling that security with regard to the interface.
–
corvecJan 30 '12 at 18:31

@corvec, I know I didn't contribute to the ux answer; but his question was vague "Is there a better way" than sending the user a message he has no permissions when he clicks a link. I agree not seeing that forbidden content exists (+1) OR seeing it with a link disabled and a lock image (+1) seem like great options. But its critical to mention that access control should not be done by disabling/rerouting links (which seems to be what spiral13 claimed to be doing).
–
dr jimbobJan 30 '12 at 19:45