OmniAuth(OAuth2)処理をキックしたときのパラメータを認証用リクエストにも渡したい はじめに RailsアプリにOAuth2認証を導入する場合に利用できるOmniAuthがあります。 TwitterやGitHubなどの外部認証用にすでにいくつもStrategyが用意されています。 リストにない場合は自作することになりますが、認証サービス用のStrategyを作成時にはまった点を紹介します。 特にOmniAuth処理をキックされたときの動的なパラメータを扱う点は、検索しても情報が見つけられなかったので苦労しました。 参考になれば幸いです。 ここで取り上げるポイント OAuth用のURLを変更する callback_urlの注意点（デフォルトのままだとエラーになってしまうパターン） OmniAuth処理をキックされたときのパラメータを認証時のパラメータとして渡す OmniAuth処
使用したライブラリはこちらです。 https://github.com/kazasiki/omniauth-line 組み込んだアプリでomniauth-google-oauth2を使用していて、omniauth-google-oauth2がomniauth-oauth2のバージョン1.6以上を要求していたので問題が起こりました。 詳しいエラーの内容と、根本的な問題はスタックオーバーフローに投稿し、的確な回答をいただいたのでそちらをご覧ください。 トークンをリクエストする時の必須パラメータredirect_uriに必要の無いパラメータが付与されてたのでredirect_uri does not matchになっていたわけですが、そもそもリクエスト組み立ててるの俺じゃねえし、どうすれば良いの？というところを解説したいと思います。 この辺でomniauth-oauth2はcallback_ur
＜この記事は「Money Forward Advent Calendar 2015」の20日目の記事です＞ 最近 OmniAuth 用の OAuth2 のストラテジーを作る機会が何度かあったので、gem のコードやドキュメントを読んで調べたことをまとめました。独自に OmniAuth のストラテジー、特に OAuth2 のストラテジーを作る場合は是非参考にしてください。 なお、本投稿は OmniAuth の Strategy Contribution Guide および OmniAuth、OmniAuth OAuth2、さらに 有志が開発した OmniAuth 用の各種ストラテジーの実装を参考にしています。 OmniAuth OmniAuth は、認証プロバイダを利用してユーザ認証する方法を標準化するための gem です。 例えば、Web アプリケーションを作るときに、複数の認証プロバイダ
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: The Practical Effects of the GVL on Scaling in Ruby 原文公開日: 2020/05/11 著者: Nate Berkopec サイト: Speedshop -- フロントエンド、バックエンド、環境を含めたフルスタックのRailsパフォーマンスコンサルタントです。 画像は元記事からの引用ですが、著作権を確認しきれないものはリンクにとどめました。 コンカレンシーとパラレリズムの説明がとても丁寧なのが嬉しいポイントです😋。 概要: MRI RubyのGlobal VM Lock（GVL）は、何かと説明が的外れだったり誤解されたり批判にさらされたりしがちです。RubyはGVLのせいでコンカレンシーにもスケーリングにも縁がないのでしょうか？この点を完全に理解するには、Rubyの仮想マシン（
技術開発部で主にバックエンド開発をしている浜田(@hamchance0215)です。 現在開発中のプロダクトのバックエンドはRails + graphql-rubyを使っています。 GraphQLを使った際のデメリットとしてN+1が発生しやすいということがよく言われます。 弊社でも例外ではなく、随所でN+1が発生していました。 今まではフロントエンドからの使われ方を考慮して、サクッと実装できる先読み(preload等)でN+1を回避していたのですが、クエリー数が増加したことでクエリーごとに使われ方を把握するのは難しくなってきたのと、同じクエリーであったとしても使われ方が多様化して先読みでは非効率になることが懸念されました(先読みが非効率になる件は後述します)。 そこで重い腰をあげて、遅延ロードを導入するために調査を行うことにしました。 ※この記事は執筆時点(2021/06)の情報で記載され
この記事はGLOBIS Advent Calendar 2020の19日目の記事です。 新規サービスの開発にバックエンドはRuby on Rails + GraphQL、クライアントサイドはReactを使っています。バックエンド側ではGraphQL Rubyをライブラリとして使用しています。実際にGraphQL Rubyを開発に盛り込んでしてきたことを書いていきます。 なぜ GraphQL + React を採用したのか 我々が現在開発中の新規サービスではサーバーサイドに GraphQL、フロントエンドに React.js を採用しました。 グロービスでサービス側はフロントエンドに React.js を主に採用しており知見・リソース共にサービス立ち上げの開発速度を担保するために十分でした。サーバーサイドについては Ruby on Rails を利用しており、APIについては Swagger
You work on a mature web application that cleanly separates backend and frontend. The server-side code, written in Ruby, is mostly responsible for translating HTTP requests into SQL statements (with the help of an ORM) through rich and well-documented API. You choose GraphQL over REST to streamline your endpoints, but your database is not happy with all the extra queries. After much searching, you
RailsやSinatraなどのRuby製Webフレームワークを利用されている方は、Rackというキーワードを一度は目にしたことがあるのではないでしょうか。 よく聞くけど詳しくは知らない、そんなやつがRackです。 今回は自分の知識の整理も兼ねて、Rackとは何ものなのかについて調べたメモを、ここに残します。長かったので、全3回に分割しています。 目次 [本記事] Rack入門 概念編(1/3) Rack入門 Rack Application編 (2/3) Rack入門 Rack Middleware編 (3/3) Rackとは何か。ひとことで Webアプリケーションサーバーとアプリケーションを接続するための標準化されたインターフェースのこと Rackとは何か。詳細 Rackの公式リポジトリでは、Rackは以下のように記載されています。 そして、 Supported web servers
How can I change the route that triggers omniauth from using /auth/:provider to /myapp/auth/:provider ? I don't want to redirect either, because my server will send anything that's not in /myapp/ to the wrong place.
結論 Rubyでは、動的にクラスに生えているメソッドを書き換えられるため、テスタビリティを上げるためにDIを使わない。 個人的にはストラテジーパターン使いたいときぐらいしか、DI使わないんじゃないかなーって思っている。 Rubyでテスタビリティ向上のためにDIを使わない理由 DIを使う理由は、結合度の低下、テスタビリティの向上が主な理由だと思います。 一般的な言語の場合には、引数にインターフェースを指定して、インターフェースに依存するようにすることでテスト時にモックオブジェクトを注入できるようにすると思います。しかし、Rubyの場合には、動的にクラスに生えているメソッドを書き換えれるためテスタビリティを上げるためにDIをするのは意味がないです。 Rubyでは、rspecを用いて下記のように書くだけでクラスのメソッドを書き換えることができます。これによりテスト実行時にはクラスのメソッドの内容
本稿は、ブダペストで開かれたイベント「 RuPy 」で、Pat Shaughnessyが披露したプレゼンの内容をまとめたものです。 プレゼンの映像はここ から視聴できます。 本稿は当初、 同氏の個人ブログ に投稿されましたが、同氏の了承を得て、Codeshipに再掲載します。 このイベントは「RubyとPython」に関するカンファレンスなので、RubyとPythonでは、ガベージコレクション（以下「GC」）の動作がどう違うのかを比較すると面白いだろうと私は思いました。 ただしその本題に入る前に、そもそもなぜ、GCを取り上げるのかについてお話しします。正直言って、すごく魅力的な、わくわくするテーマではないですよね？ 皆さんの中でGCと聞いて、心がときめいた方はいらっしゃいますか？ ［実はこのカンファレンス出席者の中で、ここで手を挙げた人は数名いました！］ Rubyコミュニティで最近、Rub
module Types class QueryType < Types::BaseObject field :users, [UserType], null: false def users User.all end end class UserType < Types::BaseObject field :name, String, null: false field :articles, [Types::ArticleType], null: false field :favorites, [Types::FavoriteType], null: false end class FavoriteType < Types::BaseObject field :user, Types::UserType, null: false field :article, Types::Articl
この記事では、並列処理に関する入門的知識を解説する。 さらに、Rubyで開発されている新しい並列実行単位Ractorにも言及する。 まず、この話題をする上で混同しがちな用語についてまとめる。 並列処理（parallel）と並行処理（concurrent）について 並列処理 では、ある瞬間に複数の処理が同時に走る。 並行処理 では、複数の処理を時分割で順に処理する。並列処理とは異なり、ある瞬間に同時に走る処理は1つだけ。 ある複数の処理が実行されているタイミングを時系列で示すと、下図のようなイメージになる。 （青い線がある部分のみ処理が実行される） この記事では並列処理の動作について扱うが、並列処理のコードを書いても結局並行処理のように動いている場合もあることには注意。 （例えば、1コアのCPUでは2つ以上の処理を並列に動作させることはできない、など。） この辺りはOSやVMなどが良い感じに
Rubyで並行処理を書きたかったのですが、自前でスレッドセーフなプログラムを書ける気がしないのでgemを探して来ました。 Concurrent Ruby github.com Be an 'unopinionated' toolbox that provides useful utilities without debating which is better or why と書いてあるので、諸々の並行処理の実装があるみたいです。スレッドセーフらしいです。 READMEを読むとActorやらChannelやら書いてあります。 とりあえず今回は一番basicっぽいAsyncを使って並行でHTTPリクエストを投げる処理を実装してみます。 Async Async: A mixin module that provides simple asynchronous behavior to a cla
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
