私のプログラミング チームは、従来の会計システムと連動するイントラネットを作成しました。基本的には、ユーザーが端末システムとやり取りする必要がないように、かなりの ASP.NET フロント エンドを作成していました。
いずれにせよ、テスターの 1 人は、最初の 8 文字が正しければ、ログイン コードが任意のパスワードを受け入れることに気付きました。テスターはパスワード「Password」でユーザーを作成しましたが、アプリケーションは「Password1」、「PasswordMonkey」、「PasswordFakeFakeFakehahahah」を検証します。そのため、テスターはこれを欠陥として記録しました。いくつかの調査により、従来のシステムではパスワードが固定幅の 8 文字フィールドに保存され、クエリを静かに 8 文字に切り捨てていることが明らかになりました。簡単なテストでは、このバグが会計システムにも存在し、20 年間気付かれなかったことが示されました。
レガシー アプリケーションはサード パーティ ベンダーによって維持されていたため、変更できませんでした。そのため、私は簡単な説明を書きましたif (password.Length > 8) { return false; }。結局のところ、8 文字を超えるパスワードは正しいとは言えません。バグが修正され、QA が承認されました。
そのため、アプリケーションが本番環境に入ると、「緊急!! ユーザーはアカウントにログインできません!!!」タイプのメッセージを顧客の社長から受け取ります。州法または会社の方針により、すべてのパスワードは 12 文字以上にする必要があり、修正後は誰も製品を使用できなかったことが判明しました。
会計システムは単に 8 文字を超えるものを保存しないこと、およびユーザーが最初の 8 文字を入力するだけですべてがうまくいくことを説明しました。「容認できない!」では、テキスト ボックスに maxlength を設定して、入力を有効な範囲の文字だけに制限できます。「愚か者!以前は問題なく機能していたのに、今すぐ修正してください!」私たちの顧客は私の会社の社長と怒鳴り合い、アプリケーションを修正しなければ変更ベンダーを脅迫しました.
そこで、サニティチェックをコメントアウトしてアプリケーションを「修正」し、バグを再導入しました。ASP.NET フロントエンドの認証コードを端末のバックエンドと同じように認証するという不合理な要求ではありませんが、意図的にアプリケーションのバグを修正するのは本当に当惑します。