オブジェクト指向におけるモデリングのアンチパターン

「このXXXは、YYYとしても使える」というようなのを作らない。


・・・こうネガティブなコンテキストで書くと、誰だってそんなことしないと言うだろうし、俺だってそう思ってるわけですが、いざコーディングしている時にふと、「おお！このオブジェクト（プロパティ、変数、なんでも）を使ってこんなこともできるのでは！まさに一石二鳥！」とか思ってノリノリになってたりするものです。少なくとも私はそうです。

が、一人二役とか一石二鳥とか考えるということは、すでに異なる2種類の何かがあるのが明解なのだから、それらはやはり別に設計しておくべきなんだと思います。たとえ、その時点の簡単な実装では同じに見えるオブジェクトでも、いずれは別の役割と振る舞いを持つんだろうと。

checkboxでチェックされてない場合は"false"とか送ってほしい

 、という場合のスクリプト。なんかもっと簡単な手はないのかね？単純なことを無駄に面倒にやってる気がして仕方ない・・・。

      <label>
        <input type="checkbox" name="dummy" class="checkbox-boolean" data-input-cls="foo-remove"> <span class="glyphicon glyphicon-trash"></span> Remove
        <input type="hidden" name="XXX" class="foo-remove form-control" value="false">
      </label>

 <script type="text/javascript">
    $(".checkbox-boolean").change(function(){
        var cb = $(this);
        $("." + cb.attr("data-input-cls"), cb.parent("label")).val(cb.prop("checked") ? "true" : "false");
    });
 </script>

※ ｊQuery、Bootstrap使用の状態。・・・もうちょっと状況を制限すればhiddenをクラスで指定することもないのか。

JSPのコンパイル時に非常に奇妙なエラーが出る

This static method of interface XXX can only be accessed as XXX

というような例外メッセージになる。

例えば、XXXインターフェースにyyyメソッドがあり、それをJSPでXXX.yyyと呼び出した場合。
その通りやってんだろうがよ！と怒りたくなる。つうか腹たつなもう。

解決策は、Tomcatのweb.xml、

<servlet>
        <servlet-name>jsp</servlet-name>
        <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
        <init-param>
            <param-name>fork</param-name>
            <param-value>false</param-value>
        </init-param>
        <init-param>
            <param-name>xpoweredBy</param-name>
            <param-value>false</param-value>
        </init-param>
  <!-- こっから -->
  <init-param>
      <param-name>compilerSourceVM</param-name>
      <param-value>1.8</param-value>
  </init-param>
  <init-param>
      <param-name>compilerTargetVM</param-name>
      <param-value>1.8</param-value>
  </init-param>
  <!-- ここまで -->
        <load-on-startup>3</load-on-startup>
</servlet>

「こっからここまで」を足したら直った。けど、今までEclipse上のTomcatでは1.7の指定で（JREは1.8だった）大丈夫だったのが解せない。1.7の指定が効いていなかったワケではなく、ちゃんとラムダとかはコンパイルエラーになってたのに。なんなんだ。


参考：
http://stackoverflow.com/questions/25360127/intstream-strange-error

クロスドメインでAjax、なおかつセッション情報も利用するなら・・・

クロスドメインでAjaxを使うのには、レスポンスヘッダーに

Access-Control-Allow-Origin:http://allowed-origin.test

てな感じで許可をつけてやらねばならないというのは前に書いた。

このオリジンというのはポート番号まででパスは不要、というか、リクエストヘッダーのOriginとして送られてきたものを（許可できるなら）戻すのが本筋のようだ。


で、自分がやりたいのは自サイト内部のHTTPからHTTPSへのクロスなのであり、そんなことをしたい理由はもちろん認証情報の取得だ。つまり、Cookieがいる。

が、クロスサイトなAjaxを上記で許可した場合、通信自体は許可されるが諸々の制限がついていて、Cookie、それからX-の拡張ヘッダ類は送られない。

受け取っていいヘッダを、

Access-Control-Allow-Headers:X-Foo,X-Bar

てな感じで書いてやらねばならない。これがないと、ｊQueryなんかがつけてくれるX-Requested-Withヘッダーなんかもつかない。


Cookieも送りたいので上記にCookieと書けばいいかというと、それではだめで、Cookieを送るには、XMLHttpRequestにwithCredentialプロパティをtrueで設定しないとならない。Cookieは認証に使われるからか、特別扱いなわけかね。

で、これを具体的に行う方法が、たとえばjQueryでは、こうなる。


jqTargetなるjQueryオブジェクトが、取得したコンテンツをロードしたい対象だとしたら、

$.ajax({
url: loadUrl,
xhrFields: {
withCredentials: true
}
}).done(function(data){
jqTarget.html(data);
});

通常なら、jqTarget.load(loadUrl);で終わるところだが。

（オリジンを許可してない場合、どっちにしろつながりもしない。この場合、ChromeのデバッガではOPTIONメソッドの履歴が残り、利用できる応答がないとかそういうことになってる。OPTIONなって使ってねーよ！と思うが、これはプリフライトと呼ばれる、クロスドメインのXMLHttpでのネゴシエート的なものの結果のようだ）




参考：

• https://developer.mozilla.org/ja/docs/HTTP_access_control
• http://dev.classmethod.jp/etc/about-cors/

クロスドメインのAjaxだとX-Requested-Withてついてくれないんですか？

そもそもこのヘッダ、なんでついてるのかもよく確認せず使ってましたが、jQueryがつけてくれてるだけなんですね。

で、自分の作ってたサイトで、http -> httpsでAjaxを使いたいのでAccess-Control-Allow-Originを使って通信したところ、X-Requested-Withがついてこないもので、これを見ていた自前のサーバーサイド検査 request.isXmlHTTP()が引っかかってしまった。

ただ、そもそもサーバーサイドの処理がjQueryに依存しているというのはおかしな感じがしていやだし、他にも微妙な問題がありそうなんで、Ajaxかどうか？の検査にはこのヘッダーを見るのではない代案を考えようと思う。

どうせ偽装可能なヘッダ情報なんだから、Refererとかでもいいのか・・・それとも、そもそもこんな検査にこだわらない（セキュリティの一助になればという思いだったが、もっと別の手を考える）方がいいのか・・・。

PHPって怖ろしいんだな・・・

http://d.hatena.ne.jp/ockeghem/20110905/p1

・・・こんなことがあるなんて。ちゃんとした出版社から出てる教科書なのに・・・。

って、まあ、このレベルをPHP開発者全員に当てはめたら怒られるんだろうけど。それに、JavaScriptの非同期通信を使った部分のセキュリティ確保については自分もよくわからないところが多く、それでアレコレ検索してたらこういうページにたどり着いたんだしね。

他人を笑えるほどわかってはいないか、俺も。まあ、だから俺は本は書いてないけど。

クロスドメインでAJAXをするにはAccess-Control-Allow-Origin

タイトルだけで書きたいことが終わってしまった。

さみしいからもう一度書こう。

クロスドメインでAjaxするには、HTTPヘッダーにAccecc-Control-Allow-Originで許可ドメインを指定する（プロトコルから）。

JSONPはセキュリティ上の危うさを感じるし何か無理矢理な感じがして好きになれない。ので、これを使おう。使おうと思っただけでまだ使ってないから細かいことは書けない。

まあ、やりたいことは、自前のWebアプリ内でHTTPSで応答するJSONをHTTPのページから普通に使いたいだけである。