Rails における Chrome80 の SameSite 対応 - ボクココ
ども、@kimihom です。 明日、2020/02/04 に Chrome 80 のリリースが予定されている。そこで巷で話題になっている SameSite の部分で対応が必要になるケースがでてくる。 ウェブ上で調べても全然その対応方法が出てなかったので、記録として残しておこう。 問題となり得るケース Rails アプリでログイン機能を実装していて、iframe で そのログインセッションを使い続けている場合、Chrome80 から問題が起こる可能性がある。その他のケースもあるので、自分の作っている Web アプリが SameSite による影響が出るのかを確認しておこう。詳しくは既にたくさんのページで紹介されているので読んでおいて欲しい。 Google Developers Japan: 新しい Cookie 設定 SameSite=None; Secure の準備を始めましょう Chr
Rails の フロントエンド周りの未来予測 - ボクココ
ども、@kimihom です。 Rails の Sprockets や Uglifier などが最新の JavaScript に追従していないという理由で、Rails 標準のやり方から外れて最新のフロントエンドツールを追い求める系の報告が多い。一部では完全に Rails の Asset Pipeline から外れて、Gulp などに移行する話もよく聞く。確かに現行の Rails のフロントエンド環境で開発すると、let や クラス構文をまともに使えない(エラーになる)ため、最新の構文に対応した JavaScript フレームワークはほとんど使えないのは大きな問題として残り続けている。 最新版である Rails 5.1 から、ようやく jQuery からの脱却とフロントエンド周りの最新化、つまり Yarn や Webpack の導入が検討され始めている。これに期待されている方も多いのではない
認証を含む API 開発で検討すべきこと - ボクココ
ども、@kimihomです。 API に関する基礎的な話で、なぜ API が重要なのか、APIの実装で注意する点について記述した。 今回はAPI開発において最も頭を悩ます、認証の問題について考えてみたい。 API における認証 よくあるログインが必要なページを考えてみていただきたい。 通常のWebアプリケーションであれば、Cookieという仕組みを使って毎回Webサーバーにアクセスするときにsession idというものを送信し、それとユーザー情報を紐付けたデータを取ってくることで、どんなユーザーからリクエストが来たのかをWebアプリケーション側で判断することができる。これにより、私たちはいつも閲覧しているWebアプリケーションが自分専用の画面として見れるようになっている。 これがAPIになると話は違ってくる。Cookieという仕組みが使えないのである。ということで、なんとかしてAPIにア
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
