二回入力させるUIはアホ
■ このスレッドは過去ログ倉庫に格納されています
ユーザー登録とか懸賞の応募で、メアドなんかを二回入力させる
サイトがあるけど、アホとしか思えん。
確認入力はもともと画面に表示されないパスワード入力のためだろ。
画面に表示されてれば、目で確認すればいいじゃん。
深く意味を考えずにほかのUIをまねするから、こんな間抜けな
ことになるんだよ。
あーめんどくせ。 例えば、LDAPとかを使用する。でもって、OSのログインやらで流用する。
ブラウザは、そういう入力が必要になったら、サーバーから取ってくる。
ユーザー作成時にその情報はすでに入力されているというわけです。 >>22
Microsoft wallet は知ってるか?
すたれてるけどな。 今でも、ブラウザで個人情報の入力データを登録できるでしょう。
あれがうまく機能していればねぇ。
またアホなシステムを見つけてしまったぜ。
生年月日入力させて、年齢まで入力させんなよ。
そんくらい自分で計算しろ。 >>25
それは アホだと思う
個人的には、 読みを全角カタカナでしか入力受け付けないというのも
アホだと思うがなー 変換してくれよ… と。
半角数字も 全角数字から変換してくれ。 >>25
でたらめな登録をはじくためだよ。ちゃんと裏で計算してる。
少なくとも俺が作った奴はな。 >>26
それは敷居を高くするため。
カタカナで入力しろって言ってひらがなで入力するバカとか
全角半角の区別もつかない池沼はお断わりってこと。
それとまだアホだと思うのが生年月日をドロップダウンリストで、
入力させるのだな。
西暦とか日とか、何十も項目があるのをドロップダウンリストで入力させんなよ。
ユーザーがアホだから、変な入力されないようにって言うんだろうけど、
日付の入力のチェックなんて簡単なんだから普通にテキストで入力させろって。
ほんとアホばっかり。 ロクにweb の入力をやったことがないおっさんがクライアントだと、
ドロップダウンリストにしてくれ率が高いっす。
作る方だって面倒なんですよねー。Smarty でだいぶ楽にはなったけど。 >>29
PC初心者はキーボードをろくに打てない。
マウスなら使える。
レベルをとことん下げないと、使えないやつらが多い。 >>33
どうせ生年月日以外の項目はテキスト入力だし、なんか意味あるのかと思うが。
以前、住所を全角で入力しろってところで間違えて番地を半角で入力したら、
エラーになってしまったことがあるけど、生年月日だって同様にエラー処理すれば
いいだけだし。
>>34は全角半角も理解できないバカw
お前みたいな奴はお断わりってことだよ。 俺も数字を全角でうつのが気持ち悪いから半角でうったらエラーでた。
つーか、普通数字を全角で打たせようとするな!ボケが! >>36
全角半角混ざると文字数を管理するのが面倒。
それが嫌で登録しない奴を相手にする手間を考えると全角で統一するほうが賢明。 ドロップダウンリストと数値のテキスト入力。
試験項目で言うと前者の方が少なくなる。
ユーザに極力エラーパスを通らせない努力は皆をシアワセにする。
>>40
選択式にしたからといってその範囲の値しか入力できないわけではないのでテストの手間は一緒。
入力画面をローカルに保存してソース書き換えればいろんなことができる。
開発者がバカだと愉快。 この前一般ピープルがPCを操作してるのを見て思ったことなんだが、
入力形式が違うものが交互に、例えば text radio text selectてな順番で並んでいると
マウス・キーボードの切り替えに結構手間取るみたいなんだな。
textが連続して並んでいる場合でも、いちいちマウスでフォーカスを移動したりとか(w
考えさせられたよ。
まぁ、Fool(略 は>>1のためにある言葉だなと思った。 >>40
ドロップダウンの項目はエラーチェックせんのか。
外部からの入力は全部チェックするだろ。ふつー。 >>40見たいなバカが作ったサイトから情報が漏れるんだよ。
>>40はエステ屋みたいに入力した内容をcsvで保存してるだろ?w >>45
はいはい、SQL位覚えてからしゃべって下さい。 >>40
ユーザービリティということならドロップダウンリストはあまりよろしくないよ。
>>42
セッションは入力者を特定するにはいいけど、入力値の汚染チェックはまた別だよ。
>>43
良いこと言ってる。 >>47
知ってる。
少しでも分かってる奴ならまともな反論してくるだろうと思って鎌かけてみた。
見事に首を刈られてくれた>>45君に多謝。 >>48
まぁ、この板はタイトルにUIってあるくらいだから、
入力時のバリデーションをどうするかが肝みたいだね。
保存時のサニタイズはまた別ってことで。(というよりやってて当たり前)
個人的には、
全角←→半角くらいは自動でバリデーションして受付けてくれないとUIとしてダメダメ君だと思う。
漢数字の電話番号をはじくくらいは許すけどね。
>>49
バカをはじくUIとしては優秀ですが何か問題でも? >>48
間違いを指摘された後で知ってるとか言うのってみっともないよ。 せめてトリップが「#釣り」とかなら良かったのにね( ´,_ゝ`) 48はcsvで管理してるんだろうな。
index.html置けば解決と思ってたエステ屋のサイト管理者のバカっぷりに匹敵する。 【厨房のための煽り煽られ講座】
煽られて反論できなくなった
→ ○○ 必 死 だ な (w
予期せぬ自分の無知で煽られた
→ 釣れた ← >>48
→ わーマジレス帰ってきたよ
言い返せないけど負けは認めたくない
→ ( ´,_ゝ`)プッ
→ 無知白痴は黙ってろ
→ 知能障害をおこす バカでマヌケで必死な48がいるスレはここですか?w >>50
「こんなへぼフォーム作るなんてバカなヤツだな」
ということに気付かないバカは、はじきまくっても問題はない。
ここにおバカなフォームについて簡単にまとまってるよ。
ttp://allabout.co.jp/computer/webproduce/subject/msub_ca5.htm >この板にしては久々に低Lvなスレだな
久々??? >>11 どうでも良いが三井住友VISAカードのIDはちゃんと変更できる。 テンパった初心者と、知った風なことを語る非プログラマが、
日雇い仕事に追われる土方の神経を逆なでする。 ところでみんな、数字入力させる項目にはime-mode:disabledなんて使ってる? クライアントがWin/IEに限定される案件では使ってる。 >>1は正論。
メアドなんてもともと入力が面倒だから
ほとんどの人が1つ目のをコピペしてしまう。
再入力を強制できるようにならない限り何の意味もない。 何の意味もないとは思わないな
少なくとも、コピペでも2回入力しろということによって
少しは注意する人もいると思う。
サイトによってはそれぐらいの誘導でいいんじゃまいかと思うけど。 2回入力はユーザー自身がタイプミスを自己チェックできるように便宜をはかってるだけだとおもうがな〜
パスワードならそこそこ意味あるかもしれないけどメールアドレスとかはどうせコピペするんだから一緒だろ。
って言う流れです >>71
だから便宜をはかってやってるだけなんだから利用しないのは使う側の勝手であって
UIがバカとかいう問題ではな〜いと言いたいのだ
メールアドレスを2回入力させるというのは責任の所在を明らかにするためでもある。
例えば、重要な内容のメールを送る場合、そのメールが届かなくて文句を言われる事がある。
(俺が経験したのはあるデパートの会員向けセールの案内)
「私に案内のメールが届かなかった。おかげで私はセール期間中に行くことが出来なかった」
というもの。
登録フォームにはメールアドレスを2回入力するようにしてあり、
注意書きにもコピペではなく必ず入力して下さいと明記しておいた。
実際にメールが送信されていない可能性もあるが、登録されているアドレスが間違いで
メールがエラーになって戻っていることを確認した。
こういった場合、相手のクレームに対して、ちゃんと登録しなかった方が悪いと言える。
もちろん謝罪はするし、面と向かって「お前が悪い」とは言わないが、
下手にゴネた場合、こういった経緯を元に相手の理不尽なクレームや要求を跳ね除けることが出来る。 メールアドレスがクリティカルな場合、
情報入力→仮登録→メール送信→メールでURLクリック→本登録
って形にするのが普通でない?
すると登録時に間違いアドレスがはじかれるから
二回入力させる必要もないと思うのだが >>74
メール鯖と連携したプログラムの組めないレン鯖のほうが多いですからねえ
>>76
連携できないと手作業で返信しないといけないのでめんどくさくてやってられません
企業もレン鯖使うよ。でも、メールが送れない状況は発生しないだろうねぇ。 全部のブラウザで試したことないし、Javascript切ったらダメだけど、
ペーストさせたくないフォームに
onpaste="return false;"
って入れるのはダメかな? >>40=>>42=>>48の香ばしい匂いに誘われてやってきましたが、
もう旬は過ぎてしまったようですね。 >>75
ハァ?? メール鯖と連携???
キミは何を言っているんだい・・・・。
たとえばPHPならmb_senうわなにすんだやめろ。 >>82
sendmailが使えない鯖ってことでしょ
有料だったら使えるところがほとんどだけど >>83
いまどきsendmailが使えない鯖なんてあるのか??
XREAだって使えるのに。
(っていうか、XREAはヘタな有料鯖なんかよりもずっと高機能だけどね) 生年月日で「月日」はセレクトボックスが便利だけど、
生年までセレクトボックスにするのはアホだね。
利用者にとってはかえって選びにくいし、
フォーム制作者にしてみれば効果の低さのわりに作る手間がかかる。 月日のセレクトボックスもイラネ
年がキーボードなら月日もキーボードだろ 全部が1つのセレクトボックスだったらいいんだよ
365x100くらいあれば足りるだろ >>87
まあ、お前みたいなオタクの発想としてはそれが正しいな。
ただ普通の人はなるべくキーボード入力したくないものだよ。
注文フォームなんかでは、極力キーボード入力を減らしたい。
キーボード入力項目が多いとめんどくさがって止めちゃう人がいるからね。
オタクだけを相手にできるなら設計も楽なんだが。 一桁ずつセレクトにしたらいいやん
そうやん
それでいいやん >>82
ちがうだろ
ユーザーへ確認メール送信
ユーザーから確認の返信
返信メールを受け取って完了処理←ここが連携できる鯖少ないだろ?
仮登録メールの内容に登録用のURL書いて送信
そのURLにアクセスすると登録完了
登録完了メール送信
普通こんな感じじゃないのか?
>>93
元々の>>74は確認メール返信じゃなく確認URLのクリック ぉぃぉぃ、月日をセレクトにするのは、プログラムで余計な値域判定をなくすためだろうが。 >>97
月日をセレクトしても、プログラムで値域判定をさせないという事はありえない。
というか、していないものはセキュリティ上ヤバイ。
簡単に偽装できる値をチェックもせずにセレクトだからと値をチェックしないのは甘い。
Webプログラムの基礎からやり直した方が世の為だよ。 ”余計な”と書いてあるのが読めないようだな。
脊髄反射するような奴はwebプログラム止めたほうが世のためだよ。 余計ってどんなトコ削るのさ。
もともと手入力でも必要ない余計なロジックでも入れてるのか? 俺も『余計』なものが何なのか気になる。
手入力でも、月に関しては1から12までの数値かどうか。
日に関しても、その月が何日まであるのかと、1からその月にある日の数値かどうか。
セキュリティ上、これらのチェックを行う事を考えると、
手入力だろうとセレクトだろうと同じチェックをしないといけない。
つまりは同一のコードを書くと言う事になると思うんだけど・・・ >>93
アホ。
もともとの話の発端である>>74の例を実現するには
「返信メールを受け取って完了処理」まで必要ないぞ。
そこまでやるには.forwardとか必要になってくるけどな。
>>74の例なら、ほとんどのレン鯖で可能。 >>97=>>99は自分の知識の愚かさに気付いていない。
>>101が書いた通り、セレクトにしようがしまいが、
送信された値のチェック・ロジックは同じ。
そんな基礎的なことも分からずに「脊髄反射」するようなバカは
webプログラム止めたほうが世のためだよ。 >>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 では ■ このスレッドは過去ログ倉庫に格納されています