Webプログラミングについて語るコミュのformの入力値のvalidationについて

http://mixi.jp/view_bbs.pl?page=9&comm_id=852457&id=6563532
の178あたりから派生して、ちょっと議題がそれてしまったので、とりあえずこの一点

・「formの入力値のvalidationについて語る」
というテーマで吸収しようと思います。

意見をいろいろ語ってくださいm(_ _)m

コメント(8)

最初
全て
最新の40件

[2] mixiユーザー 04月18日 00:32

わぁ張ろうかどうか迷ったんだよねぇ・・・
たかぎさんリファラたどって見に来るから・・・・

[3] mixiユーザー 04月19日 22:15

振っといて若干スベってるので^-^;

「maxlength 意義」などで検索してみたのですが、
maxlengthを設定することの意味を正しく（？）解説してくれているサイトが見つかりませんでした。

高木さんの記事はありましたが、これはちょっと論点が違う
http://takagi-hiromitsu.jp/diary/20051122.html
＃ココで見るとmaxlengthを「入れろ」とはなっていませんね。
＃バッファーオーバーフローに関して意義あることが書いてありますね

今回の質問の経緯で指摘があったように、
maxlengthを可能な限りいれたほうが良いのではないか？
という意見がありましたが、これについて
どなたか納得できる意見をお持ちの方がいらっしゃれば
教えていただければ幸いです。
＃パスワード入力欄に限りません。

また、なんともいえないのは
元トピ198番でたけぼんさんの書かれた
> ユーザ側の使い勝手や悪意のないユーザからのリクエスト
> データ量の軽減という点では効果ありそうですが、
> セキュリティ的に見るとな～んも効果なしって思えてきまし
> た。

ここの「軽減という点では」というのは、
セキュリティ面ではない、とすると、一体どういう面、
というようなもの（なにかいいネーミング）はあるのでしょうか？
郵便番号のハイフンであればユーザビリティであると思いますし。
こういったことも「セキュリティ」の一種だと捉えられるかもしれません。

[4] mixiユーザー 04月20日 03:27

極論を投下した方が議論になるかも？ってことで、少し極論をｗ

validationに関しては、「出力時の」sanitizingが絶対に行われるような場合には
「どうせその入力値を反映することはないから、もっとましな値入れてよ」
って意味でvalidatorの結果を通知しますね。
maxlengthに関しても、ほとんど同じようなもんだと思ってます。

DBにとって危険な値かどうかは、バックエンドが判断すれば十分で、
アプリケーション層がその判断をしても、コードが肥大化するだけではないかと。
なので、アプリケーション側でのvalidatorは、
「通常のユーザが気づかなかった入力ミスを通知する」って程度のもので、
それをバックエンドで気にくわなかったら捨てちゃえばいいでしょうね。

私の場合、JavaScript-Onが前提のシステムが多いので、
アプリケーション層でのvalidationすらなく、
クライアント側とバックエンドだけでチェックすることもあります。
validation＝ユーザビリティって面から、それで構わないと思うんですよね。

ってわけで、validationとセキュリティ強化は別の話だと思ってます。
maxlengthのattributeが存在するのは、validationとしてメジャーだからって程度で、
ime-mode:inactive とかと存在意義としては似たようなもんかな。

あ、あと、
<input type="text" style="width:100%;" maxlength="8">
みたいな感じで、見た目と最大長にギャップがある場合に設定することはありますね。
これは、パスワードとかよりも、「題名」とかでよく使うかも。

[5] mixiユーザー 04月20日 05:15

自分の場合、validationはほぼ、Model側制御でつ。
例外も勿論ありますが。

maxlengthは、クライアントの要望で入れろっていわれることが結構ありますね。
いま、作ってるサイトでもそうなんですが印鑑の販売フォームで、個人実印の印面は４文字までとかなんで、それ以上入れられないようにお願いします。とかそんな感じです。

実際は該当するフォームのデータは４文字以内のvalidationがModel上でかかってるわけですが、UIとして間違いを少なくするっていう考えの元でmaxlengthを設定する感じですかね。

HTMLのオプション周りはUIのために存在していると考え、UIとして必要ならいれてる感じです。

[6] mixiユーザー 04月20日 09:47

「DBの文字セットに合わせてエンコードしたバイト数」で制限する場合、maxlengthは意味無いんで、サーバ側で検査。
「どうしてもブラウザで」と言われたら、javascriptでevent拾ってバイト数を超えたらvalueを書き換え。

[7] mixiユーザー 04月20日 10:02

個人的にはクライアント側でのチェックは、ユーザー利便性以外の意味はないと思うんですけれど。

[8] mixiユーザー 04月20日 21:02

ああ、確かに制御は基本的にModel側ってのはなんか納得する気がします。

Javaとかの場合getter/setterを用意するときの基本的な設計方針として、なぜアクセサを用意するかというと値のチェックをアクセサ内ですることが推奨されている（ごめんなさいリソースがないです）からだった気がします。

ある程度「優れたUI」ってのがmaxlengthとかの話になるのかなと思いつつ、最近はJavaScriptがOnなのは割と前提なので、打ち込んでいくと文字数越えた時点でエラー文字列を画面に出すとかのほうがよくある話のような気もしますね。

＃極論、確かに歓迎です。

ログインすると、みんなのコメントがもっと見れるよ