提言：パスワードロック機能は誤入力の“回数”ではなく“種類数”で - Qiita
正当なユーザーの多くはパスワード認証を拒否されたらまず自分のミスタイプを疑い、再入力を試します。再々入力、再々々入力を試すことも大いにありえます。別のパスワードを試すこともありますが、それも拒否された場合はやはりその別パスワードのミスタイプを疑ってそれも再入力します。正当なユーザーは、自分のミスタイプを疑っての再入力で容易に試行回数を使い切ってしまうのです。 それに対して、総当たり攻撃をする攻撃者の目的はより多くの種類のパスワード候補を試すことです。 誤ったパスワードの種類数でなく回数を条件にすることは、防御力にまったく寄与することなく正規ユーザーの利便性だけを下げているのです。利便性ということは当然、カスタマーサポート工数とユーザー離脱率を高める利益削減要因だということです。回数を条件にする意義はまったくありません。
ファントムリードは起こらないのにSEIRIALIZABLEでない、それがポスグレのREPEATABLE READ - Qiita
ファントムリードは起こらないのにSEIRIALIZABLEでない、それがポスグレのREPEATABLE READPostgreSQLトランザクション トランザクション分離レベル、苦手意識を拭えない方はわりといらっしゃるんじゃないかと思います。なにしろ私がそうですからね！ だから本題の前にまずはおさらいから入りましょう。 トランザクション SQLのすべて成功するか最初からなかったことになるかしかないように管理された一連の操作のことをトランザクションと呼びます。 Javaのsynchronizedブロックのようなものをイメージしてしまうこともあるかもしれませんが、それは全然違いまして、トランザクションの進行中にもほかのセッションによってDB内のデータは刻々と書き換えられていきます。最初からなかったことにできる、それだけがトランザクションの特徴ですから。 トランザクション分離 しかし進行中にどん
サーバからクライアントに送信する技術 - WebSocketを中心に - Qiita
Webでのプッシュ技術 HTTPはクライアント（ブラウザ）からリクエストしてサーバからレスポンスが返る一問一答型のプロトコルなので、基本的にはサーバ側からブラウザに新着情報をリアルタイムで通知（プッシュ）できるようにはできていません。 しかしそれでもプッシュをしたいという場合にどうするかという話が出てきます。やり方には以下のようなものがあります。 ポーリング クライアントからサーバに定期的に新着を問い合わせるようにします。 最も原始的かつ確実なやり方。欠点は、最大でポーリング間隔の分だけ通知が遅延しうることです。 ロングポーリング（“COMET”） ポーリングなのですが、問い合わせを受けたサーバは新着情報がなければレスポンスを返すのをしばらく保留します。 そのあいだに新着情報が発生すれば即座にレスポンスを返しますし、一定時間経過したら何もなかったとレスポンスを返しましょう。 飛び交う通信内
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WindowsのあのフォルダはUNIX/Linuxで言えばあそこだ - Qiita
