入力画面が複数に渡るフォームで、ユーザが各画面で入力したデータを、hiddenによって引き回すのではなく、セッション変数（セッションIDにヒモ付いてサーバ側に格納される情報）に一時保存するタイプのWebアプリケーションが増えているように思います。 フォーム処理でセッションが使われるのは、「実装をシンプルにしたい」「携帯サイトなどで通信量を減らしたい」といった理由のほかに、「アプリケーションをセキュアにしたい（hiddenだと改竄される）」という理由があるのではないかと思います。 しかし、セキュリティ上の問題は、セッションを使ったフォーム処理においてもしばしば見つかります。 以下では、セッションを使ったフォーム処理で、割と多く見つかる問題について書きます。 画面遷移の不正 ある会員制サイトの、会員登録フォームを会話風に書いてみます。 会員登録の際には、氏名、生年月日、住所の3つを登録します。

最終回です。今回は，ある意味IT業界の禁忌に触れてみます。Web＋DBシステムを発注したときの見積もり額の秘密です。システムが目指す最終的な目的は”利益を上げられる仕組みの構築”です。見積もり額は利益算定の一番わかりやすいコスト判断ですが，果たして構築費用はどういう計算で生まれているのでしょうか。 利益を上げるコツは「身の丈に合った投資」をすること 利益を上げるためにはどうするべきか。私は経済評論家ではありませんから，あれやこれや難しい話はできません。ただ物事の本質は，実はいつだって単純なものです。バサっと単純明快に言い切ってしまいましょう。「自分の身の丈に合った額を投入すること」です。 決して都会とは言い切れない我が家周辺では，冬になると焼き芋の巡回販売車が回ってきます。焼き芋屋さんのほとんどは軽トラックを使っています。なぜ軽トラックなのでしょうか？　つまらないことに見えますが，これがビ

via del.icio.us/popular Apacheのフォルダローカルな設定ファイル.htaccess で使いそうな設定をかたっぱしから書き込んだファイル。 メイン、スクリプト関連、ヘッダ(キャッシュや最速化)、URL書き換え、認証、SSL、開発中サイト、というようなジャンルごとに、よく使われそうなディレクティブがずらずらと並んでいる。PHPの設定、cool URLの設定、エラーページ、認証の掛けかた、などなど。 書き換えるべきところは英単語で何を書くのかわかるようになっているので、コメントとあわせて思い出しながらコメントを外していくとそれなりに使えそうな .htaccess が作れるかもしれない。僕なんかは細かい設定方法すぐ忘れてしまって検索することが多いので、これで楽になりそう。 # 本当に不要なものはコメントにせずファイルから消すべきだし、安定運用に入ったら.htaccess

[追記] if構文の変数スコープの説明に間違えがあります。新しいスコープは作られません。 お盆のまっただ中8/11(土)に、社内勉強会を開いて、PHPユーザ向けにRuby/Rails入門をやりました。 じつはお盆の土曜日に4時間も勉強会って事で、そんなに人も集まらないだろうと思っていたのですが、ふたを開けてみたら28名も参加があり、びっくりしました。それだけ興味を持ってもらったのは嬉しいけど、これだけ集まるなら資料はちゃんと作らないと・・・・。ということで、作った資料を公開します。なんとRuby編100ページオーバー、Rails編200ページオーバーと、かなり大作です。 RubyKaigiで、発表者のスライドの横でIRCが表示されていたのが面白かったので、勉強会の参加者には、Lingrのチャットルームに全員入ってもらって、質問やパートごとの「終わった！」という書き込みをしてもらいました。今

Webアプリケーションが攻撃者に付け込まれる脆弱性の多くは、設計者や開発者のレベルで排除することができます。実装に忙しい方も、最近よく狙われる脆弱性のトップ10を知ることで手っ取り早く概要を知り、開発の際にその存在を意識してセキュアなWebアプリケーションにしていただければ幸いです。 Webの世界を脅かす脆弱性を順位付け OWASP（Open Web Application Security Project）は、主にWebアプリケーションのセキュリティ向上を目的としたコミュニティで、そこでの調査や開発の成果物を誰でも利用できるように公開しています。 その中の「OWASP Top Ten Project」というプロジェクトでは、年に1回Webアプリケーションの脆弱性トップ10を掲載しています。2004年版は日本語を含む各国語版が提供されていますが、2007年版は現在のところ英語版のみが提供さ

第0回 その気になった客を逃さないフォーム設計術 現実の店舗や窓口では、目の前にいるお客が困っていればすぐにわかるし、同じトラブルが重なれば問題が起きないように施策をとる。しかし、ウェブサイトを作っているときにはお客は目の前にいないし、公開後にお客の対応をするのはウェブサーバーやスクリプトという機械だ。そのため、現実の商売では当然のように行っている接客ができない、いや忘れてしまってはいないだろうか？ 今木 智隆（株式会社ビービット） ウェブサイトの「ユーザビリティー」という言葉は、当たり前のように耳にする機会が増えてきた。しかし、その知名度の広まりとは裏腹に、「何をどうすれば成果に結びつくのか」「実践に落とし込むにはどうしたらよいのか」について具体的に取り上げられることは少ないようだ。 この連載では、主に「会員登録による顧客獲得を行う企業サイト」をモデルとして、想定される次のようなユーザー

This browser is no longer supported. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

この連載では，エンジニアの視点から使いやすさを考えています。今回はユーザー登録画面などに代表される，フォームを使った入力画面について考えてみたいと思います。 なぜこのテーマを選んだかというと，フォームを介して利用者からデータを受け取って処理をして返すという一連の処理が，ウェブサイトのバックエンドの処理やデータ形式などによって変化しやすく，プログラマやエンジニアの作業がもっとも使いやすさと関係しやすい分野ではないかなあ，と思っているからです。こうした部分はエンジニアが使いやすさに寄与しやすい部分であり，もっと言えば，使いやすさを向上させるに当たって，エンジニアにしかできない事柄がたくさんある部分だってことになると思います。 今回は「ユーザー登録ページ」を例に，フォームにおける使い勝手を考えていきたいと思っています。その理由としてまずは，筆者が勤務する株式会社はてなにもユーザー登録画面があり，