アカウント名:
パスワード:
hhmmssでファイル名作ってたとか恥ずかしい問題という話まぁ恥ずかしいのはともかくこんなシステム作って問題起こしちゃったら胃が痛いだろうな…
ファイル名を128bit乱数とかにしとけば、相当運が悪くない限りバッティングしなさそう
「念のため」でも付けとけば実際問題にはならんかったよなぁ とか思ってしまうでもそういうののあったらもし起きたら解析大変なんだよなー
これって本来はファイル名は固定でも問題ないはずの処理になってて、「念のため」に日付にしといただけだと思う。
はっはーんありそうかもそしてそのせいで検査すり抜けちゃったとか…
乱数でも衝突しないわけじゃないので、どうしてデータベースに同じのがないか確認しないの?1個if文入れることすら納品前にできない人間に作らせてるのは怖い
> どうしてデータベースに同じのがないか確認しないの?法律上の理由。
処理用の乱数IDにも法律引っかかるん?
むっちゃひっかかる
番号法2条8項 この法律において「特定個人情報」とは、個人番号(個人番号に対応し、当該個人番号に代わって用いられる番号、記号その他の符号であって、住民票コード以外のものを含む。第七条第一項及び第二項、第八条並びに第四十八条並びに附則第三条第一項から第三項まで及び第五項を除き、以下同じ。)をその内容に含む個人情報をいう。
マイナンバーの代わりに乱数IDを振ったら、それもマイナンバーとみなす、というのが法律の立て付け。
詳しくないので教えてほしいのですが、それはマイナンバーと乱数IDが紐付けられる場合であって、重複チェックの対象であるところの、証明書のテンポラリファイルや発行履歴テーブルにマイナンバーが含まれていないならば関係ないですよね?
逆に言うと、マイナンバーと紐付けなくても重複チェックは出来そうな気がするのですが。
マイナンバーと紐づかないのなら、DBテーブル全件とかディレクトリ中ファイル一覧とかから乱数IDで検索して1件とか一致したときに、それが自分ナンバーのモノか他人ナンバーのモノかわからない気がしてくる…
重複が検知された場合、すべての問合せに対して業務を止めるって仕組みならできそうではある。当件においてセキュアだけど、もしそれが発生したらたぶんその時も大臣は文句を言うと思う。
そもそもマイナンバー単位で印刷ファイル名のID振るなよ印刷要求単位で振れよ
いや、そもそも最初の出力要求と住民票データ引っ張り出すとこまでしかマイナンバーいらんでしょ。印刷イメージの作成に入った時点でセッション管理なりでUUID送るとかマイナンバーと別の情報で送付先管理しなさいな。
印刷イメージ内にマイナンバー入ってたりしないん?
入ってることも入ってないこともあるけどそれがどうした?
印刷イメージのファイル名をデータベース管理とかコスト意識なさすぎて逆にこえーよUUID使えば済む話だろ
実機でテストできるのが、リリース1カ月前だからに決まってるじゃないですか。それまではF様の下請け先に作らせ、下請けが開発完了したところで、DVDに入れて一次受けに持ってくる。そこで実機投入。
1カ月でバグ全部潰せ、リリース日は変えられない、実にウォーターフォールモデル。
被らないファイル名を作成して応答で教えてやればいいだろ
それな絶対に衝突を許してはならないシステムなのに採番の手間くらいケチるなと
XTECH(要ログイン)によると [nikkei.com]、ファイル作成は逐次処理で、本来は先の人の処理が終わるまで後の人のファイル作成は待たされる作りになっていたとのこと。hhmmssどころかファイル名固定なんじゃないかな。
どうして逐次処理にこだわるか不明だけど(FujitsuとのことなのでListCreatorを使ってそうだけど設定を弄れば100並列できそう [fujitsu.com])、それならそれで、適当にカウンタ付けて「###通目.pdf」とかにすりゃいいのに…
古いPerl CGIで見かけたような雑な排他制御でもしてたのか
ちな雇用調整助成金の受付システム [nikkei.com](2020年)も、他人の情報を閲覧できるバグをやらかし。今後も、また同じようなバグを作りこむでしょう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
川崎市では問題は解決された (スコア:4, 参考になる)
・マイナカードで誤交付 川崎市「2人同時申請で、システム不具合」発生
市内2カ所のコンビニで2人が1秒以内のほぼ同じタイミングで申請をしたところ、
システムの不具合で先に申請した人の証明書に後の人の内容を上書
・市によると、戸籍システムとコンビニ交付シス
Re:川崎市では問題は解決された (スコア:3)
hhmmssでファイル名作ってたとか恥ずかしい問題という話
まぁ恥ずかしいのはともかくこんなシステム作って問題起こしちゃったら胃が痛いだろうな…
Re: (スコア:0)
ファイル名を128bit乱数とかにしとけば、
相当運が悪くない限りバッティングしなさそう
Re:川崎市では問題は解決された (スコア:2)
「念のため」でも付けとけば実際問題にはならんかったよなぁ とか思ってしまう
でもそういうののあったらもし起きたら解析大変なんだよなー
Re: (スコア:0)
これって本来はファイル名は固定でも問題ないはずの処理になってて、「念のため」に日付にしといただけだと思う。
Re:川崎市では問題は解決された (スコア:2)
はっはーんありそうかも
そしてそのせいで検査すり抜けちゃったとか…
Re: (スコア:0)
乱数でも衝突しないわけじゃないので、どうしてデータベースに同じのがないか確認しないの?
1個if文入れることすら納品前にできない人間に作らせてるのは怖い
Re: (スコア:0)
> どうしてデータベースに同じのがないか確認しないの?
法律上の理由。
Re: (スコア:0)
処理用の乱数IDにも法律引っかかるん?
Re: (スコア:0)
むっちゃひっかかる
マイナンバーの代わりに乱数IDを振ったら、それもマイナンバーとみなす、というのが法律の立て付け。
Re: (スコア:0)
詳しくないので教えてほしいのですが、それはマイナンバーと乱数IDが紐付けられる場合であって、
重複チェックの対象であるところの、証明書のテンポラリファイルや発行履歴テーブルにマイナンバーが含まれていないならば関係ないですよね?
逆に言うと、マイナンバーと紐付けなくても重複チェックは出来そうな気がするのですが。
Re: (スコア:0)
マイナンバーと紐づかないのなら、DBテーブル全件とかディレクトリ中ファイル一覧とかから乱数IDで検索して1件とか一致したときに、
それが自分ナンバーのモノか他人ナンバーのモノかわからない気がしてくる…
重複が検知された場合、すべての問合せに対して業務を止めるって仕組みならできそうではある。
当件においてセキュアだけど、もしそれが発生したらたぶんその時も大臣は文句を言うと思う。
Re: (スコア:0)
そもそもマイナンバー単位で印刷ファイル名のID振るなよ
印刷要求単位で振れよ
Re: (スコア:0)
いや、そもそも最初の出力要求と住民票データ引っ張り出すとこまでしかマイナンバーいらんでしょ。
印刷イメージの作成に入った時点でセッション管理なりでUUID送るとかマイナンバーと別の情報で
送付先管理しなさいな。
Re: (スコア:0)
印刷イメージ内にマイナンバー入ってたりしないん?
Re: (スコア:0)
入ってることも入ってないこともあるけどそれがどうした?
Re: (スコア:0)
印刷イメージのファイル名をデータベース管理とかコスト意識なさすぎて逆にこえーよ
UUID使えば済む話だろ
Re: (スコア:0)
実機でテストできるのが、リリース1カ月前だからに決まってるじゃないですか。
それまではF様の下請け先に作らせ、下請けが開発完了したところで、DVDに入れて一次受けに持ってくる。そこで実機投入。
1カ月でバグ全部潰せ、リリース日は変えられない、実にウォーターフォールモデル。
Re: (スコア:0)
被らないファイル名を作成して応答で教えてやればいいだろ
Re: (スコア:0)
それな
絶対に衝突を許してはならないシステムなのに採番の手間くらいケチるなと
Re: (スコア:0)
XTECH(要ログイン)によると [nikkei.com]、
ファイル作成は逐次処理で、本来は先の人の処理が終わるまで後の人のファイル作成は待たされる作りになっていたとのこと。
hhmmssどころかファイル名固定なんじゃないかな。
どうして逐次処理にこだわるか不明だけど(FujitsuとのことなのでListCreatorを使ってそうだけど設定を弄れば100並列できそう [fujitsu.com])、
それならそれで、適当にカウンタ付けて「###通目.pdf」とかにすりゃいいのに…
Re:川崎市では問題は解決された (スコア:1)
// お約束すぎる
Re: (スコア:0)
古いPerl CGIで見かけたような雑な排他制御でもしてたのか
Re: (スコア:0)
ちな雇用調整助成金の受付システム [nikkei.com](2020年)も、他人の情報を閲覧できるバグをやらかし。
今後も、また同じようなバグを作りこむでしょう。