二回入力させるUIはアホ
■ このスレッドは過去ログ倉庫に格納されています
ユーザー登録とか懸賞の応募で、メアドなんかを二回入力させる
サイトがあるけど、アホとしか思えん。
確認入力はもともと画面に表示されないパスワード入力のためだろ。
画面に表示されてれば、目で確認すればいいじゃん。
深く意味を考えずにほかのUIをまねするから、こんな間抜けな
ことになるんだよ。
あーめんどくせ。 >>101
一般的に入力値チェックは行うものだが、日付程度に関してセキュリティ
問題が出るようなシステムかどうかは>98が定義しただけだからなあ。
例えば金融やスケジュールなら、その後の処理に絡むから>101のように
存在有無は重要だけど、元々虚偽申告ありのものならばセレクトにしておけば、
数字2桁かどうかのチェックで済むって言うポリシーはあるかも知れん。
フォーム改変で大量のデータを埋め込まれなきゃいい程度の対策だけど。
まあ、処理そのものが、余計かどうかじゃなく粗さの問題になるよね。
粗くて済む=効率的ロジックではないが、省ける方法を考えてみるとそんな感じ。
虚偽申告を是とするようなシステムと定義してるのも君だけだぞ?
通常何らかの意味があって取るものだろう?
セキュリティに関係なくチェックはしないといけないだろ。 まあまあ、怠慢>>97=DQN、ということでFA。 >>108
少なくとも俺がいるので「君だけ」と言うことはない。
不特定多数を相手に名前の入力を強要してその名前の正当性を
確かめてるシステムなんてあるのか?
生年月日なんか20歳から年をとらないババアを筆頭に
まともに入力すると思えないのでフォームが埋まっているかどうかの
チェックだけでデータは捨ててしまえばいいんじゃねーの? >>110
そう思うならそんなデータ取らなきゃよろしい。
言い訳が苦しいよあんた。 チェックして再入力って意味じゃないの?
つまり、選択式ならユーザーが間違った文字を入れて
もう一度入力することがほとんどなくなる、と >>112
そのチェックは>>97の言ったプログラムでの値域判定ではないからな。 >>110
分かった、分かったからもちつけ。
お前の状況は極めて不利だ、もうそれ以上発言するな。
大怪我するぞ。 虚偽の申告、不正な値が入っていてもかまわないような項目、
即ち再利用されることが無いような項目などは削った方が
良いと思うが。
再利用するんだったら日付とかはやっぱ虚偽か否かはともかく
妥当性のチェックはすべきだし。 で、query_stringを直接入力させるUIが最強ってことでよろしいか? >107ですが、俺が>97とイコールと見てる人はいませんよね?
その事実を踏まえれば、>97のが「省略できる」と言ってるのだから、
そういう仮定に基づいて考えただけと理解いただけるでしょ>108
>>115
そうだね。そういうポリシーが通れば、webの安全性はあがるよね。
yahooメールも信頼できるようになる。リアルでは一般的な考え。
でも…虚偽の申請が許されないっていうと参加に敷居が高くなって
敬遠されてしまうし、真実ばかりが登録されてるとなれば、
狙いたい人にとっては一粒で二度美味しいシステムになってしまう。
例えば価格コムの事件を出すなら、メアド以外の信頼性は入力者の
危機管理意識に依存していた。まあ、ポリシーはいろいろあるけど、
実際に運用されているシステムでは、フリガナ欄でない名前欄に
全角30文字OKだとかザラ。実装者としては>115のように削れるじゃん
と思っても、営業や企画サイドが利用する気の有無は別に入れたいとか
ケースバイケースではある。
不正な値は「セレクトさせてる」から、一定の形式内で妥当な数値が入る事を忘れてる。
障害を狙えるほど不正値(SQL文だの、数Mbyteだの)を突っ込めるかどうか、
その値が間違いなく入力者の正確な個人情報と結びつけられるかの2面で見ると
後者ってのは元々web上のチェックでは期待できない。>97で「省略できる」と
いう時に用意された通常の手段で入力する限り後者を満たす範囲が決まってる。
>98もそれは前提で、セキュア面からヤバいといってると思ったのだけど。
セレクトを無視して例外値を入れる手段(フォーム改変+リファ改変proxy)
以外に、データに有効な同一性を確保しろというなら、それは閾値がどうでは
済まなくなる。まあこんな事力説する事じゃないが、そんな板・スレだしねw 名前とか不定形のものはともかく、日付のチェックごとき
省略も糞もねえだろ。 セレクトで選択させる所では、省略されてるとこは結構ある。
俺が作ったシステムじゃなく、office氏になりたくないから指摘しないが。
省略というならば、文字列チェックをせず
いきなり数字に変換、というとこでは省略してるかな、
SELECT では 『郵便番号入力→住所フォームに反映』は今時付いてて当然の機能 >>121
そしてそれは、たいして便利じゃない機能。 たくさん釣れてよかった。
スレがあんまり盛り上がらないからちょっと煽ってみたの。 >>97が本物の97だったら、恥の上塗り。
偽者だったら、寒い。
どちらにせよバカ決定。 >>122
そしてそのたいして便利じゃない機能をつけてあげたら
担当者が混乱したのか、
登録の最初のページが郵便番号だけになってしまった
馬鹿なフローの買い物サイトは実存します >>126
どういうこと?? イマイチ意味がわからん。 普通は、郵便番号を入力してもらったら、フォームの住所欄に
郵便番号検索した結果の住所が反映(自動入力)させるのが普通だが、
126の案件では、ほんとに郵便番号しかフォームに欄もないし
表示もされないってことじゃないのか。 出来心で郵便番号ー住所変換つけました
番号辞書がよく更新されるのでめんどくさいことになってしまいました
やるんじゃなかった >>129
良く居るんだよね。
既に存在してる機能を付加する奴。
リンクで郵便局の郵便番号検索のHPのリンクを張って、
郵便番号が分からない場合は此処で調べて下さいってだけでいいのにね。 www.post.japanpost.jpで番号増減csvが更新されるからcronか手動shかで更新できるようにしておきなさい >>130
普通は住所入力の手間を省くためにつけるんじゃないの
最初郵便番号だけ入力してもらい実行ボタン押して残りの住所部分だけ手入力してもらうという 入力の手間を省いてもらう、
提供側としては誤入力を減らす。
という意味があることはある。
入力する側も郵便番号辞書使ってる人には
あまりうれしくないんだけどね。
手書きの申込書をデータに移す、内部向けのツールには
この手の機能は便利ではある。 セレクトにした場合
日付の閾値チェックなんて必要ナッシング
大抵DBのカラムタイプを
日付型にしてるんだからそのままつっこめばそれでよし。
SQLインジェクション対策は当然必要だが、
わざわざおかしなデータ送ってくる足クサ野郎に
ご丁寧にエラーメッセージを返してやる必要はナシ! と思ったが2月30日とかの場合もあるから
妥当性チェックはどっちみち普通するな。ナハハ 漏れもうるう年の判定が面倒だから、日付チェックまではしてない。
さすがに年だけは異常なのを弾いてるけどな。たとえば西暦5000年生まれとか。 たぶんちょっとググレばソース付きで転がってるような気がするけどな
日付判定(うるう年含む)
my @last = (31,28,31,30,31,30,31,31,30,31,30,31);
$last[1] = 29 if ( $year % 400 == 0 or ($year % 100 != 0 and $year % 4 == 0) );
if ($last[$month - 1] < $day) {
# error
}
Perlならこんだけですむ事をマンドクサイとか面倒とか…。
日付はまだ良いけど他の重要なトコも省いてそうで怖い。 DBへ入れるときにエラーにさせるって言うのも、ひとつの方法だと思うね。 >>142
おお、ぐぐる前に向こうから転がってきた(w checkdateとmktimeとdate("L")があれば複雑なif条件は不要 >>145
strtotime も仲間に入れといてよ webプログラマーって、変な優越感持ってるから嫌いです。 >>130
例えば登録者を市区町村単位で検索したい場合なんかは郵便番号から
自治体コードを引いてそいつを登録しとけば誤入力による検索漏れが防げる。
市区町村の合併があっても対応できる場合が多いし。
あと統計的に、他のページに飛ばしちゃうと気まぐれでそのまま帰って来ないお客さんが
多いことが分かってる。商業的にもサイト内で済むなら済ませた方がいい。
ところで>>129は、例えば299-4300みたいな複数の市区町村(この場合「長生村」と「一宮町」)を
持つ郵便番号入れられた時の対応はちゃんとできてるか?
職業柄というか何と言うか、郵便番号の自動入力をみるたびについこういう番号を
入れてみたりするんだが、どれか1つの市区町村に決め打ちされちゃって変更できない
モノをよく見かける。
>>142
うちのはこうなってる。PHPだと標準関数あるね。
if ($day > (31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31)[$mon - 1]
+ ($mon == 2 && ($year % 4 == 0 && $year % 100 != 0 || $year % 400 == 0))){
#error
}
スレタイのメールアドレス二回入力についてだが、メールアドレスの欄を1つしか作らない場合
数パーセントの割合でメールのエラーが帰ってくる。要するにアドレスの入力ミス。
んでもって二回入力にするだけでこのエラーが激減する。二回入力なんてコピペされて
意味ない気がしてたけど、ハイフンとアンダースコアを間違うようなお客さんにはメール欄を
コピペしようなどという発想は起きないらしい。
そんなことよりも生年月日と年齢の両方入力させるのは止めて欲しい。 >>151
んやきめ打ちしてます(w
でもちゃんと手入力で書き換えられるようになってるのでまあいいかなと
2回入力にすると間違いが激減するのはその意味合いを理解して
あえて2回入力している利用者が多いということだと思いたいですね
>>154
ぬるい。そんなもんコピペされておしまい。
オレなら入力桁数分テキストボックス用意して、各テキストボックスは1文字しか入力できないようにする
んで、それを×100並べて入力させるな。 >>151
>スレタイのメールアドレス二回入力についてだが、メールアドレスの欄を1つしか作らない場合
>数パーセントの割合でメールのエラーが帰ってくる。要するにアドレスの入力ミス。
>んでもって二回入力にするだけでこのエラーが激減する。二回入力なんてコピペされて
>意味ない気がしてたけど、ハイフンとアンダースコアを間違うようなお客さんにはメール欄を
>コピペしようなどという発想は起きないらしい。
数%の頭悪い奴のために多くのユーザを面倒にさせる糞システム ビッダーズで買いたいものがあって
BIGLOBEに登録したら
生年月日の他に満年齢記入させるフォームがあるでやんの。
ばかかと。
全体的なシステムもださいし。
たまにプロバイダ系のサービス触ると
びっくりするほどレベル低かったりするよな。 >>161
ビッダーズは知らんが、生年月日と年齢を入力させといて、
年齢はいつまで経っても更新されないシステムは結構ある。
年齢だけ入力させてしまい、現在の年齢が推測でしか
分からないというアホな顧客名簿も見たことがある。
郵便番号入れさせておいて都道府県も入れさせるシステムもなんだかなーと思う。
市区町村は合併や新設に郵便番号DBが追いつかない場合があるから
必ずしも自動入力が良いとは限らないが。 Ajaxのサンプルだけど郵便番号を入力していくと住所欄が自動的に埋まっていくのは感動した。
これなら住所が変わっても変更が楽だなと >>161
生年月日と年齢を適当に入力しても通ってしまうサイトが多いのも事実。 >>166
一応通しておいて、何かあったときにチェックして「こいつは要注意人物だなふむふむ」ってやるんだよ
つーかちょっと計算すれば分かるんだから
意味ねー
リアルで聞いてとっさに答えられるかどうかの反応を見るなら分かるが 生年月日+年齢は全く意味ないわけではないが
正しく入力する人の手間を考えれば糞なシステムだね。 >>169
うそを書いてるわけではないが何年も年齢を聞かれたり書かされたことがなかったので
とっさに自分の年齢がわからなかった(w
はぁ・・・・としかなぁ
俺のサイトでは生年月日・年齢・血液型・DNAタイプまで入力させるよ。
で、アカシックレコードにアクセスしてちゃんと整合性取れてるか確かめてる。 俺もサイトは好きな体位とかスリーサイズも入力させてる。
もちろん後から整合性取れてるか確かめる。 若い娘に俺の好きな体位が整合性取れてるか確認してほしい パスワード入力を隠蔽するのはいいんだけど、
登録時には普通に表示しといて欲しいなあ。
あれがないとそのまま記録しとけるんで。 自分の生年を西暦で言えないおじちゃんおばちゃんのために
生年は西暦と和暦を併記したセレクト入力がいいよ >>178
和暦の正当性チェックはもっと面倒だけどね。 入力をした人が俺の好みかどうかチェックさせてる。
タイプ度80%以上だったら携帯にメールが送られる仕組み。 彼女にinsert権限がありませんスレ思い出した。 入力必須項目に※書いて、
末尾に
※…入力必須項目
って書くのも分かりにくいっつうか意識の導線阻害してね?
一つ一つの項目に(入力必須)と書く方が
ユーザーにはわかりやすいと思う。
開発者が重複を嫌う気持ちも分からんでもないが。 それを言うなら入力が必要ないものは最初からつけないでほしいと思ふ 最近はユーザーも、*が付いていれば入力必須と学習しちゃってるからなあw ところで日本郵政公社は、郵便番号と住所のデータを公開しているけれど
あれってコンマ区切りのテキストファイルでしか公開していないの?
データの読みは自由にできる形で、データベースとしても公開してくれないかな。
いい加減差分とか見るの面倒。 >>188
それじゃアクセス過多でサーバがダウンしちゃうじゃん http://www.post.japanpost.jp/zipcode/dl/kogaki/lzh/ken_all.lzh
スクリプトが実行される度に、このファイルを郵政公社のサーバから
ダウンロードして解凍して、それを基に検索させている俺はどうなるんだ? >>190
それは非効率では?
ダウンロード+解凍+検索 って時間かかるじゃない。 >>191
常に最新のデータが入手できるよ♪
----
まあ>>190は冗談なんだけどさ…… 半角カナで振込先を入力させるフォーム見たことがある 半年以上前のレスだが……。
>>192
wget -N http://www.post.japanpost.jp/zipcode/dl/kogaki/lzh/ken_all.lzh
でいいっしょ。
ダウンロード前に元ファイルのタイムスタンプを取っといて、変化があったら展開&DB更新。
っていうスクリプトを組んどいて、cronでメンテ時間中に走らせると。 登録フォームとかでメールアドレスを2回入力させる2回目の入力を
貼り付け(ペースト)禁止させているのアホかと。
こっちは間違わないようコピペ使ってるのに。
また、わざわざ手間をかけさせるのが気に入らない。 >>198
だが二回入力させるほうが誤入力は本当に減るので
反論する理由がない。諦めろ。
http://www.nikkeibp.co.jp/style/biz/skillup/spam/070827_58th/
筆者がWeb調査にかかわって得た経験則では、1回だけメールアドレスを
入力してもらうWebフォームだと、誤入力を防ぐことは非常に難しい。
回答を得た直後に、記入してもらったメールアドレスにメールを送っても、
1000人に10人ぐらいが不達になる。2回入力を求めて誤入力をチェックする
Webフォームを使うと、不達は1000人に2人ぐらいまで減る。
8人は単純ミスによる誤入力と推測できる。 つFirefoxでの入力フォームでのペースト禁止回避方法
ttp://q.hatena.ne.jp/1301470823
※Greasemonkeyのアドオンをインストールしておく必要があります。 >>201
スクリプト使う前にドラッグ&ドロップが使える場合が多いよ。
画像のコピー禁止でもD&Dは使えたりする。
ページとの相性とかが出る可能性もあるので、右クリック貼付がダメなら[CTRL]+[V]、
D&Dもダメならスクリプト使ってみるでよいのでは。 >>1とは別の視点でメールアドレスを2回入力させるのはアホだと思う
メールアドレスを間違えて入力したときだけ訂正させればいいだろう
(1)メールアドレスを入力させる
(2)メールアドレスに登録用URLを送りつける
登録用URLが来たら開く(3)へ
登録用URLが送られてこなければメールアドレスの間違いだから(1)へ
(3)メールアドレス以外の項目(希望ID、パスワード、個人情報、etc)を入力させる
(4)登録官僚 コピペしない場合2回目の入力時って、1回目のを見て打つだろうから、
1回目のアドレスが誤入力だったら2回目のも誤入力になって結局意味ないと思うんだけど、
>>199見ると実際はそうでもないってことなのかな? 1回目のを見ながら打つなら
2回目の入力で1回目の誤入力を気づけるだろ。
「あれ、ここ、rとt間違えてるじゃんw」とかさ。
たった今、実体験してきたw 2回入れた方が誤入力が減るという話はデマ
実際はそんなことはない ■ このスレッドは過去ログ倉庫に格納されています