アカウント名:
パスワード:
「開発チームのメンバー全員がセキュアプログラミング技術のトレーニングを適切に受けていることを確証する責任を負」っているからと言って、実際そう作られるかというのは別問題ですよね?
マジレスすると、以前委託したECサイトのテスト中、入力項目にfontタグ入れてみたら見事に文字が赤くなったり大きくなったり。。。
なんでサニタイズせんのじゃ~~!と委託先にクレームあげたら「最初に言え!」とか開き直られました。「んなもん、常識だろうが!」とこっちも吠え返して、社内にあったWEBプログラミングのテキストからXSSだのSQLインジェクションへの対策のページを送りつけてやりました。
こういうのって、要求仕様に明記しないといけないのでしょうか?呼吸するように実装してくれないと、発注側としては安心できないのですが。
この前、Webアプリなのに複数人が同時に編集することを考慮してない画面があって直してたんですが、 隣の席の中国人に「こういう問題起こさないようにな。」って話したら、 「こういうところはチェックを入れた方がいいんですか?」って返されました。
いや、Webアプリなんだからそんなこと考えるまでもないだろ!と久しぶりに声を荒げてしまった。 むしろ何でチェックを入れなくていいなんて思えるんだ? 排他制御してください、データが壊れないようにしてください、とか一々伝えないと駄目なのか・・・orz
# サニタイズ?もちろん毎回言わないとやりませんが何か? 新人じゃなくてWebアプリ経験4年てー。 # 即戦力だの派遣だの寝言言わずちゃんと教育しようぜ(涙
> 排他制御してください、データが壊れないようにしてください、とか一々伝えないと駄目なのか
あなたがどういう立場なのかわかりませんが、それぞれを対処するのにも、システムごとにそれなりにやりかたがあります。ぶっちゃけ、排他制御について、一人のユーザーが使っていたら、他のユーザーの利用を止めてしまうシステムも山のようにあります。
なんで、そういうことを対処してほしいと思うなら、明確に仕様の段階で盛り込むべきです。設計書を作成した段階で漏れている方が悪いと思います(漏れていることを指摘出来なかった方も悪いけど)。そんで、口頭でしか言わなかったということは、テスト項目から漏れているわけで、当該のシステムの利用はちょっと怖い気がします。
失礼。誤解を招いたようなので追記します。
そのシステムを設計したのも作成したのは、私とも隣の人とも縁もゆかりもない別の会社の方々です。 そんな糞システムなので、えぇ全く持って利用するのも保守するのも怖いです。
一概に排他制御を入れられない、というのはもちろん判りますが、だからといってデータが壊れるような状況を目にしておいて対策を入れたほうがよい?何て疑問系で出てくるのが信じられませんでした。 文化の違いとかそんなレベルではなく、プログラマとして間違っていると言いたくなります。
後からコミットされた方のデータを有効にする、というやり方もあるわけで。何をもってデータが壊れるとしているのかもわかりません。
そこが本題のつもりは無かったのですが、何か気にされているようなのでレスします。
データが壊れるは文字通りの意味ですね。削除済みのデータにリレーション貼るとか、データがあるのにリレーション消すとか。 後優先とかで何かしら完全性が保たれていれば、ああそういう設計なのかとも思えるんですが・・・。 そんなの常識だ!は駄目だと批判されていますが、せめてそれぐらいは考えてほしいです(涙
参照制約ぐらい言わなくてもつけてくれると思ってた。
なんてね。元コメが全てで「結局契約と金次第」です。「安ければなんでも良い」なんて方々もいるのですよ。サニタイジングにはその分手間とテストが増えるわけで、その分のコストを見積もっているかどうかです。
ここで一句
「そこからか そこからいわんと だめなのか」
なぜか社内オフショア状況に陥ったSEの世事の句
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
結局契約と金次第 (スコア:0)
「開発チームのメンバー全員がセキュアプログラミング技術のトレーニングを適切に受けていることを確証する責任を負」っているからと言って、実際そう作られるかというのは別問題ですよね?
Re: (スコア:3, 興味深い)
マジレスすると、以前委託したECサイトのテスト中、入力項目にfontタグ入れてみたら
見事に文字が赤くなったり大きくなったり。。。
なんでサニタイズせんのじゃ~~!と委託先にクレームあげたら「最初に言え!」とか
開き直られました。「んなもん、常識だろうが!」とこっちも吠え返して、社内にあった
WEBプログラミングのテキストからXSSだのSQLインジェクションへの対策のページを
送りつけてやりました。
こういうのって、要求仕様に明記しないといけないのでしょうか?
呼吸するように実装してくれないと、発注側としては安心できないのですが。
見た目動けばいい人たち (スコア:0)
この前、Webアプリなのに複数人が同時に編集することを考慮してない画面があって直してたんですが、
隣の席の中国人に「こういう問題起こさないようにな。」って話したら、
「こういうところはチェックを入れた方がいいんですか?」って返されました。
いや、Webアプリなんだからそんなこと考えるまでもないだろ!と久しぶりに声を荒げてしまった。
むしろ何でチェックを入れなくていいなんて思えるんだ?
排他制御してください、データが壊れないようにしてください、とか一々伝えないと駄目なのか・・・orz
# サニタイズ?もちろん毎回言わないとやりませんが何か? 新人じゃなくてWebアプリ経験4年てー。
# 即戦力だの派遣だの寝言言わずちゃんと教育しようぜ(涙
Re: (スコア:0)
> 排他制御してください、データが壊れないようにしてください、とか一々伝えないと駄目なのか
あなたがどういう立場なのかわかりませんが、それぞれを対処するのにも、システムごとにそれなりにやりかたがあります。ぶっちゃけ、排他制御について、一人のユーザーが使っていたら、他のユーザーの利用を止めてしまうシステムも山のようにあります。
なんで、そういうことを対処してほしいと思うなら、明確に仕様の段階で盛り込むべきです。設計書を作成した段階で漏れている方が悪いと思います(漏れていることを指摘出来なかった方も悪いけど)。そんで、口頭でしか言わなかったということは、テスト項目から漏れているわけで、当該のシステムの利用はちょっと怖い気がします。
Re: (スコア:0)
失礼。誤解を招いたようなので追記します。
そのシステムを設計したのも作成したのは、私とも隣の人とも縁もゆかりもない別の会社の方々です。
そんな糞システムなので、えぇ全く持って利用するのも保守するのも怖いです。
一概に排他制御を入れられない、というのはもちろん判りますが、だからといってデータが壊れるような状況を目にしておいて対策を入れたほうがよい?何て疑問系で出てくるのが信じられませんでした。
文化の違いとかそんなレベルではなく、プログラマとして間違っていると言いたくなります。
Re: (スコア:0)
後からコミットされた方のデータを有効にする、というやり方もあるわけで。
何をもってデータが壊れるとしているのかもわかりません。
Re:見た目動けばいい人たち (スコア:0)
そこが本題のつもりは無かったのですが、何か気にされているようなのでレスします。
データが壊れるは文字通りの意味ですね。削除済みのデータにリレーション貼るとか、データがあるのにリレーション消すとか。
後優先とかで何かしら完全性が保たれていれば、ああそういう設計なのかとも思えるんですが・・・。
そんなの常識だ!は駄目だと批判されていますが、せめてそれぐらいは考えてほしいです(涙
Re: (スコア:0)
参照制約ぐらい言わなくてもつけてくれると思ってた。
なんてね。
元コメが全てで「結局契約と金次第」です。
「安ければなんでも良い」なんて方々もいるのですよ。
サニタイジングにはその分手間とテストが増えるわけで、その分のコストを見積もっているかどうかです。
Re: (スコア:0)
ここで一句
「そこからか そこからいわんと だめなのか」
なぜか社内オフショア状況に陥ったSEの世事の句
Re: (スコア:0)
辞世の句でなくてよかったよ…