東京メトロと富士ゼロックスのサテライトオフィスサービスを利用してきた


富士ゼロックスと東京メトロが実証実験を行っている、サテライトオフィスサービスを利用してみました。

サテライトオフィスサービスとは何か。

街中の一角に壁に囲まれたスペース内に電源とディスプレイとWi-Fiが提供された個室サービス。
こちらのサービスでは現在は東京メトロの地下鉄、一部駅の設置されたスペース(新宿だけ新宿野村ビル内に設置)となっていて、それぞれ時間貸しで利用できます。最低単位は15分/枠で、2018年11月現在は1枠200円(税別)です。

現在スペースが設置されている場所(主に駅構内)

今回は縁あってサービスの利用権をいただけたので利用してみました。

スマートフォンゲームで利用されているフォント

数多くのスマートフォンゲームが日々リリースされていますが、ゲームも基本システムが似ているものから独特のものまで様々。もちろんUIもそれぞれのゲーム毎に特徴が異なるわけですが、最近はゲーム内の世界に合わせてやや特徴的なゲーム内フォントを用いることも増えてきてます。
そんなわけで、いくつかの代表的なゲーム(筆者の観測内)で利用されているフォントをいくつかピックアップしてまとめてみます。

パズドラ

くろかねEB (フォントワークス)

モンスターストライク

コミックレゲエB (フォントワークス)

グランブルーファンタジー

ニューシネマB D (フォントワークス)




Fate/Grand Order

スキップB (フォントワークス)



シノアリス

パールL (フォントワークス)




白猫プロジェクト 


スキップD (フォントワークス)

プリンセスコネクト!Re-dive

ハミングD (フォントワークス)

マギアレコード 魔法少女まどか☆マギカ外伝

NUDモトヤF4アポロ5 (モトヤフォント)


NGINXのSecureLinkモジュールを使ってみる

突然ですがSecureLinkモジュールとはなんぞや、というところですが、簡単に言うと、サービス登録時のメールアドレス確認で、下記の様なメールで見たことがあるような、一定時間のみ有効な時限式URLの認証機能を提供するモジュールです。


通常このような機能を作成する場合、URLの発行、利用期限の管理含め、基本的にはいわゆるPHP、Ruby、Python、Javaなどのサーバサイドアプリケーションで実装して利用しますが、このSecureLinkモジュールはこのうちの利用期限管理(URLの正当性検証)をnginx側で処理してくれるものになります。
そのため、時限式URLに絡めて、事前に入力されたユーザー情報を参照して〜といった、上記のメール画像のような機能には適さないですが、例えば、特定の静的ファイルを時限式URLで不特定多数に配布したい、といった場合であれば有効であると言えます。


長い前置きはさておき、以下からは実際に設定していきます。



まず、このモジュールはnginxの標準モジュールとしては提供されていないため、nginxのconfigure時に--with-http_secure_link_moduleオプションを付けてビルドし、有効化します。

一番簡単な設定方法としては、モジュールの公式ドキュメントこちらのページ(by レンタルサーバー・自宅サーバー設定・構築のヒント)で紹介されているとおり設定すると基本的に動きます。

で、同じ内容で紹介してもあまり芸がないので、今回はほんの少しだけトリッキーな設定(ただの応用)での構築をここで記載してみます。

まず、構成を下記の様に設定するものとします。

パス設定
/var/www/example.com/public
└ドキュメントルート
/var/www/example.com/secure
└セキュアファイル設置場所


URL
https://example.com
└通常URL
https://example.com/secure
└セキュアリンクURL


通常の設定

ここまでの設定で、通常設定すると下記の様な設定になります。
server {
    root    /var/www/example.com/public;
    index   index.html;
    # SecureLinkアクセス用URI
    location /secure/ {
        alias /var/www/example.com/secure;
        # 公開鍵のパラメータ k=公開鍵&t=タイムスタンプ のパラメータを与える設定
        secure_link $arg_k,$arg_t;
        # 公開鍵レシピ
        secure_link_md5 YOUR_SECRET_KEY_WITH$uri?$arg_t;
        if ($secure_link = "") {
           # 認証NGの場合404を返却
           return 404;
        }
        if ($secure_link = "0") {
            # 有効期限切れの場合は403を返却
            return 403;
        }

        try_files /$request_uri =404;
    }
}
上記設定では、例えば https://example.com/secure/secret.html?k=OqjJ-smKxgnNTCGYz78TOg&t=1531815176 というURLにアクセスすると、パラメータkの公開鍵とtのタイムスタンプがそれぞれ正しければsecret.htmlのファイルを閲覧することができます。
/secure/パス以下は、ドキュメントルート外の/var/www/example.com/secureを参照したいので、alias で別途パスを指定してます。(ここでrootディレクティブで指定すると、/secureの参照先が/var/www/example.com/secure/secure 以下を参照する事となり、恐らく想定した通りのパスを見てくれません)

セキュアリンクモジュールを使用した場合、パラメータまで一致していて初めてアクセスできるので、これらのURLパラメータを削除して、直接 https://example.com/secure/secret.html にアクセスしても、secret.htmlは閲覧できません。
が、今回はもうちょっとURLをそれっぽくしたい


セキュアリンクのURLをカスタムしたい

https://example.com/secure/OqjJ-smKxgnNTCGYz78TOg/secret.html?t=1531815176

というURLのフォーマットにしたいと思ったので、下記の様にアレンジしてみました。

    # SecureLinkアクセス用URI
    location ~ ^/secure/(?<pubkey>[0-9a-zA-Z_\-]+)/(?<filepath>.+) {
        alias /var/www/example.com/secure;
        # Public key (URI)
        secure_link $pubkey,$arg_t;
        # Secret key
        secure_link_md5 "YOUR_SECRET_KEY_WITH$filepath?$secure_link_expires";
        # Invalid key
        if ($secure_link = "") {
           return 404;
        }
        # timeout
        if ($secure_link = "0") {
            return 403;
        }
        try_files /$filepath =404;
    }

今回のポイント

ポイントはlocationディレクティブを名前付き正規表現でパラメータを判定できるようにして、その名前(ここでは変数$pubkey)とURLパラメータ(t)をsecure_linkに引数として渡しているところです。
また、対象のファイルは同じく名前付き正規表現で変数$filepathに格納しています。

すべての認証が成功した際に、try_files$filepathを確認し、なければ404を返す様にしています。

Apple Musicのプレビュープレイヤーが公開されたので実際に使ってみる

Apple Musicのウェブプレイヤーが公開され、誰でもiTunesストアおよびApple Musicで配信されている楽曲の埋め込みができるようになったので使ってみました。

Apple Music マーケティングツール こちらのページからアーティスト名や楽曲名で検索し、Apple Musicで配信されている楽曲に関してはページ内埋め込みができます。
このように、埋め込み時のサイズを指定すると、その下に埋め込み時のプレビューが表示されます。

もしプレビューが表示されない場合は、配信が停止された場合か、下記ドメインのクッキーに対して許可が必要になります。

embed.music.apple.com

プレビューのしたに、埋め込み用のコードが表示されています。
現在は「プレビュープレイヤー」用のコードが表示されていますが、他に「バッジ」「Text Lookup」「App Icon」などの方法によるリンクも設置できるようになっています。

下記は私が個人的に好きなアーティストさんのアルバムを表示したものです。


アルバムに入っている特定の楽曲を指定した場合は下記の様になります。(トラック9のInternet Cityを指定)


一部、プレビュープレイヤー(埋め込み型プレイヤー)では配信できない楽曲もあるらしく、その場合はプレイヤーを埋め込んだ場所に下記の様に表示されます。
この場合は仕方がないので、リンクで対応する必要があります。(リンク先では表示、プレビュー可能でした)


埋め込み型ウェブプレイヤーは基本的にはiTunesのプレビュー試聴が出来る状態です。
実際にApple Musicで試聴するにはiTunesが必要です。

Bloggerで独自ドメイン+SSLが使えるようになっていたので設定にした


このブログは元々、blog.anoncom.net という名前でホストし、自分でホストしているVPS上でWordpressを用いて運用していました。

しかし元々アクセス数の少ないブログ+その他サービスすべてを趣味程度で借りてるVPS1台で運用するには少々厳しくなってきたので、ブログだけを他のVPSに移し、Wordpress+Kusanagiで運用してみたりもしましたが、やはり管理が厳しい。

と諦めて、外部ブログホストサービスとして現在のBloggerに移ったが、当時、こちらではSSL通信を利用するには独自ドメインでの運用はできなかった。
現在自分のサイトのセキュリティ設定を高める(そんな必要性のないサイトだが技術検証も兼ねて)ためHSTSにより、anoncom.net およびドメイン配下のサブドメインではすべてSSL接続を強制するように設定しており、 blog.anoncom.net を利用する以上、SSL接続を避けることはできない。

そこで、しばらくは Bloggerデフォルトのドメイン(anon5r.blogspot.com)上でSSL接続を設定して運用してきた。
しかし昨今、Let's Encrypt でもワイルドカード証明書の発行ができるようになるなど、ブログホストサービスでも気軽にSSL証明書が利用できるようになったので、Bloggerでもそろそろ対応するだろう……と思っていたところ、ググってみると今年(2018年)からできるようになっていたようだった。

詳しい設定方法は公式のヘルプ、または他のブログ記事などで既に書かれているのでそちらを参考にするとして、この場合どのような証明書が発行されるかについて、軽く書く。

Let's Encryptがワイルドカード証明書に対応したので早速発行してみる

昨年(2017年)後半頃より、フリーSSLプロジェクトのLet's Encryptで、ワイルドカード証明書の発行対応(特定のドメインやサブドメインに限らず、*.example.com のようなサブドメインへの対応)を宣言していました。
元々の計画では2018年2月下旬を予定されていましたが、品質向上のため直前でリリース延期となっておりました。

それが本日(3月14日、現地時間で3月13日)、ついにリリースされました

今回、ワイルドカード証明書の対応含め、ACME v2プロトコルにも対応になりました。
ワイルドカード証明書を利用するには、こちらのACME v2プロトコルの利用が必要になります。
また、これまでは証明書発行ドメインが向いているサーバ内に、認証サーバから接続し、それによって証明書発行時の所有者確認が行われていましたが、ワイルドカード証明書の取得にはDNS認証(DNS-01)を利用する形になります。

これまでと同様、コマンドラインからcertbotまたはcertbot-autoコマンドを利用して、証明書を発行するには以下の様にする必要があります。

ACME v2プロトコルを利用し、DNS認証を行うには、--manualオプションと、ACME v2プロトコル利用字のEndpoint (https://acme-v02.api.letsencrypt.org/directory)の設定が必要になります。

最近作ったアプリの話

先日、コナミ社の提供している コナステ のダウンロードコンテンツゲームを1クリックで起動できるアプリを作り、公開した。 Ks Game Launcher  ( Github ) 作った理由として、インストール時に作成されたショートカットをクリックするとブラウザが起動し、ログインし...