iOSでPWAとして起動されたときにLocalStorageに保存したtokenを利用してオートログインさせる - Qiita
背景 iOS(11.3時点)のPWAではCookieが起動ごとに初期化され、Session(Cookie)を利用したログイン状態の保持ができません。追加調査でLocalStorageについては初期化されないことがわかったため、LocalStorageを利用したオートログインの実現について実験しました 来週開催されるWWDCやiOS12で解消されるのを切に願ってます😭 過去の調査内容 【調査】WEBアプリをPWAとして起動した場合にブラウザのCookieが引き継がれるか確認する - Qiita 【調査】WEBアプリをPWAとして起動した場合にブラウザのlocalStorageが引き継がれるか確認する - Qiita サンプルアプリ 調査のために作成したサンプルアプリは今後もiOS, Androidバージョンアップ時に利用する可能性がありそうなためHerokuで公開しておきました。（無料プラ
[*Rails*] deviseの使い方（rails4版） - Qiita
$ rails g devise:install create config/initializers/devise.rb create config/locales/devise.en.yml =============================================================================== Some setup you must do manually if you haven't yet: 1. Ensure you have defined default url options in your environments files. Here is an example of default_url_options appropriate for a development environment in config/e
![[*Rails*] deviseの使い方（rails4版） - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/f911790de9e3404182046043c3e76d287153e97f/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJTJBUmFpbHMlMkElNUQlMjBkZXZpc2UlRTMlODElQUUlRTQlQkQlQkYlRTMlODElODQlRTYlOTYlQjklRUYlQkMlODhyYWlsczQlRTclODklODglRUYlQkMlODkmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPTJlOTM0ZTEwMDcxY2FjNmFmYTUxY2FkNzVmMjQ0YTdj%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBjaWdhbGVjaWdhbGVzJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1mOGU4ZmRmYWNlYzZjNDE2ZmYwYjhhNGYyZWMyZTAyOQ%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dcaa2cb7ea781c814caa4e27ba729bcb9)
Rails 4.2 で ユーザー管理・認証 (devise) - Qiita
devise とは Rails でログイン認証管理を行う際のメジャーな Gem 。 以下の10個のモジュールからなる。 Database Authenticatable: DB に保存するパスワードの暗号化。ほぼ必須のモジュール。 POST リクエストや Basic 認証で使われる。 Omniauthable: OmniAuth サポートのためのモジュール。 Twitter などの外部サービスのアカウントでユーザー登録させたい場合に追加する。 Confirmable: アカウント作成の際のメール認証モジュール。 メール中のリンクをクリックしないとログインできないようにできる。 Recoverable: パスワードリセットが可能になる。 Registerable: サインアップ処理が可能になる。 Rememberable: クッキーに保存されたトークンの生成・削除を行う。 Trackable
Deviseを使っているRailsアプリに2段階認証を導入する - Qiita
Deviseを使っているRailsアプリに2段階認証を入れる機会があった。 調べてみると、devise-two-factorがよく使われているようだ。 GitLabもこのgemを組み込んでいる。 このgem、嬉しいことにdemoアプリまで用意してくれている。 ただし、ちょっと一般的な挙動とは違う…。 おそらく機能を紹介するために一番シンプルな構成にしているのだとは思うけど、 このまま導入するのはちょっと厳しい。 ID/PASS/認証コードを一度に入力するようになっていたり、 2段階認証有効化ボタンを押すと問答無用で有効化されたり。 そこで、Deviseを使ったRailsアプリに一般的な挙動の2段階認証を導入する過程を書いていく。 実装にあたっては、GitLabのコードを参考にした。 目指すところ ID/PASSと認証コードの入力を2段階に 「ID/PASSを入力 -> 認証コードを入力」の
OmniAuth関連のURLを変更する - Qiita
githubとdeveloperのproviderを使った場合の例で、デフォルトは/authなのを/loginに変更する。 Rails.application.config.middleware.use OmniAuth::Builder do configure do |config| config.path_prefix = '/login' end provider :developer unless Rails.env.production? provider :github, ENV['GITHUB_KEY'], ENV['GITHUB_SECRET'] end OmniAuth::Configure#path_prefix を指定する。 関連URLが/auth/githubや/auth/github/callbackから/login/githubや/login/github/c
AuthlogicとOmniAuthを使って複数のアカウントと連携する - Qiita
class User < ActiveRecord::Model has_one :facebook_account has_one :twitter_account end というように、なっていてほしい。 でもって、ログイン処理の対象になるのは FacebookAccount や TwitterAccount でなくて User モデルであってほしい。 最初 devise でそういうことをやろうとしたんだけど、なんだかうまくいかなくて authlogic に乗り換えたわけです。 authlogic にも Facebook とか OpenID とかの Add on があるみたいなんですが、そちらはどんな実装になっているのかコードを読み切れなかったので、使っていません。 認証に関しては、対応サービスも多い OmniAuth 使うことにしました。 authlogic の準備 authlogi
RailsアプリケーションにTwitterとFacebookの認証機能をつける - すべてがヒントだ
概要 新しいサービスを利用するのにユーザ登録が必要な場合、利用者にとっては手間がかかり利用するハードルが上がってしまいます。 しかし、現在広く使われているTwitterやFacebookアカウントを利用した認証機能を使うことで、ユーザは気軽にアプリケーションを利用できるはずです。 本記事ではRailsアプリケーションでOmniAuthを用いてTwitterとFacebookアカウントの認証をする方法を記します。 環境 CentOS 6.4 ruby 2.0.0p353 (2013-11-22 revision 43784) [x86_64-linux] Rails 4.0.3 1.TwitterAPI,FacebookAPIにアプリケーションを登録する 以下のURLからそれぞれアプリケーション登録を行い、アプリケーションID(APIキー)とSecretキー(APIシークレット)をメモして
#283 Authentication with Sorcery - RailsCasts
Sorcery is a full-featured, modular solution to authentication which leaves the controller and view layers up to you.
Ruby on Rails3.2でログイン機能を実装する。
というわけで。 簡易なブログアプリを作っていて、記事の投稿・編集・削除はログインした管理者のみで行いたいので Rails3.1で追加された認証関連機能を使ってログイン機能をつけました。 参考にしたエントリー ASCIIcasts - “Episode 270 - Rails 3.1の認証機能" 以下作業メモ [環境] CentOS6.2 Ruby 1.9.3(p125) Ruby on Rails 3.2.2 1. Gemfileにbcryptrubyを追加 Gemfile内のgem 'bcrypt-ruby', '~>3.0.0~のコメントアウトを外した上で bundle install 2.ユーザmodelの作成 $ rails g model user name:string password_digest:string $ rake db:migrate ※password_dig
Rails Tutorial for OmniAuth with Mongoid · RailsApps
by Daniel Kehoe Last updated 23 November 2012 Rails 4.2 Version For a Rails 4.2 example application with OmniAuth, see the rails-omniauth application, with an OmniAuth Tutorial. Rails 3.2 Version This tutorial showis how to create a Rails 3.2 application using OmniAuth with Mongoid. OmniAuth gives you ready-made authentication using a service provider such as Twitter or Facebook. Mongoid gives acc
Rails3, Mongoid, OmniAuth でFacebookログイン実装 - ボクココ
最初はやはり認証。これができないと何もアプリ作れない。 $ rails new youme -m https://github.com/RailsApps/rails3-application-templates/raw/master/rails3-mongoid-omniauth-template.rb -T -OGithub から実装テンプレートを取ってくる。HTTPSの証明書エラーが出たので、ここ http://railsapps.github.com/openssl-certificate-verify-failed.html を参考にして解決。 [homma@localhost rails]$ rails new youme -m https://raw.github.com/RailsApps/rails3-application-templates/master/rails3
Railsの第4世代認証エンジンDeviseのREADMEを翻訳してみた - babie, you're my home
Devise の README は懇切丁寧だが、その分クソ長いので、読むのに疲れる。後続のために訳してみることにした。無保証。OAuth2 の部分は飛ばした。長いし。差し迫ったら訳します。 Devise Devise は Warden をベースにした Rails のためのフレキシブルな認証ソリューションです。 Rackベース Rails エンジンに基づいた完全な MVC ソリューション 1回の認証で複数のロールを持たせることができます あなたが必要な部分だけ使えるモジュラー構造というコンセプトに基づいています 以下の11のモジュールで構成されています： Database Authenticatable ユーザーがサインインする時に認証するためにパスワードをデータベースに暗号化し保存します。この認証は POST リクエストまたはBasic認証を通して行われます。 Token Authenti
ASCIIcasts - “Episode 210 - Deviseのカスタマイズ”
210: Deviseのカスタマイズ (view original Railscast) Other translations: Other formats: Written by Naomi Fujimoto 前回のエピソード[動画を見る, 読む]で、Railsアプリケーションでユーザ認証を行うためにdeviseを設定する方法を紹介しました。今回は、前回から引き続いてdeviseをカスタマイズする方法を見ていきます。 前回と同じアプリケーションを使うので、登録、ログイン、ログアウトのページがあり、すでにある程度の認証のしくみができています。 アクセスを制限する 次のステップでは、ログインユーザのみに特定のアクションへのアクセスを制限します。ログインしたユーザだけがプロジェクトを作成、編集、削除できるようにします。このためにProjectsControllerを修正しbefore_fi
OAuth Echo の Rails Gem
9. OAuth Echo • 認証をService Provider（Twitterなど）に 委譲するしくみ • クライアントがOAuth登録してあれば、 事前の登録やトークン取得が不要 12. POST http://api.twitpic.com/2/upload.json X-Auth-Service-Provider: https://api.twitter.com/1/ account/verify_credentials.json X-Verify-Credentials-Authorization: OAuth oauth_consumer_key="GDdmIQH6jhtmLUypg82g", oauth_nonce="oElnnMTQIZvqvlfXM56aBLAf5noGD0A QR3Fmi7Q6Y", oauth_signature="U1obTfE7Rs9J1ka
railsforumのrestful_authenticationは素晴らしい！それを見てRESTfulの理解も深まる - ザリガニが見ていた...。
最近、restful_authenticationで試行錯誤していて感じたこと。restful_authenticationはユーザー認証に関する必要最小限の機能を提供してくれるが、実際に運用できるレベルに仕上げるには、要点を押さえた的確な修正が必要になる。ユーザー認証のscaffold的な位置付けだろうと。 生成されるソースコードはとても簡潔にまとめられていて、読み易い。しかし、いざ自分好みのログインに修正しようとすると、実にいろいろな手段があり、どのような仕組みにするか本当に迷ってしまう。 例えば、以前の日記で試したパスワード忘れに対応する方法も、今振り返ってみれば最悪の例だ...。アクティベーションとパスワード忘れの処理が混同しているし、修正の手順もセキュリティ的に中途半端。実装の仕方もせっかくのrestful_authenticationのRESTfulなルールを無視している。やは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【Rails4.2.x】omniauth(twitter/facebook/github)実装まとめ - Qiita
Page Redirection
GitHub - NoamB/sorcery: Magical authentication for Rails 3 & 4
http://www.machu.jp/posts/20110522/p01/
GitHub - mbleigh/twitter-auth: Standard authentication stack for Rails using Twitter to log in.
