Furyu
[フリュー公式]

Tech Blog

フリュー株式会社の技術ブログです

2017年07月24日

Spring Securityを使ったAjax通信について

こんにちは。フリューのジョンです。

最近はVue.jsがあればテンプレートエンジンなんていらないと思いながらThymeleafを触っています。

さて、今回はSpring Securityを使ったAjax通信についてハマったのでそれの解消方法について書かせていただきます。

具体的には、Spring Securityの機能の一つである、クロスサイトスクリプティング防止機能でハマりました。

クロスサイトスクリプティングの説明については、今回省きます。他サイトを参照してください。

概要

環境は以下のとおりです。

spring-boot 1.5.3.RELEASE
spring-boot-starter-security 1.5.3.RELEASE
Thymeleaf 3.0.6.RELEASE

結論から言えば、Spring Securityを導入すると、単純なPOSTアクセスをすることができなくなります。
理由としては、認可した場所からのリクエストであることを検証するためにトークンが必要になるためです。その為、これを解消するには以下の方法があります。

  • Formにトークンを付ける。
  • Cookieにトークンをつけて、リクエストヘッダにトークンをつけて送信する。
  • GETで対処する  ← ダメゼッタイ、ユルサナイ

上手くいかない例

まずうまくいかない、例を見てみましょう。

この状態でボタンを叩くと以下のような画面になります。

spring-security-postが上手くいかない例

Formにトークンを付ける

これはSpring Security+Thymeleafを導入すると簡単に対応できます。

具体的にはFormのaction属性をThymeleafのものにします。

Formタグを見てみると自動でinput[type=’hidden’]が追加されているのがわかると思います。

spring-security-form送信(上手くいく例

Ajaxにする場合、このinput[name=’_csrf’]の値をJavaScriptで取得すれば良いのです。しかし、この方法はFormタグがなければ成り立ちません。

FormがないAjaxのpost通信をするためには、以下の方法があります。

Cookieにトークンをつけて、リクエストヘッダにトークンをつけて送信する

Spring Securityでは、Cookieにトークンをつけることができます。そのためには、CookieCsrfTokenRepositoryを使用します。

withHttpOnlyFalseとしているのは、HTTPでもCookieにトークンをつけてもらうためです(デフォルトはHTTPSだけにしかCookieは付いてきません)。リクエストを見てみると、以下のようにXSRF-TOKENという名前のCookieがついているのがわかります。

spring-security-cookieが付いている

このCookieの値をJavaScriptで読み込み、リクエストヘッダにX-XSRF-TOKENをつけます。

これによりAjax通信が可能になります。しかし、いちいちCookieをとってリクエストヘッダに渡すのは面倒ですね。

Axiosというライブラリではそれを解消してくれます。内部でcookie()を見て、リクエストヘッダに追加してくれているのです。

非常に便利ですね。

Cookieの名前、ヘッダの名前は、デフォルトの値ですので、変更可能です。もちろんAxiosの方も変更が可能です。

AxiosのFormData通信

ちょっと話が変わりますが、Spring SecurityでのAjaxのlogin機能を実装しようとした時、すこし、ハマりましたので追記します。

Axiosで通信するとデフォルトはJsonでの通信になります。しかし、loginには、FormDataでパラメータを渡さなければいけません。

実装方法としては、以下のようにAxiosのpostメソッドの第3パラメータに変換メソッドを追加してあげます。

まとめ

Spring Securityを使ったajax通信は少しだけ工夫が必要です。
しかし、その設定は本当に少しだけです。
ここではSpring Securityの機能自体について触れませんでしたが、Spring Securityは本当に素晴らしいので、ぜひ使ってみてください。

そして、Ajax通信だけのために、jQueryを使うのは止めましょう。Axiosを使ってみましょう。(個人の感想です)

最後に

弊社は、Springを実践利用してバリバリコード書きたいエンジニア募集中です!

詳しくはこちら


2017年07月24日

Doma2を使った複数データベースアクセス

こんにちは。フリューのジョンです。

個人的意見ではありますがSpring Data JPAのほうが好きですが、今回はDoma2を使った複数データベースアクセスを実装して躓いたので書かせていただきたいと思います。

概要

環境としましては以下のようになります。

spring-boot 1.5.3.RELEASE
doma-spring-boot-starter 1.1.0
spring-boot-starter-aop 1.5.4.RELEASE

複数のデータベースアクセスの具体的な要件は以下になります。

  • データベースアクセスをするメソッドに対して、アノテーションを付けてアクセス先を切り替える
  • アノテーションを付けていない場合はデフォルトのデータベースにアクセスする
  • 接続先はDomaの基本に合わせて、DataSourceの切り替えをしたい

以上の要件を満たすために、AbstractRoutingDataSourceとAnnotation、ThreadLocalを利用しました。

実装については、Qiitaの「Spring Bootで複数データベースを扱うウェブアプリケーションのサンプル」の記事を参考にさせていただきました。

実装

Daoには実装は加えません。

肝になるのは、AbstractRoutingDataSourceです。AbstractRoutingDataSourceはSpringのJDBCパッケージの中にあります。
このクラスを実装したモノを、Domaのconfigを継承したConfigrationクラスが返却することで対応が可能です。

ここで、AppConfigはルートである必要があります。(もしかすると、そうでなくてもいける方法があるのかもしれませんが、私が調べた限り出来ませんでした……)

接続先を保存するためにstaticでデータを作っておきます。ThreadLocalですので取扱には注意です。

メソッドに必要なアノテーションは以下のように設定します

アノテーションの実装は以下になります。
アノテーションがあるメソッドが動く前に接続先をHolderにセットして、動作した後に開放しています。

接続先はenumで持つようにします。

ここまでで実装終わりです。

使い方

以下のようになります。

まとめ

今回はアノテーションを使った振り分け方を行いましたが、リクエストパラメータやCookieを使って振り分けるというのも良いかと思います。

Doma2がConfigを勝手に参照してくれるのは、とても楽ですね。設定だけでうまくいきました。

最後に

弊社は、Springを実践利用してバリバリコード書きたいエンジニア募集中です!

詳しくはこちら


2016年11月21日

sakata

弊社フリューはJJUG CCC 2016 fallのゴールドスポンサーになりました!

Hello world! コンテンツ・メディア第1事業部のjyukutyoこと阪田です。

弊社フリューはJJUG CCC 2016 fallのスポンサーになりました!

http://www.java-users.jp/ccc2016fall/

JJUG CCCは毎年2回、春と秋に開催する日本最大のJavaコミュニティイベントです。Java関連の技術や事例に関する良質なセッションが行われ、また異なる分野で活躍するJava技術者が一堂に会する場ともなっています。

スポンサーにはダイヤモンド、プラチナ、ゴールド、ブースと種類があり、フリューはゴールドです。

CCCでは弊社から2セッション!

弊社では2セッションでスピーカーをします。

  • 13:30-14:20
  • ルームE
  • 10年運用している画像サービスでのJavaの活用と今後の展望

こちらは、盛岡が弊社のサービス開発について話します。私がCCCの2016 Springと2015 Springで話した弊社のサービスについて、別の観点から話します。盛岡はこのサービスを初期(10年前!)から担当しており、ユーザの拡大につれて変遷してきたアーキテクチャや運用、チーム構成などさまざなまリアルが聞けます!

  • 18:30
  • ルームI
  • バイトコードが君のトモダチになりたがっている

こちらは私のセッションです。Javaにおけるバイトコードって何?というところからそこを変更するライブラリの紹介、実例としてJava Agentでのバイトコード操作といったことを話します。

ぜひ私たちのセッションに足をお運びください!

エンジニア募集中

弊社では他にもScalaMatsuri、Scala関西 Summit、try! Swiftなどのスポンサーをしています。それもこれも最終的にはエンジニアの採用のためですね。京都での開発業務(Webアプリ、iOS/Androidネイティブアプリ)に興味のある方はぜひご連絡ください。

http://mobile-career.furyu.jp/

京都以外に渋谷にもオフィスがあり、開発をしています。関東の方もぜひご連絡ください。


2016年11月15日

JMockitを使ってテストを書いていて困った点

こんにちはフリューのジョンです。普段はJMockitを使ってテストコードを書いているのですが、今回は、そのJMockitを使ってテストを書いていて、困った2点を書きたいと思います。

  1. すでに@Injectableで書いてあるクラスをモックしたい
  2. FileOutputStreamをJMockitでMockUpを使ってコンストラクタをモックする

この2つです。例えば以下のようなメソッドをテストした場合はどうすればよいのかを書きます。

環境

JDK 1.8.0_65
JMockit 1.18
JUnit 4.12

解説

1. すでに@Injectableで書いてあるクラスをモックしたい

これは、テスト対象のクラスに@Resourceがあるため、@Injectableを書いているため起きます。
@Mockedを引数に書いてつかうこと、MockUpを使ってやることもできません。(すでにモックされています、というエラーが出ます)

対応としては、ソースコードの①にある通り、Expectationsにクラスを渡すことで、Fileのモックを対象のExpectations内で書くことができます。
今回はコンストラクタをモックしたかったので、返り値となるFileのモックオブジェクトを@Injectableで定義してExpectations内で使用しています。

2. FileOutputStreamのコンストラクタをモックする

これはFileOutputStreamに@Mockedをつけてモックすることができないために起きます。(@Mockedは使えません、代わりに@Injectableや部分モックを使ってくださいというエラーが出ます)

対応しては、ソースコードの②にある通り、MockUpで記述します。
closeメソッドもモックしているのはtry-with-resource文にて自動的にcloseメソッドが呼ばれるためです。(もちろん無いとテストが落ちます)

ここで気をつけることが、一点あります。
実際のコードでは、ファイルを引数としたコンストラクタを使用していますが、テストコードでは異なるコンストラクタをモックします。理由としては以下になります。

To mock the target “FileOutputStream(File)” constructor, JMockit must replace the internal call to another constructor (“this(file, false);”) with an innocuous “super(…)” call. This is because, inside a constructor, the JVM forbids extra calls before a “super(…)” or “this(…)” call is complete. So, in this case calling “proceed()” from $init has no effect since there is no remaining code in the original constructor.

https://groups.google.com/forum/#!topic/jmockit-users/EvTuJKTecDk

意訳すると、以下のようになります。

JMockitでFileOutputStream(File)をモックするためには、内部でsuperによってFileOutputStream(File, false)を呼び出しているのでそちらをモックしてください。 理由としては、JVMによってsuper(…)またはthis(…)の余分な呼び出しが解消されます。だから、MockUpのproceed()で呼ばれる$initは存在しないコンストラクタを参照してしまうのです。

まとめ

JMockitは複数の書き方ができますが、それ故にわからなくなることも多いと思います。
みんな細かい部分で詰まっていると思いますので、ソースコードを共有していければ解消できるかもしれないですね(切実)


2016年10月13日

sakata

JavaOne 2016 サンフランシスコに参加しました!(その4) #javaone #j1jp

Hello world! コンテンツ・メディア第1事業部のjyukutyoこと阪田です。

前回はコレクションのセッションについてのレポートでした。今回はクラスローダーのセッションについてレポートします。

Join the War on ClassLoader Leaks

スライドはこちらにあります。

https://static.rainfocus.com/oracle/oow16/sess/1461358415846001E0TZ/ppt/Classloader%20leaks%20public.pptx

内容

java.lang.OutOfMemoryError(OOME)はみな出会ったことがあるだろう。Java 8になってPermGen spaceとは出なくなったが、代わりにMetaspaceが出るようになった。ローカルでの開発時にも、継続的デプロイでもOOMEは出る。このセッションのアジェンダは次のようなものだ。

  • OOMEは何を意味するのか?
  • OOMEはなぜ起こるのか?
  • どこでリークするのか?
  • どのように避けるのか?
  • OSSの例
  • トレーニング

OOMEは何を意味するのか?

JVMのメモリはヒープとPermGen/Metaspaceとスタックである。スタックはスレッドごと、ローカル変数やメソッドのパラメータを持つ。ヒープはオブジェクトのインスタンスを持つ。PermGen/Metaspaceはjava.lang.Classインスタンスなどを持つ。PermGenという名前はJava EEとクラスのアンロードができる前に名付けられた。Java 8でMetaspaceへ置き換えられた。OOME PermGen space/Metaspaceは、あまりに多くのクラスをロードしたときに起こる。

OOMEはなぜ起こるのか?

OOME PermGen space/Metaspaceが起こる原因は次の2つが考えられる。

  1. アプリケーションが大きすぎる。Java 7までは-XX:MaxPermSize=256Mなどと指定すればよい。Java 8ではMetaspaceは自動的に増えていく。
  2. java.lang.Classインスタンスが再デプロイ後にガベージコレクトされない

参照の型は次の4つがある。

  • 強い参照:到達可能なときは決してGCされない
  • ソフト参照:OOMEになる前にGCされる
  • 弱い参照(WeakHashMap):強い参照とソフト参照がないときにGCされる
  • ファントム参照:GCは妨げない

GCの到達可能性は以下の図のようなことである。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-05-17-40-30

再デプロイでは、新しいWARファイルをデプロイすれば前のクラスローダはGCされる。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-05-17-43-30

クラスローダーの参照は次の図のようになる。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-05-17-44-55

どのようにリークが起きるのか。GCルートからクラスローダへ到達可能だと、クラスローダをGCすることができない。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-05-17-45-38

どこでリークするのか?

Tomcatなどアプリケーションサーバのバグだ。他にCommons LoggingやLog4Jなどロギングフレームワークのバグ、Bean Validation APIやUnified Expression Languageのバグといったこともある。

GCルートでも起こる。まず、システムクラスローダによってロードされるクラス。JDKのクラスにおけるstaticフィールドで起こる。ライブスレッドではローカル変数、メソッドのパラメータのスタック、java.lang.Threadインスタンスで起こる。

システムクラスでは、java.sql.DriverManagerやBean introspectionのキャッシュ、シャットダウンフック、カスタムでデフォルトにしたAuthenticator、カスタムのセキュリティでのProvider、カスタムMBean、カスタムのThreadGroup、カスタムのプロパティエディタ…最初の呼び出し元でのcontextClassLoaderへの参照などで起こる。

DriverManagerをもう少し詳しく見てみよう。たとえばMySQLのJDBCドライバを使うときはこうするだろう。

com.mysql.jdbc.Driverクラスにはstaticイニシャライザがある。

registerDriver()メソッドは以下のようになっている。

このregisterDriversという変数は、以下のものだ。

図で表すと以下のようになる。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-06-16-55-03

そのため、コンテキストのシャットダウンで以下のように書かなければ、リークしてしまう。

スレッドもここで止めておかなければならない。次のようにスレッドを実装するのは悪いアイデアだ。

止められるようには以下のようにする。

このことは、次の記事に紹介されている。

Heinz Kabutz / Java Specialists’ – The Law of the Blind Spot

次にThreadLocalについて考えてみよう。次のように実装してはならない。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-06-17-09-13

ThreadLocalのJavaDocには以下のようにある。

Each thread holds an implicit reference to its copy of a thread-local variable as long as the thread is alive and the ThreadLocal instance is accessible; …

各スレッドは、スレッドが生存していてThreadLocalインスタンスがアクセス可能である間は、スレッド・ローカル変数のコピーへの暗黙的な参照を保持します。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-06-17-13-40

プールされたスレッドではスレッドはクラスローダより長生きする。ThreadLocalはThreadGlobalになる!

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-06-17-17-35

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-06-17-18-20

ThreadLocalMapのJavaDocには以下のようにある。

However, since reference queues are not used, stale entries are guaranteed to be removed only when the table starts running out of space

(私訳)しかしながらリファレンスキューが使われないので、テーブルが容量不足になり始めたときだけ失効したエントリが削除されることが保証されます。

参照を含んだカスタムの値は、staticなThreadLocalであればリークし、そうでなければ予測されていないGCとなる。カスタムのThreadLocalであればリークしない。

ThreadLocalはクリアするようにしよう。

実際には、多くのOSSライブラリが違反している。

どのように避けるのか?

リーク防止のライブラリがある。アプリケーションサーバ非依存、Tomcatよりも多くをカバーしており、ログで警告を出力、ライセンスはApache 2ライセンスだ。実行時の依存は0で、設定は必要ない。Mavenであれば以下のように依存ライブラリを追加する。

これはServlet 3.0以降用だが、2系のものもある。

OSSの例

Bean Validationの1.0.0.GAでは以下のようになっていた。

(私訳)List<ValidationProvider>はキーであるクラスローダに強い参照を持っている。JPAのCachingPersistenceProviderResolverと同じモデルを使うようにして。

jyukutyo調査

Bean Validationの1.1.0.GAではこのクラスは次のようになっています。

providersPerClassloader.put( classLoader, new SoftReference<List<ValidationProvider<?>>>( providers ) );とあるので、ソフト参照を使うようになったようです。

JPAのCachingPersistenceProviderResolverクラスも調べてみました。

その他のOSS

javax.el.BeanELResolverやorg.apache.cxf.transport.http.CXFAuthenticator、com.sun.star.lib.util.AsynchronousFinalizerも該当する。

トレーニング

Eclipse Memory Analyzer(MAT)を使おう。

http://www.eclipse.org/mat/

次のオプションをつけてアプリケーションを実行しよう。

感想

最後に出てきた、MATについてはこのブログで私が記事を書いています。

ヒープダンプをEclipse Memory Analyzerで解析しよう!

セッションとしては非常におもしろかったです。とくにOSSの実例を挙げながらリークの原因を解説する箇所ではとても興奮しました。こういう内容のセッションはJavaOneだと他にもいろいろとあります。なかなか普段の勉強会でこの分野を扱っていることは少ないと思いますので、興味がある人にはJavaOneはとても楽しめるカンファレンスです!