IIS 7 以降でのアプリケーションプールと権限について調べた - しばやん雑記
今日、IIS 周りの設定を行っている時に「お前 ASP.NET/IIS の MVP のくせに IIS のこと何も知らないのかよ！」と説教され、そういえば IIS の上っ面しか使ってないと思ったので、理解が中途半端だったアプリケーションプールと権限について調べました。 ちなみに ASP.NET/IIS となっているのは、ASP.NET の Expertise が IIS と統合されただけです。*1 環境の準備 開発用のマシンには IIS をインストールしてますが、何時でもぶっ壊し可能な環境が欲しかったので Azure に Windows Server 2012 R2 な環境を用意しました。 当然ながら IIS 8.5 なのですが、アプリケーションプールや権限に関しては IIS 7 から変わっていないので問題ないはずです。 アプリケーションプール とりあえずアプリケーションプールを新しく作成し
OpenSSHのAuthenticationMethodsを使って鍵認証+ユーザパスワード認証による二要素認証の設定をする | 俺的備忘録 〜なんかいろいろ〜
Blog 201701 OpenSSHのAuthenticationMethodsを使って鍵認証+ユーザパスワード認証による二要素認証の設定をする OpenSSHの6.2以降では、AuthenticationMethodsという項目を指定することで複数要素での認証を行うことができる。 これを使って、鍵認証とユーザパスワード認証の二要素認証設定を行ってみる。 「鍵とパスワードなら、秘密鍵にパスフレーズつけときゃいいじゃん」とも思うが、今回はそれはおいておく(鍵は使いまわして、特定のサーバだけ二要素認証にしたい場合もあるので)。 記述方法としては、AuthenticationMethodsの指定のあとに認証方式の組み合わせをカンマ区切りで、パターン別はスペース区切りで記述してやればよい。 例えば鍵認証+パスワード認証(orチャレンジレスポンス)の場合は、以下のように記述してやる(事前にChal
JWT認証、便利やん？ - ブログ
どうして JWT をセッションに使っちゃうわけ？ - co3k.org に対して思うことを書く。 (ステートレスな) JWT をセッションに使うことは、セッション ID を用いる伝統的なセッション機構に比べて、あらゆるセキュリティ上のリスクを負うことになります。 と大口叩いておいて、それに続く理由がほとんどお粗末な運用によるものなのはどうなのか。最後に、 でもそこまでしてステートレスに JWT を使わなくてはいけないか？ とまで行っていますが、JWT認証のメリットはその実装のシンプルさとステートレスなことにあります。現実的には実際はDB参照とか必要になったりするんですが、ほとんど改ざん検証だけで済むのは魅力的です。トレードオフでリアルタイムでユーザー無効化ができないことくらいですかね。ライブラリなんて使う必要ないほどシンプルだし、トレードオフさえ許容できればむしろ、なぜこれ以上に複雑な認証
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
