Refusing a user permission to click a URL

Question

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.

Anyone any ideas on this/seen any similar patterns in use?

Answer 1

• If a user doesn't have permission to access a particular item of content, I would suggest not displaying it at all.

• If the user needs to know that content they don't have access to exists - show them the content in a different form and provide them with a way of enquiring about how to gain access if necessary.

  • Eg. as a content list (rather than semi functional links), with a suggestion about who to contact if they feel access if required.

Answer 2

I'd like to take @lazer's suggestion a step further.

• Why not add a small padlock icon after each of the links the user does not have permission to?

  

• Then, if the user would hover the link, I would show them a tooltip explaining that they don't have permission to view the page contents.

Answer 3

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.

Answer 4

Generally, I would:

• show / hide content based on user rights
• enable / disable content based on availability dependent on everything else.

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.

Answer 5

Updated

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?

1. Did I misunderstand the help, and I'm on the wrong page?
2. 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?
3. Is that link not applicable for some reason that is not clear from the help, and therefore has been "helpfully" removed from view?
4. Does the help page refer to an older (or newer) version of the app, and needs to be updated?
5. 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:

1. 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.
2. 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!
3. This makes it a good deal harder to upgrade the source and target apps efficiently and correctly.
4. 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.
5. 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.

Answer 6

One other way could be to have the link text displayed but not actually linking anywhere if the user does not have permission. For example:

Page 1

Page 2

Page 3

Page 4

Answer 7

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).

For tooltips, I'm fond of TipTip jQuery plugin.

Answer 8

If I were in a situation where certain contents needs to be disallowed, but it's not harmful to inform everyone that such content exists, then I would:

1. Change the color of the disallowed hyperlink to grey.
2. Either keep the popup, or forward them to a page that is more verbose about the content not being allowed, and who they should content if they believe they need this content.

Answer 9

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.

Answer 10

if (is_loggedin())
   echo "<a href=\"destination\"">Click</a>";
else
   echo "Log in to access this link."

That way should work.

If the user is logged in..just echo the link.Else echo the text...as simple as that.