アカウント名:
パスワード:
Web開発側から、というと大げさではありますが、JavaScriptは 便利/有用なんですよ。いちいちサーバにアクセスせずとも処理が 可能ではありますし。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
企業側の対策として (スコア:3, すばらしい洞察)
むやみにFLASHを使ったりJavaScriptやActiveScriptを要求したり……。JavaScriptを無効にしていれば今回の偽装アドレスバーは表示されないようですが、本当のその企業や銀行などのwebサイトがJavaScriptを要求するようでは、初心者に「JavaScriptというものをこ
Re:企業側の対策として (スコア:0)
便利/有用なんですよ。いちいちサーバにアクセスせずとも処理が
可能ではありますし。
そもそも、JavaScriptは原因ではなく、単なる手段の一つで
し
Re:企業側の対策として (スコア:3, すばらしい洞察)
あるいは、ユーザ環境に影響を及ぼしたり、アクセシビリティを悪くしていませんか？ウィンドウサイズを勝手に変更されたり、アドレスバーをいじられたり、通常使えるはずの機能を禁止されたりするようなもの、音声ブラウジングをしている人に不便な使い方などはユーザーとしてはやめてほしいと思うかもしれませんね。
そういった駄目な使い方をしていない、適切な使われ方であれば JavaScript も有用でしょうね。
Re:企業側の対策として (スコア:1)
いるんですよ、規約書いても「読んでない」とかいうバカが。
なので、confirm()で強制表示にさせて [ok]押さないと進めないようにしています。
perlでファイル送信を行う時って、次の頁を作れなかったんですよ。
(ファイル送信選択画面 -> 規約 -> 送信開始 ができない)
単純な入力確認等ならjavascriptなんて使わなくてもいいんですが、
使わざるを得ない時もあるんです。
Re:企業側の対策として (スコア:0)
Cookieにステートでも埋めとけ。
Re:企業側の対策として (スコア:1)
Cookieにステート埋め込んだら、input TYPE=file の情報を数セッション先に
引き継げるの？
ステート埋め込みってID・PASSの後、ログイン認証されたかどうかの話でしょ？
apache::sessionにしても、セッションIDを発行して、ログイン管理を行うだよね？
俺が知りたいのは、input TYPE=fileをsubmitした後に別ページに飛ばせて、
そこで「了承」してくれたら input TYPE=file を実行するというプロセス。
これがステート埋め込みで実現できるならそっちのがスマートだし
是非覚えたい。
了承をそんな位置にするなとかはナシな。
Reffererチェックにしてもそうだけど、
リファラチェックしたらinput TYPE=fileの内容を
複数回後のリクエストに引き継げるのかな？
つか、ありえない。
ステートもリファラもあくまでログイン管理の話だしょ？
Re:企業側の対策として (スコア:1)
この順番でないといけないんでしょうか？
規約 -> ファイル送信選択画面 -> 送信開始
じゃだめ？
Re:企業側の対策として (スコア:1)
> 了承をそんな位置にするなとかはナシな。
ということですね。
INPUT type=FILEはいじれないので、クッキーを使ってもいいのであれば、
１．ファイル送信ボタンの他に規約確認リンクを用意し、これを読まないと送信できないと表示しておく。
２．規約確認リンクで別ウィンドウを表示し、確認(サーバに通知)させる。
３．確認済み判定用のクッキーを返すなどした後、別ウィンドウを閉じさせる。
４．送信を受け付ける。
(もちろん、確認済みでないときは、受け付けない)
これで一応JavaScriptは必要ない。
まぁでも、送りつけてこられるのは拒否できないから、それが嫌だって言うんなら、スクリプトで制御したくなりますね。
Re:企業側の対策として (スコア:0)
＃偽装までして入るサイトとも思えん。
Re:企業側の対策として (スコア:1, 興味深い)
極力、クライアント側(JavaScript)で
チェックしてくれって言う要望はよくききます。
郵便番号辞書を全件裏で持てとか…
#無茶だって
顧客(サイトを公開しているメーカさん)のわがままを聞こうとすると
JavaScriptだのFlashだのに依存した作りになってゆきますね。
見栄えさえよければオッケーみたいなところもありますし。