第4回 Webアプリとスマホアプリの同期 | gihyo.jp
テーブル名を文字列で格納するなどスマートでない設計ですが、DUPLICATE以外の動作はシンプルです。 テーブル名で示されたテーブルを、プライマリキー値で検索し、そのデータに基づいてスマホ側で実行されるSQL文を生成しています。 図4 更新情報テーブルのレコードからスマホ用SQL文を生成 なお、DELETEとRESTOREは特別な更新種別です。DELETEは鉄道事業者・路線・駅の廃止または長期休止を表し、RESTOREはいったんDELETEされた鉄道事業者・路線・駅の長期休止からの復活を表しています。しかしこれらはいずれも、UPDATEで代替可能です。両者はともに、対象テーブルのenabledカラムが変更された、という意味であり、他のカラムの更新と等価だからです。 ただし、駅の休止や復活は、ユーザデータの無効・有効に直結する重要な項目です。これは、このupdatesテーブルのメンテナーにと
高木浩光＠自宅の日記 - 無責任なキャリア様に群がるIDクレクレ乞食 ―― 退化してゆく日本のWeb開発者
馬鹿じゃないのか。このようなセキュリティに関わる情報公開ページは https:// で提供する（閲覧者が望めば https:// でも閲覧できるようにする）のが当然なのに、携帯電話会社ともあろうものが、そろいもそろってこんな認識なのだ。 （8月2日追記: ソフトバンクモバイルについては「7月27日の日記に追記」参照のこと。） それをまた、ケータイWeb関係者の誰ひとり、疑問の声をあげていないことがまた、信じ難い。何の疑問も抱かずにこれをそのまま設定しているのだろう。 こんな状態では、ケータイWebの運営者は、DNSポイゾニング等で偽ページを閲覧させられても、気付かずに、偽アドレス入りの帯域表を信じてしまうだろう。 つまり、たとえば、example.jp というケータイサイトを運営している会社が example.co.jp であるときに、攻撃者は、example.co.jp のDNSサーバに
高木浩光＠自宅の日記 - ケータイWebはそろそろ危険
■ ケータイWebはそろそろ危険 これまでの背景と最近の状況変化 「安全なWebサイト利用の鉄則」にある通り、フィッシングに騙されずにWebを安全に使う基本手順は、（パスワードやカード番号などの）重要な情報を入力する直前に今見ているページのアドレスを確認することなのだが、しばしば、「そのページにアクセスする前にジャンプ先URLを確認する」という手順を掲げる人がいる。しかし、それは次の理由で失当である。 ジャンプ先URLを確認する手段がない。ステータスバーは古来よりJavaScriptで自由に書き換えられる表示欄とされてきたのであり、ジャンプ先の確認に使えない。 ジャンプ先URLを事前に確認したとしても、それが（任意サイトへの）リダイレクタになっている場合、最終的にどこへアクセスすることになるか不明。 そもそも、アクセスする前から、アドレス確認の必要性を予見できるとは限らない。普通は、アクセ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
