私はASP.Net Identity 2.2をWebアプリケーションで使用しています。ASP.Net Identity 2.0無人ログイン
私がやりたいことは、一部のページのサムネイルやPDFを生成するためにWebアプリケーションにアクセスするバックグラウンドサービスがあることです。このサービスは、w3wp.exeプロセス内で実行される可能性があり、ユーザーによって行われた特定のWeb要求によってトリガされます。ユーザがいくつかの設定を変更し、バックグラウンドサービスがトリガされてサムネイルが再生成されます。
問題は、他のユーザーがページにアクセスするために使用できるバックドアを開かずに、バックグラウンドサービスがページにアクセスできるようにすることです。現在のところ、Webリクエストから認証Cookieをコピーし、ページをリクエストしてサムネイルを生成するコードを使用していますが、Cookieをコピーする既存の接続なしでこれを行う必要があります。それはそれ自身のクッキーを得ることができる必要があります。
PDF /サムネイルの生成に使用しているライブラリは、Webサーバーに通常のWeb要求を行い、ヘッドレスブラウザを使用して動作します。私は、ページが静的なページを生成することが難しいように多くのjavascriptとajaxが含まれているので、Webサーバーを経由する必要があります。
理想的には、Web上の誰もがログインできない「システム」ユーザーを使用する必要があります。
私は、ユーザーのパスワードを復元可能に復号化できる形式(すべてのパスワードはデータベースでハッシュされています)に保存したくありません。
どのようにすればいいですか?
サムネイルサービスからリクエストが来ていることを確認するための確実な方法があれば、サーバーはパスワードを必要とせずにsignin()関数を呼び出すことができますが、それ自体は難しい問題ですセキュリティを迂回するためにサーバー上のWebブラウザーを実行しているユーザーから保護したいと考えているからです。私はおそらく共有(一回限りの)秘密を考えていませんでしたが、これが十分に安全に実行できるかどうかはわかりません。
バックグラウンドサービスの別のユーザーを作成し、BackgroundServiceAppの役割のように役割を設定することができます。あなたはこの役割だけがアクセスできるAPIを書いているのですが、後であなたのサービスはこのuserAccountを使ってログインし、ユーザー情報を得ることができる独自のアプリapiにアクセスします。 Azureを使用している場合は、https://msdn.microsoft.com/en-us/library/azure/dn798668.aspxをチェックして、Azure QueueまたはAmazon Simple Queueを使用することもできます。 – Miguel
個別のAPIは、ユーザーが画面上に表示されているものと同じように見えるサムネイル/ PDFを生成しようとしているため、サービスがユーザーと同じページにアクセスすることは意味があります。努力の重複を減らします。つまり、2つの異なるパイプラインが同じデータにアクセスするのではなく、パイプラインの最後に余分なステップを置くだけです。 – Mog0
@ Mog0最近の共通のアプローチでは、まずAPIを作成してから、UIと他の自動サービスの両方で同じAPIを使用してデータにアクセスさせることです。そうすれば、今説明した重複問題を回避できます。あなたのUIを既に構築しているのであれば、明らかにそれほど助けにならないのですが、将来私はそれを言いたいと思っています。 – ADyson