URLをクリックするユーザー権限を拒否する
さまざまなURL（コンテンツのリストへのリンク）があり、アクセス権が付与されているイントラネット上のシステムメッセージを処理するように求められたため、特定のユーザーだけがコンテンツにアクセスできます。
現在のところ、許可なくユーザーがこれらのURLのいずれかをクリックすると、「このコンテンツを表示する権限がありません」というメッセージが表示されるように仕様化されています。
これを処理するより良い方法はありますか？
私はおそらくリンクを完全に無効にすることを考えていました（ユーザーには許可がありません）。
ここには長所/短所があります。
プロ：
それは、ユーザーが上記のリンクをクリックしてメッセージを受信するのを止め、愚かな気持ちになり、許可がないことに腹を立てるかもしれません。
短所：
たぶん、ユーザーは表示できないとしても、このコンテンツが存在すること（したがって、URLとして認識可能である必要があること）を認識する必要があります。
これに関するアイデア、または使用中の同様のパターンを見た人はいますか？
- ユーザーがコンテンツの特定のアイテムにアクセスする権限を持っていない場合は、まったく表示しないをお勧めします。
アクセス権のないコンテンツが存在することをユーザーが知る必要がある場合は、コンテンツを表示します別の形式でとし、必要に応じてアクセス方法を問い合わせる方法を提供します。
- 例えば。コンテンツリストとして（半機能的なリンクではなく）、必要に応じてアクセスできると感じた場合の連絡先についての提案。
@ lazerの提案 をさらに一歩進めたいと思います。
ユーザーがアクセス権を持たない各リンクの後に小さな南京錠のアイコンを追加してみませんか？
![3 links, followed by an inactive 4th which has a padlock icon]()
- 次に、ユーザーがリンクにカーソルを合わせると、ページのコンテンツを表示する権限がないことを説明するツールチップが表示されます。
私はあなたと非常によく似たプロジェクトに取り組みましたが、ユーザーはアクセス許可に基づいてコンテンツを表示することしかできませんでした。利害関係者からの最初の反応は、ユーザーがアクセスできるコンテンツのみを表示することでしたが、ユーザーが特定のコンテンツへのアクセスを望んでいる可能性があるというフィードバックもありました。したがって、許可されていないコンテンツを非表示にすると、そのコンテンツは存在しないかのように見えます。私たちのプロジェクトでは、コンテンツは次のように検索結果リンクとして表示されることになっています。
ただし、そこにはあったがユーザーがアクセスできなかったコンテンツを強調するために、Preview | Browser in Viewをrequest accessリンクに置き換えただけです。リクエストフォームが起動します。次に、ユーザーはビジネスニーズを指定する必要があり、情報はメールでコンテンツ所有者に送信されます。
このプロセスの利点は、正当な理由を提供できる限り、潜在的な利害関係者にアクセスを許可することです。ただし、明らかな欠点は、コンテンツが非常に望ましい場合、コンテンツ所有者が大量のリクエストを送信する可能性があることです。
一般的に、私は：
- ユーザー権限に基づいてコンテンツを表示/非表示
- 他のすべてに依存する可用性に基づいてコンテンツを有効/無効にします。
ユーザーが何かを見る権利がない場合、セキュリティはその存在を知らされるべきではないことを要求します。
ユーザーは何かを表示する権限を持っていますか？（s）常に表示する必要がありますが、必要に応じて無効にすることができます。たとえば、サービス/プリンター/利用できないものは何でも;または、送信するためのフォームがまだ無効な状態です。
更新
OPの提案（リンクを「非表示にする」ではなく「無効にする」）が私たちが直面したルールとはかなり異なることに気付いたので、私は私の回答を更新しました（a）。 （b）私たちが直面した大きな問題は、特定の状況ではリンクを非表示にするように指示されたからではなく、盲目的な全面的なルールのためだったと言います。
数年前にイントラネットで関連する問題を経験しました。 「アクセスなし、リンクなし」のコンセプトで販売されたリーダーがいて、イントラネットWebアプリケーションの原則として（その意味についてはあまり考えられていませんでした）採用されました。このバリアントには、リンク先のアイテムにデータがない場合（システムに存在しないIDによるユーザーへのリンクなど）と、ログインしたユーザーがデータにアクセスできない場合が含まれます。言い換えると、このリーダーの概念では、アクセス可能な既存のデータにリンクしない場合、リンクは表示されません。
このやり方が、「ノー」と言われたくないだけの人々にどのようにアピールするかがわかります。しかし、原則としてそれは本当に悪い考えでした。
最大の問題は、他の人がUXの原則 discoverability を著しく損なうとすでに述べています。
ヘルプページでこれとそのリンクをクリックするように指示されているとします。ページに移動しましたが、リンクが見つかりません。この状況にどのように対処しますか？
- ヘルプを誤解し、間違ったページにいますか？
- リンクにアクセスする権限がありませんか？ （このオプションについて知るには、「アクセスなし、リンクなし」の原則についてすでに教育を受けている必要があります。この原則は、ユーザー集団にトレーニング要件を課します。そうであれば、本当に許可を与えるべきではないためですか？または、一部のロールデータベースがまだ適切に更新されていないためですか？
- そのリンクは、ヘルプから明確ではない何らかの理由で該当しないため、「問題なく」ビューから削除されましたか？
- ヘルプページはアプリの古い（または新しい）バージョンを参照しており、更新する必要がありますか？
- ブラウザに何らかの互換性の問題が発生していますか？
混乱と問題を診断できないことで、あらゆる種類の欲求不満にどのようにつながるかがわかります。そして、それはユーザー側だけです。 （すべてのリンクが表示されない可能性があることをユーザーに説明し、その理由と対処方法を見つける方法をユーザーに説明しようとすることは、ドキュメント管理者にかかる負担は言うまでもありません。）
開発者側では、このルールを順守すると、新しい負荷がかかります。
私が発するすべてのリンクについて、私は考慮する必要があります：
- ターゲットアプリだけでなく、ソースアプリも、スコープ、機密性、およびその他の基準に基づいて、ユーザーIDとロールから権限へのマッピングを理解する必要があります。
- これにより、アクセス基準を評価するためのコードを共有するか、コードを共有しないことにより、ターゲットアプリとソースアプリが密結合されます。後者の場合、アプリが同期しなくなる可能性があります。その場合、ソースアプリは、ユーザーが実際に利用できるはずの情報へのリンクを誤って省略してしまう可能性があります。
- これにより、ソースアプリとターゲットアプリを効率的かつ正しくアップグレードすることがかなり難しくなります。
- ソースページでリンクを生成するとき、およびターゲットページでアクセス権限を確認するときにデータベースを照会する必要があるため、パフォーマンスに影響があります。ソースアプリとターゲットアプリが異なる場所でホストされている場合、パフォーマンスへの影響が大きくなる可能性があります。
- ソースページとターゲットページが異なるシステムにある場合、これは、ターゲットアプリの役割のデータベースにアクセスするための資格情報を、潜在的にいくつかの異なるソースアプリ間で共有する必要があることを意味し、これらの資格情報を同期して安全に保つことをより困難にします。
この原則が重要な場合は、かなりのコストでそれを実装できます。しかし、それは広い規則として決して適用されるべきではありません。
この原則は実用的ではなかったため、イントラネットのWebサイトに完全に実装されることはありませんでした。最終的にそれは落とされました。 （そして大きな喜びがありました。）
リンクを提供するのではなく、ユーザーがアクセスできる場合はリンクが存在することを示す（つまり、「無効にする」）など、提案された妥協案をサポートします。ただし、この機能の開発コストは高額になる可能性があり、メリットと比較する必要があります（リンクをクリックして、ターゲットページで有益なエラーメッセージを取得するのと比べて）。メリットは小さいと思いますが、それが重要である場合もあります（たとえば、リンクの長いリストを表示する場合、その多くが「アクセス不可」または「見つかりません」エラーにつながる）。これは、ユーザーのタスクと、ユーザーが手に持つ必要性によって異なります。
ユーザーから情報を完全に隠すケースが見られる状況の1つは、リソースの存在そのものが機密情報である場合です。その場合、ユーザーにはターゲットデータにアクセスする権限がないため、リンクを非表示にしません。ユーザーにはメタデータにアクセスする権限がないため、メタデータ（リソースの存在）を非表示にしています。
確かに、画面上の不要な、またはあまり役に立たない混乱を減らし、有用なものを見つけやすくする場合があります。特に、何も役に立たないものにつながるリンクが多数かつ頻繁にある場合。しかし、非表示は混乱を軽減する唯一の方法ではありません...これは、「ズーム」されたリンクを小さくしたり、グレー表示にしたり、無効にしたり、ページの下部に移動したりすることで実現できます。混雑していないページで2つのリンクの1つを省略しても、混乱を減らすことはできません。ユーザーの目隠しになります。
私は彼らにリンクをまったく与えるのではなく、代わりにテキストをリンクに似たスタイルにして、アクセスできないことを簡単に識別できるようにすることをお勧めします。次に、各非リンクの横に「このコンテンツにアクセスできない理由とそれに対して何ができるのかを教えてください」というような何らかのリンクが表示されます。それについて本当に積極的になりたい場合は、非リンクの横にある簡単に認識できるアイコンを使用します。この場合、非リンクがロールオーバーされると、アイコンの上に小さな小さなツールチップがポップアップして、詳細を学習できることを示しますアイコンをクリックして非リンクについて。
他の人が指摘したように、アクセスできないページはリンクされるべきではありません。また、スマートユーザーから保護するために、ページ自体のサーバー側の検証で保護されるべきです。
状況が許せば、「リンクではないもの」ページ/モーダルに、ユーザーが部門のリストから選択して、特定の状況下で許可リクエストを送信できるフォームを含めることができます（例：ユーザーは、 Joe Somebodyに連絡することで、より多くのコンテンツにアクセスできる可能性があります。そのため、このページでは、そうすることができます）。
ツールチップについては、 TipTip jQueryプラグイン が好きです。
特定のコンテンツを禁止する必要があるが、そのようなコンテンツが存在することを全員に通知しても害がない場合は、次のようにします。
- 許可されていないハイパーリンクの色を灰色に変更します。
- ポップアップを保持するか、許可されていないコンテンツ、およびこのコンテンツが必要だと思われる場合は誰にコンテンツを送信するかについてより詳細なページに転送します。
簡単に推測できるRESTful URLを使用している場合（例：http://example.com/page/1/）、ユーザーには4〜1ページではなく1〜3ページを表示する権限があります。ユーザーにリンクをクリックして4ページに移動するオプションを与えないだけでは安全ではありません（またはリンクをJavaScriptポップアップに変更します）。 。
熟練した攻撃者は、不足しているURL名を自分で簡単に入力できます。権限のないユーザーにWebサーバーが禁止されたページを提供しないことを確認する必要があります。 （そして、アクセス許可を適切な方法で確認する必要があります。つまり、システムにログインしていて、推測できないセッショントークンがあることを確認する必要があります。）彼らが表示した最後のページやIPアドレス（特に、禁止されたセクションは、ユーザーの作成など、何らかのアクションを実行できます。
URLが簡単に推測できない場合でも、攻撃者はユーザーの履歴を参照したり、サーバーログを見つけたり、暗号化されていないhttp接続を盗聴してURLを見つけたりすることができます。
if (is_loggedin())
echo "<a href=\"destination\"">Click</a>";
else
echo "Log in to access this link."
そのように動作するはずです。
ユーザーがログインしている場合は、リンクをエコーします。それ以外の場合は、テキストをエコーします。