なんでもブログ

久々にハーデスを打ってみる。
朝一でサクサクと3連したので高設定を掴んだかといい気分に。
ただ３回ともケルベロス。
しかも50G、60G、70Gのショボさ。
まぁこれはケルベロスならしかたない。

で、600ハマってGOD揃い降臨。

が！！

ケルベロス　60
ケルベロス　70
ペルセポネ　50
最終的には390ゲーム、1157枚という激烈ショボい内容に。

ハーデスのGOD揃いならケルベロス３回で終了という可能性があるのは分かっていたが、
今まではそれでもしっかりハーデスやペルセポネで乗ってくれていたので、
ここまでひどい内容は初めて。

もうGODシリーズ怖い・・・

三菱重工業の国産初のジェット旅客機・MRJ
別に飛行機や戦闘機に興味はないのだけど、
国産初のジェット機というだけあって少なからず興味を惹かれた。
ぜひ頑張ってほしいなぁと思っていたけど、５度目の延期って・・・。
最大で20年遅れる可能性もあるって・・・。

こんなんで本当に大丈夫なのかなぁと思ってきたのは私だけなのか？
もちろん安全性は大事だろうけど、そもそもこんなに延期しないといけないような代物を売ろうとしていたことがおかしい気がするんですが。

１度や２度ならまだしも５度目って。
こんなんじゃ６度目、７度目も十分あり得るわけで。
もはや、どこぞの大手銀行のシステム統合みたいに終わりの見えないものを作っているんじゃないかと思えてきた。

パチンコGANTZを初打ち

ハマればハマる出玉が増え続ける超GANTZボーナスが魅力的ですが、
そう簡単にはハマり続けられません。だって確変中なんですもん（＾＾；
しかも、そう簡単には超GANTZボーナス来てくれません。
継続率65％しかないのに、当たり配分の内、超GANTZボーナスは35％しかないので、
超GANTZボーナス引く前に確変終わります。
隣の台では、通常時にぬらりひょん倒して7当たり。
120ラウンドまでハマって、１激12000発オーバーしてました。
まぁそんなことが起きるのは極稀だと思うので、期待しすぎは禁物ですね。

通常時に関しては、もう何が来たら期待していいのかサッパリです。
超転送がかなり熱そうに感じる演出ですが、実際はかなり空気。
何回来たか分からないくらい見ましたが、１回も当たってくれませんでした。

あとGANTZフラッシュも空気。
雑誌では期待度約60％ってなってましたが、３回きて３回とも外れ。

どデカ保留も文字が白のままであれば完全に空気。
赤文字のどデカ保留が１回来ましたが、これは当たった。

疑似連（行ってくだちい）３回（赤）も完全に空気。

もう最後には何が来ても「ハイハイ、空気空気」って感じで全く楽しめず。

単発当たりが多い上に、確変入っても即バトル負けて実質単発ってこともかなり多いです。
超GANTZボーナスが引けないとかなりきつい戦いになること間違いなし。

なお、何が来たら当たるんだとよく分かる動画↓

SQLインジェクション、クロスサイトスクリプティング（XSS）
この2つはよく聞く言葉。
で、今回新たにHTTPヘッダインジェクションというのが存在することを知った。

HTTPヘッダインジェクションで検索すれば情報は沢山出てくるので、詳細についてはそちらを参照してもらうとして、
今回ハマったのはリダイレクトしか行わないWebAPIでHTTPヘッダインジェクションを指摘されたこと。

レスポンスヘッダに改行コードを埋め込むことで任意のスクリプトを実行させられるようになるとのことだが、試してみてもスクリプトが実行されない。
普通に次の画面へリダイレクトされるのみ。

で、調べてみたところ、リダイレクト（HTTPステータスが502）の場合は、
ブラウザがレスポンスボディを評価しない仕様になっていることが判明。
なので、スクリプトを埋め込んでも何も起きなかった模様。

だからと言って放置するわけにもいかないので、改行コードをエスケープして対応して問題解決。

WildFly + Spring な環境のWebアプリケーションにおいて、
セッションIDのCookieにSecure属性を付けるのにハマったのでメモ。

まず、WildFlyの設定で行えると思い調査。
まさしくこちらと同じ環境でやりたいことも一緒。
http://qiita.com/tsubu-mustard/items/651320e83497371947fc
こちらで紹介されている通り、standalone.xmlを修正してみるも改善されない。

WildFlyで調査を進めていると、web.xmlでも出来ることが判明。
http://stackoverflow.com/questions/31163475/how-to-activate-secure-cookies-in-wildfly
が、web.xmlを修正しても改善されない。
当然、standalone.xmlとweb.xmlを一緒に直しても改善されない。

で、もしかしてSpringで設定できるのか？と思い調べてみると正解。

今回のWebアプリではSpringセッションを利用している。
そのせいなのか、それともSpringを使っている時点でそうなのかは分かりませんが、
SpringがセッションIDをセットしてくれているようです。
http://docs.spring.io/spring-session/docs/current/reference/html5/guides/custom-cookie.html

一般的には、セッションIDといえばJSESSIONIDの名前で登録されているのが普通と思っていましたが、なぜかSESSIONで登録されているのを見て見ぬふりしていましたが、SpringがデフォルトではSESSIONという名前でCookieに登録されているようなので納得。

で、本題のSecure属性を付ける方法ですが、
上記サイトにはHTTPS接続であれば自動的にsecure属性を付けると書いているだけです。
今回はHTTP接続でもsecure属性を付けたいので、DefaultCookieSerializerを調べてみたところありました。

今回追加修正したメソッドは下記の通り。

        @Bean
        public CookieSerializer cookieSerializer() {
                DefaultCookieSerializer serializer = new DefaultCookieSerializer();
                serializer.setCookieName("SESSIONID");
                serializer.setUseHttpOnlyCookie(true);
                serializer.setUseSecureCookie(true);
                return serializer;
        }
       ※setCookiePath、setDomainNameは指定なし。デフォルト設定に任せてます。

（2017/11/17追記）
CookieのKeyに予約語（PathやDomain等）が使われていると、DefaultCookieSerializerでエラーが発生します。
下記記事の方法で対応しました。
Cookie name "Path" is a reserved token