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.


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.


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?

  • 9
    Curious, is something going to be placed on whatever serves up the restricted URLs to check that the user has access? Security in just the UI is not security.
    – casperOne
    Commented Jan 30, 2012 at 17:40
  • 18
    @Spiral13: Please go back to your old questions and accept answers by clicking the green checkmark next to what you believe to be the best answer. Commented Jan 30, 2012 at 18:42
  • This topic has been covered many times from various angles. Try browsing questions with the disable tag. Commented Jan 30, 2012 at 19:25
  • What happens if your user knows the url and enter it in the browser ? Users are talking to each others...
    – Luc M
    Commented Jan 30, 2012 at 21:41
  • just do not display non-accessed links. display the current user functionality only
    – igor
    Commented Jan 31, 2012 at 23:42

10 Answers 10

  • 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.
  • 10
    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. Commented Jan 30, 2012 at 14:23
  • 10
    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. Commented Jan 30, 2012 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. Commented Jan 30, 2012 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. Commented Jan 30, 2012 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.
    – Svish
    Commented Jan 31, 2012 at 13:01

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?

    3 links, followed by an inactive 4th which has a padlock icon

  • 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.
  • 4
    +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.
    – user606723
    Commented Jan 30, 2012 at 16:30
  • 6
    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" Commented Jan 30, 2012 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".
    – Riduidel
    Commented Jan 31, 2012 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. Commented Jan 31, 2012 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.
    – Zelda
    Commented Jan 31, 2012 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:

enter image description here

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.

  • 5
    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.
    – LarsH
    Commented Jan 30, 2012 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
    Commented Jan 30, 2012 at 18:49
  • *desired..I really need to watch my spelling
    – Mervin
    Commented Jan 30, 2012 at 19:06
  • 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.
    – LarsH
    Commented Jan 30, 2012 at 21:30
  • Thats true ,we just wanted to ensure there was no dead end
    – Mervin
    Commented Jan 30, 2012 at 21:31

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.



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.

  • 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. Commented Jan 30, 2012 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.
    – LarsH
    Commented Jan 30, 2012 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. Commented Feb 1, 2012 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.
    – LarsH
    Commented Feb 1, 2012 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. Commented Feb 1, 2012 at 23:46

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


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.


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.
  • 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. Commented Jan 30, 2012 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
    – user606723
    Commented Jan 30, 2012 at 16:28
  • 3
    No, I'm afraid they're not the same. It's possible to have something that's harmless and useless. Commented Jan 30, 2012 at 16:29
  • 1
    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. Commented Jan 30, 2012 at 16:41
  • 1
    and how is "potentially creates noise and distraction" not harmful...?
    – user606723
    Commented Jan 30, 2012 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.

  • 4
    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.
    – corvec
    Commented Jan 30, 2012 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 jimbob
    Commented Jan 30, 2012 at 19:45
if (is_loggedin())
   echo "<a href=\"destination\"">Click</a>";
   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.

  • 2
    Hi yaswanthraj, this isn't a site for programmers, so code is not a very useful answer.
    – Rahul
    Commented Jan 31, 2012 at 17:41
  • oh sorry! now i understand ! am new here! thanks!!
    – royalraj26
    Commented Jan 31, 2012 at 17:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.