アカウント名:
パスワード:
SSL接続状態でヒストリバックするとフォームの内容をキャッシュ しないのはいいとして、リロード時に必要なパラメータ送らないの はどうなのよ。それでセッション外れたりするので、
ということは、input[type=hidden]なんかでセッションを特定するキーをやりとりしてるのだと思いますが、これだけをCookieに移せば済む話ではないかという気がしますが、
# クッキーにすると複数ウィンドウ開
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
ブラウザに依存しないで (スコア:4, すばらしい洞察)
ブラウザに依存しないでください。
HTML4.01やらISO-HTMLやらメジャーなものなら何でもいいですけど、少なくとも規格に依存してください。
「このブラウザは対応してます」とか
Re:ブラウザに依存しないで (スコア:0)
IEは標準規格外の固まりみたいなもん(偏見込み)だし
多少記述がおかしくてもそれっぽく解釈しちゃうし
動作確認にはもっと厳密にチェックしてくれるブ
Re:ブラウザに依存しないで (スコア:1, 参考になる)
> バグ抱えてるからIEでしか動かないと思った方がいいと思うん
> だけどどうよ?
クライアント(依頼主の方)がIEしか使ってなくて、それで製作側
がIEのバグやらヘンな挙動に対応すると他のブラウザでの動作を
確認してるヒマがなくなる。
っていうのは良くある。
確認できなくなるというより、IE以外のブラウザでひどく使い勝手
が悪くなってしまったりとかだけど。
SSL接続状態でヒストリバックするとフォームの内容をキャッシュ
しないのはいいとして、リロード時に必要なパラメータ送らないの
はどうなのよ。それでセッ
Re:ブラウザに依存しないで (スコア:1)
ということは、input[type=hidden]なんかでセッションを特定するキーをやりとりしてるのだと思いますが、これだけをCookieに移せば済む話ではないかという気がしますが、
Re:ブラウザに依存しないで (スコア:0)
> ということは、POSTするデータをちょっといじれば、色々とできそ
> うなので、Webアプリの作り方の方として問題があると思うのですが。
そう言われると思ってましたが、、非SSLだった古いサイトを極短期
間で最低限の作業でSSL対応してくれなんて場合、そもそも設計
から考え直す余裕はないのですよ。
しかし過去に私がやったものは、入力エラー時の「戻る」をJSヒス
トリバックで実装してて、戻ったときにキャッシュしてたりして
なかったり、キャッシュしてなかった時のリロード時に何もPOSTし
てくれないと・・・。
POSTしてくれないことにはどうしようもないですよね。
# ええ、pragma: no-chacheとかにした上「戻る」ボタンを全部
# フォームにしましたとも。
RFCには動的ページはキャッシュすべきではないが、リロード時に
はパラメータを再度送るべきと定義されていたはずだが、、、。
HTTP関係のRFCは多くてドラフトだったかもしれないけど。
まあ、異論反論あるとはありますが、Webアプリなんてそういう
曖昧なものの上で動いているものですし、この辺で失礼!
# 今日もめっさ疲れているのでAC