アカウント名:
パスワード:
フォームを送信しようとしたときにチェックするというのは、form の submit をフックするということですかね。それだと「JavaScriptでフォーム内容を取得し、Ajaxで送信する」タイプのページはどうなるんでしょう。ちょっと考えてみたのですが
A) form の submit 時のみチェックして警告を出す →ajaxではmaxlengthを超えたデータが送信されてしまう
B) http request 発行時に警告を出すC) JavaScriptでフォーム内容取得時に警告を出す →どちらも、そこで処理中断されることを想定していない、既存のページでは、警告を出したあとのエラー復帰ができないケースがありそう。
ってことで、JavaScriptでの処理を従来通り正常に進行させるためには、フォーム送信時ではなく、入力(ペースト)段階で「maxlengthを超えたら、そのフォームにフォーカスしたままになり、maxlength以下に収めるまで他の操作をできなくする」ようにするしかないような気がします。
maxlengthはHTMLの文字数の定義が曖昧 [github.com]＆変更 [github.com]された事等が原因で、ブラウザ上の通常入力ですらアテに出来ない [github.com]物です。その為、本来ならば既存コードはフォームのmaxlengthを信用せずに対策済みなはずです。まぁ、現実は違ったりで結局不具合が起きる可能性が有りますが。しかし、今回の変更で死ぬシステムは元々運よく死んでなかっただけなので。
例えば、エイプリルフールネタになった吉野家 [it.srad.jp]ですが、maxlength=10な入力エリアに「𠮷野家」をコピペし続けた場合、IE/旧Edge:𠮷野家𠮷野家𠮷野家𠮷(10文字/14文字)新Edge/Firefox/Chrome:𠮷野家𠮷野家𠮷(7文字/10文字)と、挙動の差異が有ったりします。# Chromeの古いバージョンはIE/旧Edge側の挙動をします。# Firefoxは、BugzillaのBug 670837 - maxlength shouldn't count one non-BMP character as two characters [mozilla.org]がまとまってる？
＞ A) form の submit 時のみチェックして警告を出す＞ →ajaxではmaxlengthを超えたデータが送信されてしまう
そもそもこれは既存でも起こそうと思えば起こせるので、APIなりでチェックするのが正しいのでは？（開発者ツールでチェック外すとか。）
APIでチェックするのは勿論必須なのだけど、送信前に長さチェック出来ればできたほうが利用者にとってはありがたい。ネットワーク介さずに済む分速いからね。さらに言えば入力出来ないほうがその時点で気付けていい。
フォーカスを取るのはブラクラの基本中の基本だから、それは絶対にやっちゃダメ。
maxlengthを設定しなきゃいいだけでしょ。受け入れ態勢が整ってるなら何メガになっても問題ない。
そういう行儀悪いことをしたいんなら、わざわざそうしたい理由をちゃんとbugzillaで説明して納得させないと。「ボクの考えは説明しないし開発者の想定していない使い方をするけど、全部誰かが事前に汲み取って完璧にボクが納得するように対応し続けてくれないとヤダ」というのはただの駄々っ子。
自分でサイトを作る場合の話ではなく、既存のサイトでそういうことしてるのは結構見かける、という話です。(これは元コメに書き忘れてました。すみません)
あとは、「フォーム内容をJavaScriptで取得してAjax送信する」のが「行儀が悪い」こととは思えません。環境依存は強くなりますが、今時JavaSriptオフだと動かないサイトなんてそこら中にあるし。
「行儀の悪い」っていうのは，「フォーム内容をJavaScriptで取得してAjax送信する」ではなく，「maxlengthを超えたら、そのフォームにフォーカスしたままになり、maxlength以下に収めるまで他の操作をできなくする」というあなたの思いついた仕様案ではないだろうか？
maxlength指定なんかは、ユーザーにそれ以上は入らんよって通知する程度の目的であって、それをチェック処理の一部と捉えるのが致命的な誤り。maxlength指定したところ、それを無視したデータが送れるのは当たり前なんだから、クライアントは信用せずに、サーバー側でちゃんとやれよっていうWEBシステムの常識の話でしかない。
セキュリティ的に問題となることがあったので好ましい。JavaScript で入力フィールドに勝手に細工するのも禁止して欲しいんだけど、無理かな?
JavaScriptオフ
どうせハッシュ化するんだから何十文字でも受け付けろよ
コピペでパスワード貼り付けられないようJavascriptで細工してるサイトも面倒。まあDOM操作で直接値を貼り付け入力しちゃうけどね。
「何十文字でも」ではなく、根拠のある数字を述べて欲しい。その仕様通りに実装するのは簡単だろう。
境界値試験なんてアホ臭いよね
そんなわけあるかい離散系なんだから有限で最大値決めんかい
うーん、じゃあ4文字
四字熟語とかでログインしたいなあ。
冗談でもそういうのは止めてくれ。それを鵜呑みにしてそういう使用を押しつけられそうになったことあるから。
メモリも帯域も有限なのに、無限なんて実現できるものか。
ハッシュ化されたパスワードが漏洩した場合の安全性を保つために、高強度のストレッチングなどを行うと、長いパスワードでは膨大なCPU時間やメモリを消費してDoS状態になるんですよ。
例えば、パスワードのハッシュ化を目的とした関数 bcrypt (blowfish) は、最大72文字までしか対応していません。SHA-2にかけてから、bcryptにかけるなどすると、安全性が保証されません。あなたが暗号やハッシュの専門家でないならば、生兵法は大怪我のもと、素直にパスワードを72文字制限した方が安全です。
そもそも、普通のSHA-2を使えば良いって？高速ハッシュ関数をパスワードのハッシュ化に使うなんて脆弱ですよ。それだと、もし、ユーザが8文字のパスワードを指定したときなんてすぐにハッシュ化されたパスワードから復号されてしまうでしょうね。
逆にハッシュ化されるより大幅に長い入力を受け付けられるようにしてもあまり意味がない(強度が増えない)。もっとも理論上256bitの強度があっても人間は完全にランダムなパスワードを覚えられないから完全に無意味なわけではないが
貼り付け以外でも、maxlengthで切り捨てられたら分かるようにして欲しいね。
12文字のパスワードを登録したつもりが、maxlength=8が設定されていたせいで、8文字で登録されていたと言うトラブルがあったので。
CyberGate DDNS の登録フォームにその罠がしかけてあってハマった覚えがある
#10年近く前のハナシですが...
F.*77 って文字列を見て反射的に Fortran77 と認識
＃77まではFORTRAN、90からはFortranが正しい?
4年間放置、それでもって20日間で修正。なんだかなあ
入れ違いだったね。https://www.kobe-np.co.jp/news/sougou/202005/0013358458.shtml [kobe-np.co.jp]
6文字で切られるネタを書こうとしてやめた。
FM77AV77ってあったっけ？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
フォーム送信時のチェックはやめて (スコア:1)
フォームを送信しようとしたときにチェックするというのは、form の submit をフックするということですかね。それだと「JavaScriptでフォーム内容を取得し、Ajaxで送信する」タイプのページはどうなるんでしょう。ちょっと考えてみたのですが
A) form の submit 時のみチェックして警告を出す
→ajaxではmaxlengthを超えたデータが送信されてしまう
B) http request 発行時に警告を出す
C) JavaScriptでフォーム内容取得時に警告を出す
→どちらも、そこで処理中断されることを想定していない、既存のページでは、警告を出したあとのエラー復帰ができないケースがありそう。
ってことで、JavaScriptでの処理を従来通り正常に進行させるためには、フォーム送信時ではなく、入力(ペースト)段階で
「maxlengthを超えたら、そのフォームにフォーカスしたままになり、maxlength以下に収めるまで他の操作をできなくする」
ようにするしかないような気がします。
Re:フォーム送信時のチェックはやめて (スコア:1)
maxlengthはHTMLの文字数の定義が曖昧 [github.com]＆変更 [github.com]された事等が原因で、ブラウザ上の通常入力ですらアテに出来ない [github.com]物です。
その為、本来ならば既存コードはフォームのmaxlengthを信用せずに対策済みなはずです。
まぁ、現実は違ったりで結局不具合が起きる可能性が有りますが。
しかし、今回の変更で死ぬシステムは元々運よく死んでなかっただけなので。
例えば、エイプリルフールネタになった吉野家 [it.srad.jp]ですが、maxlength=10な入力エリアに「𠮷野家」をコピペし続けた場合、
IE/旧Edge:𠮷野家𠮷野家𠮷野家𠮷(10文字/14文字)
新Edge/Firefox/Chrome:𠮷野家𠮷野家𠮷(7文字/10文字)
と、挙動の差異が有ったりします。
# Chromeの古いバージョンはIE/旧Edge側の挙動をします。
# Firefoxは、BugzillaのBug 670837 - maxlength shouldn't count one non-BMP character as two characters [mozilla.org]がまとまってる？
Re: (スコア:0)
＞ A) form の submit 時のみチェックして警告を出す
＞ →ajaxではmaxlengthを超えたデータが送信されてしまう
そもそもこれは既存でも起こそうと思えば起こせるので、APIなりでチェックするのが正しいのでは？
（開発者ツールでチェック外すとか。）
Re: (スコア:0)
APIでチェックするのは勿論必須なのだけど、送信前に長さチェック出来ればできたほうが利用者にとってはありがたい。
ネットワーク介さずに済む分速いからね。
さらに言えば入力出来ないほうがその時点で気付けていい。
Re: (スコア:0)
フォーカスを取るのはブラクラの基本中の基本だから、それは絶対にやっちゃダメ。
maxlengthを設定しなきゃいいだけでしょ。受け入れ態勢が整ってるなら何メガになっても問題ない。
Re: (スコア:0)
そういう行儀悪いことをしたいんなら、わざわざそうしたい理由をちゃんとbugzillaで説明して納得させないと。
「ボクの考えは説明しないし開発者の想定していない使い方をするけど、全部誰かが事前に汲み取って完璧にボクが納得するように対応し続けてくれないとヤダ」というのはただの駄々っ子。
Re:フォーム送信時のチェックはやめて (スコア:1)
自分でサイトを作る場合の話ではなく、既存のサイトでそういうことしてるのは結構見かける、という話です。(これは元コメに書き忘れてました。すみません)
あとは、「フォーム内容をJavaScriptで取得してAjax送信する」のが「行儀が悪い」こととは思えません。環境依存は強くなりますが、今時JavaSriptオフだと動かないサイトなんてそこら中にあるし。
Re: (スコア:0)
「行儀の悪い」っていうのは，「フォーム内容をJavaScriptで取得してAjax送信する」ではなく，「maxlengthを超えたら、そのフォームにフォーカスしたままになり、maxlength以下に収めるまで他の操作をできなくする」というあなたの思いついた仕様案ではないだろうか？
Re: (スコア:0)
maxlength指定なんかは、ユーザーにそれ以上は入らんよって通知する程度の目的であって、それをチェック処理の一部と捉えるのが致命的な誤り。
maxlength指定したところ、それを無視したデータが送れるのは当たり前なんだから、クライアントは信用せずに、サーバー側でちゃんとやれよっていうWEBシステムの常識の話でしかない。
いいね (スコア:0)
セキュリティ的に問題となることがあったので好ましい。
JavaScript で入力フィールドに勝手に細工するのも禁止して欲しいんだけど、無理かな?
Re: (スコア:0)
JavaScriptオフ
そもそもパスワードの文字数制限すんな (スコア:0)
どうせハッシュ化するんだから何十文字でも受け付けろよ
Re: (スコア:0)
コピペでパスワード貼り付けられないようJavascriptで細工してるサイトも面倒。
まあDOM操作で直接値を貼り付け入力しちゃうけどね。
Re: (スコア:0)
「何十文字でも」ではなく、根拠のある数字を述べて欲しい。その仕様通りに実装するのは簡単だろう。
Re: (スコア:0)
Re: (スコア:0)
境界値試験なんてアホ臭いよね
そんなわけあるかい
離散系なんだから有限で最大値決めんかい
Re: (スコア:0)
うーん、じゃあ4文字
Re: (スコア:0)
四字熟語とかでログインしたいなあ。
Re: (スコア:0)
冗談でもそういうのは止めてくれ。
それを鵜呑みにしてそういう使用を押しつけられそうになったことあるから。
メモリも帯域も有限なのに、無限なんて実現できるものか。
文字数制限しないサイトは脆弱 (スコア:0)
ハッシュ化されたパスワードが漏洩した場合の安全性を保つために、高強度のストレッチングなどを行うと、長いパスワードでは膨大なCPU時間やメモリを消費してDoS状態になるんですよ。
例えば、パスワードのハッシュ化を目的とした関数 bcrypt (blowfish) は、最大72文字までしか対応していません。
SHA-2にかけてから、bcryptにかけるなどすると、安全性が保証されません。
あなたが暗号やハッシュの専門家でないならば、生兵法は大怪我のもと、素直にパスワードを72文字制限した方が安全です。
そもそも、普通のSHA-2を使えば良いって？
高速ハッシュ関数をパスワードのハッシュ化に使うなんて脆弱ですよ。
それだと、もし、ユーザが8文字のパスワードを指定したときなんてすぐにハッシュ化されたパスワードから復号されてしまうでしょうね。
Re: (スコア:0)
逆にハッシュ化されるより大幅に長い入力を受け付けられるようにしてもあまり意味がない(強度が増えない)。もっとも理論上256bitの強度があっても人間は完全にランダムなパスワードを覚えられないから完全に無意味なわけではないが
貼り付け以外でも (スコア:0)
貼り付け以外でも、maxlengthで切り捨てられたら分かるようにして欲しいね。
12文字のパスワードを登録したつもりが、maxlength=8が設定されていたせいで、8文字で登録されていたと言うトラブルがあったので。
Re: (スコア:0)
CyberGate DDNS の登録フォームにその罠がしかけてあってハマった覚えがある
#10年近く前のハナシですが...
空目 (スコア:0)
F.*77 って文字列を見て反射的に Fortran77 と認識
＃77まではFORTRAN、90からはFortranが正しい?
うーん (スコア:0)
4年間放置、それでもって20日間で修正。なんだかなあ
Re: (スコア:0)
入れ違いだったね。
https://www.kobe-np.co.jp/news/sougou/202005/0013358458.shtml [kobe-np.co.jp]
6文字で切られるネタを書こうとしてやめた。
Re: (スコア:0)
FM77AV77ってあったっけ？