CookieのSameSite属性とSecure属性について

初めまして。株式会社PRVENT開発部、バックエンドチームの横川です。
現在入社2年目で、普段はGoやRubyを書いて仕事してます。
今回はCookieSameSite属性Secure属性について紹介したいと思います。

なぜ書こうと思ったか

現在、『Mymonitor』という弊社のスタッフと取引先が利用するプロダクトのリプレースを進めており、Cookie初心者の自分がCookieを使ったログイン管理を実装しました。
そこで直面したエラーのおかげでCookieについて調べ上げCookieを完全に理解したので、今回直面したエラーの原因でもあるSameSite属性とSecure属性の挙動について記事にすることにしました。

そもそも Cookieとは

ブラウザで何かのサイトを閲覧した際にそのサイトのサーバーが発行してブラウザへ送信, 保存するテキスト情報です。
そのテキスト情報は、次またそのサイトへアクセスした際に毎回自動でブラウザからサーバーへ送信されるようになっていて使い方は様々です。
具体的にはサーバー側からのレスポンスにSet-Cookieヘッダを付与することでブラウザにセットされます。 スクリーンショット 2022-04-28 17.44.06.png (54.2 kB)

ログアウトできない...

MymonitorはフロントエンドにNext.js, バックエンドにGoを採用しており分業体制で開発を進めています。
ある程度機能を作ったところで一旦AWSに載せてみることになったのですが、ローカル環境では問題なく動作していたログアウトがAWS環境だと動作しませんでした...
ただこのエラーを機に、Cookieについて調べ上げることとなります。

原因はSamesite属性とSecure属性

確認したところ、サーバー側で発行するログアウト時のCookieにSameSite属性とSecure属性を設定していなかったのが原因でした。
ちなみにログイン、ログアウト時の意図した挙動は以下です。

機能 詳細
ログイン 有効期限が3時間のCookieをサーバー側で発行しブラウザに保存する
ログアウト 有効期限が切れたCookieをサーバー側で発行しブラウザに保存する
認証 リクエストの度にサーバー側でCookieを受け取りその値でアクセスコントロール

有効期限が切れたCookieは、ブラウザに保存すると同時に消えることでログアウトを実現できます。
今回は消えるはずのCookieがログアウト後も残ってしまっていました。

その時のソースコード

// ログイン時のcookie
cookie := http.Cookie{Name: name, Value: token, Expires: time.Now().Add(3 * time.Hour), HttpOnly: true, Secure: true, SameSite: http.SameSiteNoneMode}

// ログアウト時のcookie
cookie := http.Cookie{Name: name, Value: "", HttpOnly: true, MaxAge: -1}

すっぽり抜けてます。
ただ、この時Cookie初心者だった自分は SameSite属性 == クロスオリジンでCookieやりとりするときはNoneにしないといけないと誤った理解をしてしまっていました。
なのでローカルもAWS環境もクロスオリジンだったのに、なぜAWS環境だけログアウトできないのかこの時点ではまだわかっていません 笑

SameSite属性とSecure属性ってなんぞや

Cookieには発行する際にいくつか属性を付与できます。(以下一部抜粋

名前 解説
Name Cookieの名前
Value Cookieの値
Expires 有効期限(日)
MaxAge 期限までの秒数
HttpOnly 付与するとJavaScriptからアクセスできなくなる
Secure 付与すると httpsの通信でのみ送信する
SameSite cross-site(クロスサイト)の通信でもCookie送信します?の 設定

解説にも書きましたが、今回取り上げるSecure属性は付与することによりそのCookiehttps通信でなければ、ブラウザ, サーバ間で送信されなくなります。
SameSite属性は、このあと書きますが設定によってブラウザ, サーバー間のCookie送信をクロスサイトでも行うかの設定ができます。

SameSite属性に設定できる値

名前 効果 詳細
Strict 同一サイトでのみCookie送信 セキュリティ強
Lax クロスサイトの場合HTTPメソッドがGETなど特定の条件下でのみCookie送信 Chromeでは未指定だとこれになる。 セキュリティ中
None クロスサイト、同一サイト関係なく送信する Secure属性が必須。セキュリティ弱

今回だと、フロント側のURLとサーバー側のURLの関係がクロスサイトかどうかが重要で自分はここを理解してませんでした。そして当初の理解のSameSite属性 == クロスオリジンでCookieやりとりするときはNoneにしないといけない ではなく SameSite属性 == クロスサイトでCookieやりとりするときはNoneにしないといけない と知りました。(そもそも属性の名前が SameSite(同一サイト)になってるやろ!って話ですね)

ちなみにcross-site(クロスサイト)かsame-site(同一サイト)かの定義は以下の通りです。

スクリーンショット 2022-04-28 2.30.42.png (306.7 kB)

引用:https://zenn.dev/agektmr/articles/f8dcd345a88c97

トップレベルドメイン+セカンドレベルドメインの組み合わせが違うかどうかのようです。

今回の状況

環境 フロント バック 詳細
ローカル http://localhost:3000 http://localhost:8000 same-site なのでCookie送信できる
AWS https://hogehoge.amplifyapp.com/ https://fugafuga.com/ cross-site & SameSite属性が 未指定(Lax) & リクエストメソッドがPOST なのでCookie送信できない

ローカル環境ではポート番号が違うだけで同一サイトになるため、SameSite属性が未指定(Lax)でも問題なくCookieを送信できる。
AWS環境では、まだ載せたばかりだったこともありドメインも違うのでクロスサイトになり、SameSite属性が 未指定(Lax)のログアウト処理だけうまく動かなかったわけです。

http通信のローカル環境でなぜログインできてたのか

SameSite属性は完全に理解したところですが、もう一つ疑問が。
そう。Secure属性です。Secure属性は付与すると、httpsでしかCookie送信しないはず...
↓もう一度その時のソースコード

// ログイン時のcookie
cookie := http.Cookie{Name: name, Value: token, Expires: time.Now().Add(3 * time.Hour), HttpOnly: true, Secure: true, SameSite: http.SameSiteNoneMode}  // ローカル環境のhttp通信では送信しないはず...

// ログアウト時のcookie
cookie := http.Cookie{Name: name, Value: "", HttpOnly: true, MaxAge: -1}

localhost は例外

ブラウザによっては localhost だと httpsの要件が無視されるとのことでした。
※自分はChromeを使ってます

スクリーンショット 2022-04-08 11.43.38(2).png (90.5 kB)

引用:https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Set-Cookie#sect4

開発者のこと考えてってことだよね。ありがてぇ... 笑

まとめ

  • ローカル環境では同じlocalhostでsame-siteのため SameSite属性が未指定(Lax)でもCookie送信できた
  • cross-siteでCookie 送信する場合は、SameSite属性をNone、Secure属性をtrueにするべし
  • Secure属性は localhost だと 無視される(ブラウザによる)

最後に

なんだかんだで今では、AWS環境でフロント側とサーバー側で同じドメインを使い、SameSite属性をStrictにして動かしています。
有名なサーバー攻撃手法のXSSCSRFの対策として、SameSite属性やHttpOnly属性の設定は必須です!!正しい知識で安全にCookie使っていきましょー!!

開発部内でのコミュニケーション頻度の向上のためGatherを導入してみた

PREVENT開発部、フロントエンドチームの高田(@tockii_ )です。本日は弊チームでオンラインコミュニケーション改善のため実施している施策についてご紹介します。

書いていること

  • Gatherを使い始めた背景
  • Gatherの利点
  • Gatherを使ってからのメンバーの所感
  • 今後の課題

書いてないこと

  • Gatherの使用方法
    • 別の機会で記事にできれば良いなと思っています。

はじめに

弊社では現在自由出社制度が実施されており、社員の任意でリモートワークか出社かを選択することができます。その中で開発部は常にほぼ全員がリモートワークで業務をしておりますが、現状業務に大きな混乱はなく、滞りなく円滑に進んでいるようにはなっています。

ただやはりリモートワークの弊害として、雑談などといった気軽なコミュニケーションがどうしても減ってしまっているというところがありました。無理に話をする必要がないのはもちろんですが、しかし全体的にも気軽に雑談とかできる方が嬉しいよねという共通の認識はあったところでした。

ただ、こちらを解決するためのツールや施策がなかなかうまくいかず(Discordなども使ってみましたがあまり浸透しなかった)どうしたものかと頭を悩ませていました。

そのとき、弊社エンジニアの1人が Gather っていう 面白いオンラインコミュニケーションツールがあるよということで、開発部内で試しに使ってみることにしました。

結果としては、部内でGatherを使うという文化が浸透し、コミュニケーションの幅が増えたというところになりました。

Gatherとは?

アプリ内に複数のユーザーが自由に出入りすることができる空間を作成し、その中でユーザー同士が通話やチャットなどといったコミュニケーションをとることができるというWebアプリです。

app.gather.town

他のコミュニケーションツールと何が違うのか?

MeetsやDiscordなど、世の中にはさまざまなツールがありますが、そのようなツールとは違う部分がいくつかあり、それが要因として部内に浸透したのかなと思っています。

スペースという存在・遊び心

上記ツールと一番の違いはこれに尽きるかなと思います。標準的な通話ツールは、ただ特定の通話部屋に入り、通話やチャットができるという機能しかありません。

しかしGatherはまるで一昔前の2DRPGのような空間に入り、その中で必要であれば会話をしたり、集中して作業したい時は離れた場所で仕事をするというようなことができます。これは仕事というよりは遊びという概念がかなり多く含まれているなと感じ、実際にそのような点をメンバーも感じとり、楽しんで使ってもらっているようです。

若干のリアルさ

上記で説明しましたが、Gatherではスペースという空間で移動をする必要があります。単なるコミュニケーションツールとしては非効率的な動作ですが、こういった操作を行うことでアバターと自身がシンクロしてそこに人がいるという感覚になり、出社をしている感じだったり、気軽なコミュニケーションの取りやすさがあるのかなと思います。

f:id:proghallelujah:20220318163816p:plain

弊社のGatherの風景です、最近はSnapCameraでよくわからないフィルターを使うのが流行っています

Gatherをどのように使っているか?

開発部では主にGatherをバーチャルオフィスのような感覚で使っています。

以下が2022年3月現在のPREVENT開発部スペースの全景です。複数のエリアがありますが、大きく分けて3つの用途を持って使用しています。現在はこの3用途だけで問題なく運用されている状態です。

番号を割り振ったので順番に説明していきます、番号外の箇所に関してはフリースペース(特に何も決めていない)です。

f:id:proghallelujah:20220310111626p:plain

 

①オープンスペース

ここでは近くにいる人とであれば誰とでも会話できるようになっています。

用途としてはいつ話かけてもいいよという状態のメンバーが使っているイメージです。

メインは中央スペースですが、たまに左にいるメンバーもいます。

左下はゲームセンターをイメージして作ったんですが特に使っている人はいないですね(泣

②会議スペース

枠の中でマスごとに番号が割り振られていますが、会議スペースはこの番号内のスペースに入っている方のみと会話ができるようになっています。(左上の[1]の場合、[1]の中にいる人としか会話できない、会話は[1]の外には聞こえない)

用途はその名の通り会議で使っています。部屋も大中小と分けており、どの人数でも対応できるようになっています。

最近開発部内での会議に関してはほぼ全てGatherでするようになっていますが(今まではMeetsを使っていた)今のところ大きな問題は出ていません。

Gather自体にバーチャル背景機能がないのがネックですが、SnapCameraという外部アプリを使うことでその点は解決できています。

③黙々スペース

こちらは会議スペースの機能の応用で、移動できる箇所で会話できるマスを1マスにすることで基本的には誰とも会話ができない&会話が聞こえないようになっています。(Gatherの特定の機能を使うことで会話はできますが、意図的に行う必要がある)

用途としては作業に集中したい時やGather以外で会議がある場合など、話しかけてほしくない状態のメンバーが使用するイメージです。

Gatherを使って1ヶ月後のアンケート

2月の初めからGatherを使い始めましたが、3月に簡単なアンケートを実施しました。

目的としては、メンバーがどういう風にGatherを使っているか、Gatherを今後も使い続けていけそうかを判断してみたかったからです。個人的にこのようなアンケートをとるのは初めてなので、実際に有効なアンケートなのかは微妙かもしれません。この辺りアドバイスなどありましたらぜひ教えていただきたいです。

各アンケートの後には、個人的な感想を少し述べています。

1.Gatherはコミュニケーションツールとして使いやすいですか?

f:id:proghallelujah:20220310111635p:plain

(①を使いにくいとし、⑤を使いやすいとしています)

ほぼ全ての人が使いやすいという回答をしています。コミュニケーションを取る、というだけだったら余計な工程があったりしますが(スペース内で移動しないといけないなど)おおむねその辺りは許容されているのかな?といったところです

2.Gatherはツールとして面白いですか?

f:id:proghallelujah:20220310111619p:plain

(①を面白くないとし、⑤を面白いとしています)

全員が面白いと回答しています。やはりゲーム的な側面もあり、コミュニケーションツールとは思えないような点が面白いのかなと感じます。

3.ログイン頻度は?

f:id:proghallelujah:20220310111622p:plain

ほぼ全員が毎日ログインしてくれていると回答しています。

毎日ログインしている身としての感覚としては、間違ってはいないかなと思います。

3-1. (3)で「営業日は毎日」「営業日の2日に1回」「営業日関係なく」に回答した方に質問です。Gatherにログインし続けている理由はなんでしょうか?

f:id:proghallelujah:20220310111624p:plain

色々な回答がありますが、やはりコミュニケーションが取りやすいと意見が多いですね。出社している気分になる、というのも実際にその通りだなと思います。

リモートワークをしているとどうしても仕事感が希薄になってきますが、Gatherを使ってからはGatherにいる→仕事をしているという感覚になっています。

3-2. (3)で「営業日は毎日」「営業日の2日に1回」「営業日関係なく」に回答した方に質問です。今後もGatherを使い続けようと思いますか?

f:id:proghallelujah:20220310111627p:plain

(①を思わないとし、⑤を思うとしています)

毎日ログインしている方全員が使い続けると回答しています。施策を実施した身としては嬉しい思いです。

3-4. (3)で「思い出したら」「ログインしない」に回答した方に質問です。Gatherの使用をしないのはなぜでしょうか?

f:id:proghallelujah:20220310111630p:plain

先のログイン頻度で「思い出したら」と回答した人は、基本的に習慣になっていないというのが大きな理由になっているとのことです。

習慣化するのは難しいですが、最近は部内の会議をGatherにシフトしているなどしているので、そこからGatherに入室するという習慣をつけていけたらという気持ちです。

3-5. (3)で「思い出したら」「ログインしない」に回答した方に質問です。Gatherを使いたいと思うにはどのようなことがあればいいと思いますか?(設定やイベントなど、なんでも良いです!)

開発部全体の朝会みたいなのやりたい

出社したらGatherっていう習慣をつける。打刻申請とリンク。

打刻申請とリンクというのは面白いなと思いました。ただリンクする場合は全社的な施策がちょっと絡んでくるので、思い出せないということであれば開発部内で定期のslackメッセージなどを流すなどをしたらいいのかなとも思いました。

4. Gatherを使い始めて他の方とのコミュニケーション頻度は増えましたか?

f:id:proghallelujah:20220310111633p:plain

(①を減ったとし、⑤を増えたとしています)

ほぼ全員が増えたとの回答をしています。③は「変わらない」という回答なのかなと思っていて、これは後述する黙々スペースに常にいる人などがそうなっていたりするのかなと思います。ただ、無理にコミュニケーションを取る必要はないという考えなので、このあたりはこんなもんかなといったところです。

5. Gatherを使い始めて他の方とのコミュニケーションは取りやすくなったと思いますか?

f:id:proghallelujah:20220310111635p:plain

(①を思わないとし、⑤を思ったとしています)

ここでは全員が取りやすくなったという回答をしています(もしかしたら③の人は変わらない、という回答なのかもしれませんが、、、)4の回答では変わらないと思った方も取りやすくはなっているという認識のようです。

6. Gatherでは主にどのスペースにいますか?

f:id:proghallelujah:20220310111638p:plain

黙々スペースが多数派ですね。

6-1. (6)で「オープンスペース」と回答した方に質問です。主にオープンスペースにいる理由はなんでしょうか?

f:id:proghallelujah:20220310111641p:plain

オープンスペースは雑談などのコミュニケーションをとりやすくしたいという考えで設置してみたのですが、何かあった際のコミュニケーションのとりやすさを解答としている人が多くて少し予想外でした。ただ確かにトラブルや相談があった際にオープンスペースにいると会話はしやすくなりそうなのでこの解答には納得です。

6-2. (6) で「黙々スペース」と回答した方に質問です。主に黙々スペースにいる理由はなんでしょうか?

f:id:proghallelujah:20220310111643p:plain

ほぼ全員が集中して業務に取り組みたいといった回答で、予想通りの使用方法かなと感じました。

ただ出社をしている場合は確かにGatherを使うのが少し難しいかなというところの回答もありました。ここは今後の課題かなと思っています。

Gatherのいいところを教えてください!(先に回答したことと被っても大丈夫です

一部抜粋して掲載しています

コミュニケーションが取りやすい

雑に話しかけれるビジュアル的に「みんな集まってる」感があって心理的安全性の維持につながっていそう

話しかけてよいか悪いかのところはDiscordより分かりやすく感じた。

キャラとか個性がでて面白いなとか、ゲーム感覚があって普段の仕事とは別の面白さがあって良いと思います。

Gatherの悪いところを教えてください!(先に回答したことと被っても大丈夫です

一部抜粋して掲載しています

まだバグがあるところ

急に声をかけられた時にマイクをすぐに on にするのが難しい

十字キーでの移動がめんどくさく感じる ゲーム感あって好きだけど業務中に使うツールとしては非効率

現在のステータスがわかりにくく、切り替えにくい。お昼とか、gather以外の会議とかが簡単に切り替えられるとよい。現状は、gather外にいるときは、quiteモードにしている。

その他、Gatherに関する要望等あればこちらに記入してください!

一部抜粋して掲載しています

他部門も入れたい(まぁ無理か。)

meetsでやるのか、gatherでやるのか曖昧な状況を整備した方が良さそう

今後の課題

最近の課題であった「リモートワークでのコミュニケーションの取りにくさ」については多少の改善はできたかなと感じています。

ただまだまだGather自体不具合も多いので、とても使いやすい、という状況になるにはもう少しかかりそうです。この辺りはGatherチームに期待をするしかありませんね。

コミュニケーションの取りやすさの改善などはまだ色々考えれるところがありそうなので、直近の目標としては開発部全員が常にログインしている状況にし、誰とでも常にコミュニケーションが取れるような環境づくりをしていけたら良いなと思います。

 

終わりに

最近のPREVENT開発部ではコミュニケーションをどのように解決しているか?について書かせていただきました。

コロナ禍でなかなか外出や出社が難しい現状ですが、Gatherなどのツールを活用し、リモート下でも気負いなくオンラインコミュニケーションを取れるよう、今後も改善していきます。

Gather自体は私たちのような会社の部内で使う以外にも勉強会やイベントなどでも使えそうなツールなので、よかったら試しに触ってみてはいかがでしょうか。

データサイエンスチームで、はじめてのインターンシップを受け入れました

はじめに

株式会社PREVENTのデータサイエンス(DS)チームの戸田です。今回はDSチームで受け入れたインターンシップの活動を報告します。

ツイッターのDM経由で連絡をいただいた東京大学 公共健康医学専攻の瀧澤さんは、9月6~24日の実稼働日が13日と非常に短い期間のなかで、こちらの用意した以下の課題を実施しました。

  1. 弊社解析業務のMyscope*1のデータクレンジング
  2. データセット仕様書や業務についての仕様書などのドキュメント整理
  3. 社内匿名加工済みデータを用いた先行文献の追従解析

有給のインターンシップという形でしたので、業務タスク(1, 2)をお願いしつつも何か学びをご提供できればと思い、先行文献の追従解析(3)を追加しました。盛りだくさんで課題が多過ぎたかと思いましたが見事にこなしていただきました。

リモートでのインターン受け入れ

9月30日まで東京では緊急事態宣言が出ていました。そのため、インターン開始の9月6~10日までホテルにてリモートで作業していただき、その後、マスク着用・入室時の手指のアルコール消毒など弊社が定める感染予防対策を徹底した上で、9月13日よりオフィスでインターンを開始しました。この辺りは瀧澤さんに柔軟に対応していただきました。

リモートのみでのインターン受け入れはなかなか難しいなという印象でしたので、今回のように前半リモート、後半は出社で今後のインターンを実施する可能性があります。

課題の成果報告

1. Myscopeのデータクレンジング

健康診断データおよびレセプトデータは、クライアントの保険者様からお預かりし、弊社内のレポート作成コードに合うように整形されます。Myscopeでは、機械的にクレンジング作業を行うためのアルゴリズムを組んでいますが、人によるチェックとコードの変更が必要な箇所があります。お預かりした生データから指定したフォーマットに変換する作業を期間中に2件行なってもらいました。

2. データセット仕様書や業務についての仕様書などのドキュメント整理

弊社内で保有しているデータについては、ER図が存在しているものの定義書やプロファイルがまだ不十分です。そこで、ER図と指定した参考資料を用いて定義書の作成してもらいました。エディタの指定はしませんでしたが、フォーマットはMarkdownに統一しました。 (レセプトDBの定義ドキュメントの一部) f:id:D_Sk:20211102110018p:plain

3. 先行文献の追従解析

今回参考にさせていただいた論文は2021年に公開されましたPhysician visits and medication prescriptions for major chronic diseases during the COVID-19 pandemic in Japan: retrospective cohort study(I.Osawa, et al, BMI Open, 2021)です。COVID19流行による緊急事態宣言前後での慢性疾患に対する医師の診察と処方行為についての日本の観察研究です。proportion of days covered:PDC(処方日数を対象期間の日数で除した割合)という指標を抜き出すことや時系列でデータを取り扱うことがレセプトの取り扱いを実践してもらう良い題材となると考え、インターン課題として選択しました。

結果のサマリー

弊社内匿名加工済みデータセット(225,237件、2017.01~2020.12)を用いて、論文にある指標を計測しました。 詳細をみるとまだ考察しきれていない部分はありますが、1回目および2回目の緊急事態宣言前後で受診回数が減少していることがわかります(スライド8枚目)。参考にした先行文献と類似した結果が得られました。

www.docswell.com

インターンシップを参加した感想

インターンシップに参加した瀧澤さんより感想をいただきました。

今回インターンシップをさせていただいた瀧澤です。
私はデータサイエンスの学習はしておりましたが、レセプトデータなどの生データに触れる機会はなく、「データサイエンス職に興味はあるが、実際の業務は自分に合っているのだろうか?」という不安がありました。今回のインターンシップで 、データ分析の8割を占めるといわれるクレンジング業務や実際のレセプトデータに触れることで、PREVENTのデータサイエンス職の業務内容がイメージしやすくなりました。学習したことが実際のデータではスムーズにいかないことも体験でき、とても充実し学びの多い経験となりました。 これまでレセプトデータとの関わりがなかったのですが、ドキュメント作成と論文追従を経て、受診から請求までのデータの流れをイメージできるようになりました。
PREVENTのインターンシップを経験し、よりデータ分析に関わりたい気持ちが強くなりました。この経験は自分にとって資産だと感じています。受け入れてくださったPREVENTの皆様、本当にありがとうございました!

まとめ

DSチームでのインターンの受け入れは初めてのことでした。非常に優秀な方でしたのでなんとか形にしていただき、さらには今後インターンシップの方針もだいたい定めることができました。この場を借りて瀧澤さんにはお礼を申し上げます。

今回の経験を踏まえて、インターンの方には基本的に

  1. 弊社解析業務のMyscopeのデータクレンジング
  2. データセット仕様書や業務についての仕様書などのドキュメント整理
  3. 社内匿名加工済みデータを用いた先行文献の追従解析

を実施していただく予定です(※ もちろん期間に応じて課題設定は行います)。ヘルスケアスタートアップが扱う生データに触れていただく機会とデータの活用方法について体験いただければと考えています。ただ、ある程度のドメイン知識が必要ですので、前半はドキュメント作成などのタスクで特有なデータ構造について学んでもらい、後半にはガンガンコードを書いてデータ分析を進めるという流れが良いかなと考えています。

DSチームのリソース的に多くの受け入れは困難ですが、ご興味のある方が是非ご連絡をいただければと思います。ヘルスケアベンチャーでDSチームが何しているの?実際にどんな業務があるの?今後の展望ってあるの?など、この分野でDSを目指したい方は是非一度コンタクトをとってみてください。

*1:Myscopeの詳しい説明についてはhttps://prevent.co.jp/service/myscope/

ベイジアンネットワークを用いた胃潰瘍罹患者における薬剤処方パターンの探索

【はじめに】

こんにちは。データサイエンスチームです。

今回はPREVENT社内に蓄積されたレセプトデータを用いて、因果探索を行なった事例を紹介します。

続きを読む

CORS(オリジン間リソース共有)とは?

はじめに

こんにちは、フロントエンドチームの高田(@proghallelujah)です。 webアプリケーションを開発していると、このような内容のエラーが出たことがある人は多いかもしれません

Access to XMLHttpRequest at 'https://hoge.com' from origin 'https://fuga.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

このエラーは一体どういったことを伝えているのでしょうか?また、エラー文内にあるCORSというものは一体なんでしょうか?今回はこちらについて解説していこうと思います。

CORSについて

CORSの意味

まず、このCORSというのはCross-Origin-Resource-Sharingの略で、日本語に訳すとオリジン間リソース共有と言います。

このCORSは、あるオリジンで動作しているウェブアプリケーションに、異なるオリジン内のリソースへのアクセスをオリジン間HTTPリクエストにより実行するようブラウザに指示するための仕組みです。


(補足)オリジンとは?

プロトコルドメイン、ポートによって定義されたものです。

例) http://hoge.com:80

こちらの場合、http(プロトコル)+hoge.com(ドメイン)+80(ポート)からできたオリジンです。


なぜCORSが必要か?

CORSは、webセキュリティポリシーの一つSame-Origin Policy(同一生成元ポリシー)によって定められた制限に対応しており、安全なオリジン間のリクエストやブラウザ・サーバー間のデータ転送を行うためのものです。

同一生成元ポリシーとは?

JavaScriptなどのプログラムを用いた通信において、そのプログラムが存在する同一のオリジン内でのみデータアクセスを可能にし他のオリジンへのアクセスをできないよう制限するための仕組みです。

オリジン1: http://hoge.com/dir/page.html
オリジン2: http://hoge.com/dir/shop/main.html

パスは異なっていますが、プロトコル、ドメインといったオリジンは同一のため、アクセスは可能となります
オリジン1: http://hoge.com/dir/page.html
オリジン2: https://hoge.com/dir/page.html

パスは同一ですが、プロトコルが違うため、アクセスは制限されます

なぜ制限するのか?

例えばXSS(クロスサイトスクリプティング)という攻撃手法があります。これは標的とするwebアプリに第三者が外部から悪意のあるスクリプトを埋め込み、アプリが意図をしていない動作を引き起こすようにします。

これは基本的に別のオリジンからの攻撃になるため、同一制限ポリシーがあることで防ぐことができます。

このように異なるオリジンからのアクセスを制限することにより、元オリジンのリソースに対して悪い影響を与えることを防ぐのを目的としています。

制限が適用されないケース

基本的にはJavaScriptによる非同期通信などに適用されますが、htmlベースのものでは制限されないものが多いです

  • <img>タグのsrc属性で読み込まれた画像
  • <link>タグのhref属性で読み込まれたCSS
  • <script>タグのsrc属性で読み込んだJavaScript

などなど、普段よく使っているものの中にも別のオリジンから読み込んでいるものが多くありますが、これらは同一オリジンポリシーが適用されません。

参考

MDN - オリジン間リソース共有 (CORS)

CORS(Cross-Origin Resource Sharing)

MDN - Origin (オリジン)

MDN - 同一オリジンポリシー

Wikipedia - クロスサイトスクリプティング

銀座Rails#24@リンクアンドモチベーション 勉強会の感想

こんにちは!株式会社 PREVENT の開発部門、バックエンドエンジニアチームの松原と申します。

厳しい残暑がようやく和らぎ始めましたが、いかがお過ごしでしょうか?

今回は、8月28日(金)に銀座 Rails に参加した感想と、イベント中に登場した技術、特に詳しく知らない点を学習も兼ねてまとめたいと思います!

ginza-rails.connpass.com

銀座 Rails のイベントに初めて参加したのですが、今回は Devise 、 Rails で行う Distributed Tracing 、 Rails で作る serverless CMS などを学びました。

業務で Rails を扱うようになり八ヶ月が経過しましたが、イベントでテーマとして取り上げられている技術は知らないものばかりで、 Rails に変換して考える段階まで至ることができませんでした。

Rails 的に考察できるととても面白そうなので、 Distributed Tracing について学習し直したいと思います。

Distributed Tracing (分散トレーシング)とは?

分散トレーシングとは、分散されたシステムで処理されるリクエストを追跡するためのものです。

分散トレーシングには主に二つの要素があり、その要素を Span と Trace と呼びます。

Span: 1サービス内の処理を表す。

Trace: Requestのstart-endを含むSpanの集合をあらわす。

イメージは以下のようになります。

f:id:syrengr:20200909190708p:plain

<出典: 分散トレーシングシステムのZipkinを使ってみた話>

分散トレーシングでは、 Span と Trace を可視化し、問題点と処理に時間がかかっている点を確認することができます。また、解決するための手助けをするシステムを分散トレーシングシステムといいます。

Open Tracing について

Open Tracing とは、開発者にシステムトレーサーの追加、またはトレーサーの切り替えを行う仕組みを提供する、分散トレーシングの実装です。

Open Tracing 仕様を実装したトレーサーとして、 Twitter 社が開発した Zipkin や、 Uber 社の Jaeger などがあり、詳しくは以下の資料が大変参考になりました! :)

www.slideshare.net

Distributed Tracing を Rails で行う方法

ネット上の資料を調べた結果、分散トレーシングを Rails で行うには以下の記事が参考になりそうだと思いましたが、翻訳しつつ拝読しても難易度は高く感じたため、今後まとまった時間が取れたらトライしてみたいです。

medium.com

OpenCensus (分散トレーシングを行うためのライブラリ集)を使用すると、 Rails で分散トレースを簡単に採用できるというお言葉が心強いです :)

イベントに参加させていただき、ありがとうございました!

以下でも同様の記事を書いておりますので、ご紹介させていただきます。

銀座Rails#24@リンクアンドモチベーション 勉強会の感想|Sayuri Matsubara|note

季節の変わり目、くれぐれもご自愛ください。それでは、失礼致します。

半年間リモートワークを続けてみて感じたこと

はじめに

こんにちは、フロントエンドチームの高田(@proghallelujah)です。

弊社は昨今世界中で発生しているCOVID-19危機のため、2020年3月ごろから一時的にリモートでの業務が可能になりました。 それまでは全ての業務を会社のオフィス内で行っていました(業務委託などの例外はあります)ので、最低限の規約の中でのスタートで本当に大丈夫だろうか?と最初は不安でしたが、今現在でも会社は問題なく動いております。 これは開発部門も例外ではなく、2020年9月現在では全ての開発メンバーが適宜リモートワークを活用しながら業務を行っております。半年間もリモートワークをしていることに記事を書きながら気付いたのですが今ではこれが当たり前になっており、たまに会社に出社するとあまりの人の少なさに少し寂しくなったりもします。

半年間リモートワークを続けてみてどうだったか?メリットデメリットを含め僕が感じたことを書いていこうと思います。

①: 時間を有効に使えるようになった

リモートワークの魅力の一つとして通勤時間が無くなることです。時間をフルに無駄なく使えることの素晴らしさを1日目から実感することができました。 朝起きてすぐに仕事ができるというのはかなり魅力的ですし、早くはじめれる分早く仕事を終え、自分の時間を増やすこともできました。 また、休憩時間に家のことができるので、部屋が少し綺麗になったりご飯の質も少し上がりました笑

ただし、家にいると身嗜みに無頓着になりがちで、僕は髭を剃らなすぎて大変なことになっていました。定期的なビデオ会議等あるので毎日ある程度はきちんとすることが必要です。

②: 予想以上に業務で困ることがなかった

弊社はリモートワーク以前からコミュニケーションツールとしてSlackを、ドキュメント作成にはesaを使用していました。なのでリモートワーク中でも業務についての連絡は特に以前と変わらずに滞りなく行えています。急ぎの用件があっても投稿をすれば間違いなく返答があるので今のところ根本的に業務で困ったことはありません。

ビデオ会議に関してはリモートワーク前は業務で使用することはなかったのですが、これも当初から問題なく運用できています。(弊社開発部門のリーダーは会議ツールに嫌われているのか初回入室のさいは声が聞こえない確率が高いというのが喫緊の問題です)

ただ、痒いところに手が届かないようなことはよくあるのでそのためのドキュメントやルール整備は日々進めていっております。

③: 人と喋る機会が少なくなった

僕は一人暮らしでペット等も飼っていないので丸一日中人と接することがない日もあります。ビデオ会議はもちろんありますが毎日しているわけでもないので、その日した唯一の会話が「袋はいりません」ということもあったり笑。

集中したいときに周りに雑音がなく自分の事に取り組めるのでコーディングにブーストをかけたりはできますが、たまにはみんなでワイワイしたいという気持ちもあります。 上記の通り業務に関するコミュニケーションは問題なく行えてますが、雑談となるとなかなか難しく、discordなどのもくもく・雑談用のコミュニケーションツールやチャンネルなどを用いたりもしましたがなかなかうまくいっていないのが現状です。

④: 家で良い作業をするためには設備投資が必要

僕は1SK(リビング1つとロフト1つ)のアパートに住んでいて、仕事やプライベートも全てリビングで行っているのですが(ロフトは寝室)そのせいか、仕事とプライベートの境界が少し曖昧になってしまっています。ただあまり大きい部屋でもないのでのでこれ以上机を増やすこともできず、こればかりは引っ越すくらいしか手がないのが難点ですね。

また、作業環境も座椅子とこたつテーブルなのですがあまり体にあってないのでだんだん腰が痛くなってきます。一日中同じ場所にいるということを考えると、やはり良い作業環境は必須だなと思います。最近は小さいスタンディングデスクなら置けるかなと試行中です。

⑤: 外に出る頻度が減った・日にあたることや運動の大切さ

通勤が無くなったことで平日に外に出る用事が少なくなり、最初は買い物などの用事をまとめて済ませて3日くらい家にこもりっぱなしという日もありました。必要なこと以外は家から出なくていいのはなかなか楽だなと思ったのですが、流石に不健康すぎると思って毎朝散歩やランニングをするようになりました。

軽い運動をしているということもありますが、日光に直接当たることで体内時計が補正されたのか、家にこもりっぱなしの時より体の調子がよくなった気がします。リモートワークを続けていると普段より体重が増えたという声もよく聞きますが、やはり意識的に運動する機会を作る機会が必要だと感じました。

最後に

リモートワークというのはとても魅力的なものですが、いざ実施するとなると大小様々な問題が発生すると思います。弊社では緊急で始まった施策ではありますがこれを機に正式な形としてのリモートワーク制度を実施するため、様々な施策や環境の整備が弊社では進められています。

現在でも日本中で広がり続けているCOVID-19ですが、PREVENTは病気予防・ヘルスケアに携わる企業としてこれに負けることなく、一人でも多くの方に健康的な生活を送り続けていただけるよう業務に取り組んでおります。