まだプログラマーですが何か？

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

以前のブログで「IBM Bluemix 内に用意された MySQL のデータベースサイズが小さすぎる」という不満をぶちまけました：
Bluemix のデータストア比較

このブログエントリを書いた頃は MySQL データベースはサイズが 10MB しかなく、お金を払ってもサイズを増やすことができませんでした（有料という選択肢がない）。まあ無料で使えるサービスだし・・・と諦めかけていたのですが、現在は状況が変わっているようです。

現在の Bluemix で MySQL データベースサービスを選択すると、このような画面になります：
2015012601


無料で利用できることは変わっていませんが、「プラン」という選択肢が用意されています。これらはそれぞれ以下の様な解説がついていました：
プラン解説
100Shared server, shared VM, 1MB memory, 10MB storage, 10 connections
200Shared server, shared VM, 1MB memory, 50MB storage, 10 connections
300Shared server, shared VM, 1MB memory, 500MB storage, 10 connections


データベースのサイズが 10MB, 50MB, そして 500MB から選択できるようになったようです。しかもいずれも無料！　それなら 500MB の 300 プラン一択、でいいのかな？

まあ、それでも現状は最大 500MB であって、デフォルトで 2GB まで無料で使える SQL DB と比べると貧弱ではありますが、10MB ではさすがにデモ用途以外で使い物にならなかったので、これは嬉しい仕様変更でした。




 
タグ ：
#ibm
#bluemix
#mysql
#datastore

WebView は、「ネイティブアプリに内蔵して使うブラウザ」です。

HTML5 をベースにするなどして、ネイティブアプリっぽい見栄えになったウェブアプリケーションであっても、利用するには URL を打ち込むか、ブックマークから選択するなどして（つまり、あくまでウェブページとして）利用することになります。

でも、そのようなウェブアプリは簡単にネイティブ化する方法があります。それが上述の WebView を使う方法です。WebView 自体はネイティブアプリケーションに組み込んで使う部品ですが、例えば「全画面 WebView だけを表示するネイティブアプリ」を作れば、（メニューの表示項目は何にするか、JavaScript を有効にするか無効にするか、最初に表示するページの URL はどうするか・・・などの設定項目はありますが）それはウェブブラウザでウェブページを見ているのと大きく変わりません。モバイルUIに対応したウェブページを比較的簡単にネイティブアプリ化する方法、といえます。

実際に自分も Android アプリ開発の中で使ってみる機会があったのですが、そこで想定外のことに１つ躓きました。それがタイトルにある「何も考えずに Android の WebView を使うと viewport が無視される」ということです。

これがバグ扱いなのか、何らかの理由があっての仕様なのかもよくわかりませんが、ともあれ何故か viewport は無視されてしまいます。

そしてそれが原因で、本来モバイルUIで表示されるべきページが、WebView を使って見た時だけモバイル端末と判断されず、PC 用の UI で表示されてしまう、という現象が起こってしまいます。

で、これを回避するための方法がこちらです。色々設定してますが、今回の肝は青字部分の２つ：
(1) 読み込み時にページ横幅を画面幅に無理やり合わせる
(2) ワイドビューポートへの対応
public class MainActivity extends Activity{
  public WebView webView = null;

  protected void onCreate(Bundle savedInstanceState){
      :
      :
    super.onCreate( savedInstanceState );
    setContentView( R.layout.activity_main );

    webView = ( WebView )findViewById( R.id.webView1 );

    //. JavaScript 有効
    webView.getSettings().setJavaScriptEnabled( true );

    //. リンクタップ時に標準ブラウザを使わない
    webView.setWebViewClient( new WebViewClient() );

    //. (1) 読み込み時にページ横幅を画面幅に無理やり合わせる
    webView.getSettings().setLoadWithOverviewMode( true );

    //. (2) ワイドビューポートへの対応
    webView.getSettings().setUseWideViewPort( true );

      :
      :
    //. 初期URLを指定してロード
    webView.loadUrl( "http://neppi.co/" );
  }

  :
  :
}

これで viewport を読んでいる時と同様に画面幅を強制的に変更して、本来の（モバイルUIの）ページに対応させることができました。

なお、WebView に関しては Android 4.3 以下の（WebKit ベースの）WebView については Google による脆弱性サポートが提供されなくなる、というニュースがありました（4.4 以上の Chrome ベースの WebView に対してのみサポート継続）：
Google No Longer Provides Patches for WebView Jelly Bean and Prior

4.3 以下ってまだ結構多いはず。そして WebView を使ってるアプリってどのくらいあるんだろ？？　その意味でも少し気になるニュースではあります。







 
タグ ：
#google
#webkit
#android
#webview
#viewport

ウェブサーバー（HTTP サーバー）を使う場合、なんらかのアクセスログを残すことになります。例えば Apache HTTPD の場合、デフォルトでアクセスログは /var/log/httpd/access_log に残ります。そのフォーマットは /etc/httpd/conf/httpd.conf 内で設定／カスタマイズできます。
2015012200


デフォルトの httpd.conf では、以下の様なログフォーマットが指定されています：
LogFormat "%h %l %u %t \"%r\" %>s %b common

暗号のような記述ですが、左から順にこのような意味があります：
　%h : 接続元のリモートホスト名（IPアドレス）
　%l : クライアント識別子（取得できない場合は - ）
　%u : 認証時のユーザー名（取得できない場合は - ）
　%t : 時刻
　%r : リクエストの最初の行の値
　%s : レスポンスステータス
　%b : 送信バイト数（0バイトの場合は - ）

このログフォーマットであれば、以下の様なログが取得できることになります：
192.168.1.101 - - [20/Jan/2015:11:32:29 +0900] "GET / HTTP/1.1" 200 -


最初の値がアクセス元のホストになります。つまりこれで（プロクシが使われている場合はプロクシのアドレスになりますが）どこからのアクセスがあったのか、という情報が分かります。


ところが、このアクセス元ホストが分からなくなる場合があります。それは HTTP サーバーがロードバランサ経由で使われていた場合です。サーバーの負荷軽減などの目的で、サーバーを複数台構成にしてロードバランサ経由で利用する、というケースは珍しくないと思います（クラウド環境によっては１台構成でもロードバランサ経由になることもあります）。ただその場合、この設定だとアクセス元ホストは必ずロードバランサの IP アドレスになってしまい、結果として常に同じホストからのアクセスがあったとログに記録されることになります。

これを避けるには httpd.conf をカスタマイズする必要があります。具体的にはこんな感じに：
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b common


%h の代わりに %{X-Forwarded-For}i という記述に変えました。この意味ですが、まず %{XXX}i という記述は「リクエストヘッダに含まれるヘッダー名 XXX の値」です。つまりこの記述は「リクエストヘッダに含まれる X-Forwarded-For ヘッダの値」をログに書き出すよう指示していることになります。

そしてリクエストヘッダの X-Forwarded-For ですが、これはプロクシやロードバランサなどのキャッシングサーバーに接続するクライアントの送信元 IP アドレスです。つまりキャッシングサーバーから見た時の %h の値がこのヘッダ値に入ってくるので、その値を取り出してログに記録すればよい、ということになるわけです。　そこで上記のような設定をすることでロードバランサ経由であっても、元のクライアントの IP アドレスを記録できるようになるのでした。

なお、この方法は HTTP プロトコルに限って有効です。HTTPS では暗号化によって HTTP ヘッダに送信元 IP アドレスが記録できるかどうか、ロードバランサによって変わってきてしまいます。お使いのロードバランサが HTTPS をサポートしているか、サポートしていない場合の対応方法などはお使いのクラウド業者に問い合わせる必要があると思っています。



 
タグ ：
#httpd.conf
#http
#httpd
#access_log

このページのトップヘ