アカウント名:
パスワード:
10桁に満たないパスワードを勝手にスペースで埋めて登録してたんですよね．
あっちが持ってるデータは，10桁に埋められたものから生成されたものですよね．
それを，スペース埋めなくてもいいようにしたってことは，もしかして例の生パスワードを保存してるんですってやつ？
と思ったけど，手動でスペースを入力してたのを，あっちで勝手にスペースを埋めるようにしただけかな．
解決できたという事は平文がどっかに保存されていたということで。
スペースで比較が成功／失敗ってのは Oracle の CHAR/VARCHAR2 あたりの問題だろうか・・・？
私も「解決できた」ってあたりからして、平文パスワードでCHAR/VARCHARの違いが問題になったんだろうと想像しましたが、これは別にOracleに限った話じゃないですよね。
・元のシステムではVARCHAR(10)のカラムに可変長のパスワードを平文保存していた。・新システムも可変長で格納されるのを前提として設計開発。・ところが新システムのDBカラムをCHAR(10)になっていた。データ移行の際、10文字未満のパスワードはスペースが付加されて10桁固定になってしまう・結果、認証時にも、後ろにスペースを付加しないとログインできなくなるって感じで。で、新DBをVARCHAR(10)に直してから、改めてデータ移行し直すことで、復旧、っと。
新システムが開発段階に入ってから、COBOL流れの「固定長信者」な設計者が、影響を深く考えずに横やりを入れて、データ型をCHAR(10)に変えちゃった、というのを想像しました。
たしかに、ありそう。
だとしても、性根がCOBOLerかどうかよりも、ザルなテストしかしていなさそうな性根の方がよっぽど罪。
受け取った入力にサーバー側でスペースくっつけて処理するようになったのなら（つうか最初からそうしとけ）、平文を保存しておく必要は無いだろ。
それだったら今度は末尾のスペースが無視される不具合が発生だな
たったそれだけのために、まさかの2日がかりｗ
①問題の原因と修正箇所の特定②修正案作成③修正案の承認④修正作業⑤単体試験⑥結合試験⑦リリース判定会議⑧リリース
これだけ手順踏むんだぜ？
この会社は知らないけど、少しの変更をするのにもシステム全体をテストをして問題が発生しない事を確認したり、稟議書を回して全役員の承認を貰ったりしなければいけない場合があります。（特に金融系の場合は）直す以外の作業が圧倒的に多い場合が有るので、一瞬で直せる事が２日かかっても何の不思議もありませんよ？
>>システム全体をテストをして問題が発生しない事を確認これに必要な時間は仕方ないとしても
>>稟議書を回して全役員の承認を貰ったりしなければいけないこれが時間がかかることの理由になって当然ってのは、大切なことを見失ってしまっているんじゃないでしょうか。
>>稟議書を回して全役員の承認を貰ったりしなければいけない>これが時間がかかることの理由になって当然ってのは、大切なことを見失ってしまっているんじゃないでしょうか。？たとえばどんなことを見失ってんの？顧客サービス優先とか？たとえ見失っていなくても手順は必要で、緊急だから省略していいなんてことは無い。
軽く煽ったら思いのほか反論されて漠然とモラル方面に逃走してるだけでしょう。深い意味はないと思いますよ。
＞たとえ見失っていなくても手順は必要で、＞緊急だから省略していいなんてことは無い。
顧客が主要サービスにログインできないレベルの大トラブルなら、稟議に必要な役員みんなあつめて迅速に承認できるようにしたりするだろ。少なくとも私の知ってるとある金融サービス会社はそうだった。社長からみんな会議室に勢揃い。
会社の一大事に稟議を回すのに時間をかける役員なんてものを認めることが間違いって話です。
そもそも稟議なんてのは会議で集まってやるほどのことでもない程度のことを書類回して会議で承認したことにしましょう的なもんです。
この状況でそんなもんでいいの？って言いたかったのです。
役員たるもの、何かコトがあったときには即座に会議に出席できる状態にしておくべきです。リモート会議でもなんでもいいから。
役員の承認を省略していいなんて言ってないです。何か問題あったときに現場に責任取らされちゃたまりませんから。
× 私の知ってるとある金融サービス会社○ 私の想像上の金融サービス会社
回避方法も早々に確立してたし、元々そんな緊急性ないでしょ。#2772546のきまぐれな結果論を無理筋で擁護してるうちに「役員たるもの」なんてどんどん大仰になった雪ダルマ。
SIerでコードを組まないプログラマは幸せである
緊急じゃなかったけど、「>」を「>=」にするだけで5日かかったことあるな
パスワードにスペースを含んではいけないとかいう謎慣習がパスワードのエントロピーを劇的に低下させる
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
なぜ解決できた？ (スコア:1)
10桁に満たないパスワードを勝手にスペースで埋めて登録してたんですよね．
あっちが持ってるデータは，10桁に埋められたものから生成されたものですよね．
それを，スペース埋めなくてもいいようにしたってことは，もしかして例の生パスワードを保存してるんですってやつ？
と思ったけど，手動でスペースを入力してたのを，あっちで勝手にスペースを埋めるようにしただけかな．
Re:なぜ解決できた？ (スコア:1)
解決できたという事は平文がどっかに保存されていたということで。
スペースで比較が成功／失敗ってのは Oracle の CHAR/VARCHAR2 あたりの問題だろうか・・・？
Re:なぜ解決できた？ (スコア:2)
私も「解決できた」ってあたりからして、平文パスワードでCHAR/VARCHARの違いが問題になったんだろうと想像しましたが、これは別にOracleに限った話じゃないですよね。
・元のシステムではVARCHAR(10)のカラムに可変長のパスワードを平文保存していた。
・新システムも可変長で格納されるのを前提として設計開発。
・ところが新システムのDBカラムをCHAR(10)になっていた。データ移行の際、10文字未満のパスワードはスペースが付加されて10桁固定になってしまう
・結果、認証時にも、後ろにスペースを付加しないとログインできなくなる
って感じで。
で、新DBをVARCHAR(10)に直してから、改めてデータ移行し直すことで、復旧、っと。
新システムが開発段階に入ってから、COBOL流れの「固定長信者」な設計者が、影響を深く考えずに横やりを入れて、データ型をCHAR(10)に変えちゃった、というのを想像しました。
Re: (スコア:0)
たしかに、ありそう。
だとしても、性根がCOBOLerかどうかよりも、ザルなテストしかしていなさそうな性根の方がよっぽど罪。
Re:なぜ解決できた？ (スコア:1)
受け取った入力にサーバー側でスペースくっつけて処理するようになったのなら（つうか最初からそうしとけ）、平文を保存しておく必要は無いだろ。
Re:なぜ解決できた？ (スコア:3)
それだったら今度は末尾のスペースが無視される不具合が発生だな
Re: (スコア:0)
たったそれだけのために、まさかの2日がかりｗ
Re:なぜ解決できた？ (スコア:2, すばらしい洞察)
①問題の原因と修正箇所の特定
②修正案作成
③修正案の承認
④修正作業
⑤単体試験
⑥結合試験
⑦リリース判定会議
⑧リリース
これだけ手順踏むんだぜ？
Re:なぜ解決できた？ (スコア:1)
この会社は知らないけど、少しの変更をするのにもシステム全体をテストをして問題が発生しない事を確認したり、稟議書を回して全役員の承認を貰ったりしなければいけない場合があります。（特に金融系の場合は）
直す以外の作業が圧倒的に多い場合が有るので、一瞬で直せる事が２日かかっても何の不思議もありませんよ？
Re: (スコア:0)
>>システム全体をテストをして問題が発生しない事を確認
これに必要な時間は仕方ないとしても
>>稟議書を回して全役員の承認を貰ったりしなければいけない
これが時間がかかることの理由になって当然ってのは、大切なことを見失ってしまっているんじゃないでしょうか。
Re: (スコア:0)
>>稟議書を回して全役員の承認を貰ったりしなければいけない
>これが時間がかかることの理由になって当然ってのは、大切なことを見失ってしまっているんじゃないでしょうか。
？
たとえばどんなことを見失ってんの？
顧客サービス優先とか？
たとえ見失っていなくても手順は必要で、
緊急だから省略していいなんてことは無い。
Re: (スコア:0)
軽く煽ったら思いのほか反論されて
漠然とモラル方面に逃走してるだけでしょう。
深い意味はないと思いますよ。
Re:なぜ解決できた？ (スコア:1)
＞たとえ見失っていなくても手順は必要で、
＞緊急だから省略していいなんてことは無い。
顧客が主要サービスにログインできないレベルの大トラブルなら、稟議に必要な役員みんなあつめて迅速に承認できるようにしたりするだろ。
少なくとも私の知ってるとある金融サービス会社はそうだった。社長からみんな会議室に勢揃い。
Re: (スコア:0)
会社の一大事に稟議を回すのに時間をかける役員なんてものを認めることが間違いって話です。
そもそも稟議なんてのは会議で集まってやるほどのことでもない程度のことを書類回して会議で承認したことにしましょう的なもんです。
この状況でそんなもんでいいの？って言いたかったのです。
役員たるもの、何かコトがあったときには即座に会議に出席できる状態にしておくべきです。
リモート会議でもなんでもいいから。
役員の承認を省略していいなんて言ってないです。
何か問題あったときに現場に責任取らされちゃたまりませんから。
Re: (スコア:0)
× 私の知ってるとある金融サービス会社
○ 私の想像上の金融サービス会社
Re:なぜ解決できた？ (スコア:1)
回避方法も早々に確立してたし、元々そんな緊急性ないでしょ。
#2772546のきまぐれな結果論を無理筋で擁護してるうちに
「役員たるもの」なんてどんどん大仰になった雪ダルマ。
Re:なぜ解決できた？ (スコア:1)
SIerでコードを組まないプログラマは幸せである
Re: (スコア:0)
緊急じゃなかったけど、「>」を「>=」にするだけで5日かかったことあるな
Re: (スコア:0)
パスワードにスペースを含んではいけないとかいう謎慣習がパスワードのエントロピーを劇的に低下させる