ここで同様の問題が発生しています。Web アプリでは、AoP スタイルのアプローチを使用して属性を持つコントローラーをチェックする単純な Cookie 認証システムを使用し、現在のコンテキストを取得します (静的な HttpContext.Current またはインターセプターのタイプに応じてターゲット呼び出しオブジェクトから)、Cookie が存在すること、正しいデータが含まれていることを確認し、最後にデータベースまたはキャッシュなどでトークンを確認します。
とにかく、このアプローチはSignalrにも使用できますが、少し長くなり、依存性注入を使用しています. 基本的には、必要な属性でハブ呼び出しをラップし、DI/IoC 構成をセットアップしてこれらの呼び出しをインターセプトし、インターセプター内でハブ インスタンスを取得して、要求から Cookie (またはカスタム認証メカニズム) を取得し、検証します。それはすべて有効かどうかであり、そうでない場合は、ユーザーを追い出し、ハブメソッドに到達する前に戻る必要がnew HttpException("403", "Not authenticated");
ある aをスローします。このようにして、ロジックを 1 か所 (インターセプター、またはインターセプターが消費するクラス) に配置できます。 ) 次に、属性を使用してこの認証を使用する必要があるメソッドをラップします。
私は Ninject とインターセプト拡張機能を使用していますが、最近のほとんどの主要な DI フレームワークには、Autofac、Windsor、Spring など、何らかの形の IoC プラグイン/拡張機能があります。
現在のプロジェクトに DI や AOP を導入することに満足できない場合は、認証ロジックを含むカスタム ハブ インスタンスを作成し、それをハブで使用することもできます。保護したい各ハブメソッド内から手動でいくつかの認証ロジックを呼び出す必要がありますが、コードが少ないため、次のようになります。
public class AuthorisableHub : Hub
{
private ISomeAuthenticationToken GetSomeAuthenticationTokenFromRequest(Request request) // probably a SignalR specific request object
{
// Get your token from the querystring or cookie etc
}
private bool IsAuthenticationTokenValid(ISomeAuthenticationToken token)
{
// Perform some validation, be it simple or db based and return result
}
protected void PerformUserAuthentication()
{
var token = GetSomeAuthenticationTokenFromRequest(Context.Request);
var isRequestValid = IsAuthenticationTokenValid(token);
if(!isRequestValid)
{ throw new HttpException(403, "<Some forbidden message here>"); }
}
}
public class MyFancyPantsHub : AuthorisableHub
{
public void TellAllClientsSomethingSecret(ISecret secret)
{
PerformUserAuthentication();
// Do stuff with the secret as it should have bombed the user out
// before it reaches here if working correctly
}
}
それは完璧ではありませんが、うまくいくと思います(私は思います)。また、リクエストごとにハブが新しくインスタンス化されることをどこかで読んだことがあると確信しています。ハブ内のすべてのアクションに認証を適用します。
それが助けになるか、アイデアを提供してくれることを願っています...最終的にどのように解決したかを知りたいと思います。