タグ

2022年1月29日のブックマーク (7件)

  • 「勝手に学ぶ人」と「期待されて学ぶ人」の差が埋められない|柴田史郎

    ここ1年ぐらい感じていた「学びに関する格差」の話を書く。 最初にまとめ・勝手に学ぶ人は、自分の周囲にある「学びに使えそうな仕事」を探して自分の仕事にすることを繰り返す ・期待されて学ぶ人は、上司とかの期待に応えて新しいことを学ぶ ・「勝手に学ぶ人のスピード」>「期待されて学ぶ人のスピード」なので、格差が開いていく ・「早く行きたければ一人で行け、遠くへ行きたければみんなで行け」が実現できない ・勝手に学ぶ人を止める理由も見つからない ・困ったなあ(解決策わからない) では詳細を書いていく。 勝手に学ぶ人:自分の周辺にある「誰も手をつけてない仕事」を発見し、自分の学びに利用するそれぞれが自分の担当範囲の仕事をしているとする。 それぞれが自分の担当範囲の仕事をしている勝手に学ぶ人は、「誰も手をつけてない」かつ「自分の学びになりそうな」仕事を自ら発見して、自分の仕事として取り組む。 勝手に学ぶ人

    「勝手に学ぶ人」と「期待されて学ぶ人」の差が埋められない|柴田史郎
  • RailsでPOSTリクエストではリダイレクトできないことへの対応

    Rails では POST リクエストによるリダイレクトができないようです。というか、HTTP protocol の RFC で定められていて、POSTリクエストではリダイレクトできないらしい。GETのみ。Stack Overflow に書いてありました。 ruby – redirect_to using POST in rails – Stack Overflow — 環境 — rails-4.0.1 devise-3.2.2 HTTP の POST メソッドによるリダイレクトはできなかった 想定したケースは、ログインしていないユーザーが、フォームのサブミットによる POST リクエストで複数ページを遷移している途中で、ログイン用ページに移動してログインした場合。この POST リクエストのページ遷移では DB に対する処理はなし。ショッピングカートのようにセッションに情報を保存させるだ

    RailsでPOSTリクエストではリダイレクトできないことへの対応
  • OpenID Connectユースケース、OAuth 2.0の違い・共通点まとめ

    OpenID Connect概要 OpenID Connectをひと言で説明すると、 OAuth 2.0 + Identity Layer = OpenID Connect という表現が最もふさわしい。 OpenID Connectは、「OAuth 2.0を使ってID連携をする際に、OAuth 2.0では標準化されていない機能で、かつID連携には共通して必要となる機能を標準化した」OAuth 2.0の拡張仕様の一つである。 OpenID Connect登場以前は、OAuth 1.0/2.0ベースのID連携の仕組みがTwitterやFacebookなどの巨大SNSから提供され、人気を博した。これらの仕組みは今でも広く利用されている。 一方で、OpenID Connectの1つ前のバージョンのOpenID 2.0では、ID情報の連携はできるもののAPI連携には利用できないなど、デベロッパーに強

    OpenID Connectユースケース、OAuth 2.0の違い・共通点まとめ
  • OmniAuth(OAuth2)処理をキックしたときのパラメータを認証用リクエストにも渡したい - Qiita

    はじめに RailsアプリにOAuth2認証を導入する場合に利用できるOmniAuthがあります。 TwitterGitHubなどの外部認証用にすでにいくつもStrategyが用意されています。 リストにない場合は自作することになりますが、認証サービス用のStrategyを作成時にはまった点を紹介します。 特にOmniAuth処理をキックされたときの動的なパラメータを扱う点は、検索しても情報が見つけられなかったので苦労しました。 参考になれば幸いです。 ここで取り上げるポイント OAuth用のURLを変更する callback_urlの注意点(デフォルトのままだとエラーになってしまうパターン) OmniAuth処理をキックされたときのパラメータを認証時のパラメータとして渡す OmniAuth処理をキックされたときのパラメータをapi呼び出し結果に格納する OAuth2の処理の流れはこちら

    OmniAuth(OAuth2)処理をキックしたときのパラメータを認証用リクエストにも渡したい - Qiita
  • 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

    OmniAuth関連のURLを変更する - Qiita
  • OAuthでomniauth-facebookが何をやっているかを見てみた - Qiita

    背景 omniauthを使ってFacebookとのOAuthをやってみた、といった記事はネット上にたくさん転がってる。 けど、どうやって実現しているかについて、詳細を解説しているサイトを見かけたことがなかったのでまとめておく。 対象バージョン omniauth (1.2.1) omniauth-oauth2 (1.1.2) omniauth-facebook (1.6.0) アプリとFacebookとの間に立ってFacebookとのOAuthをしてくれるgem。 中核となるOmniAuth::Strategies::Facebookクラスはrack middlewareになっていて、特定のパスへのアクセスを起点にOAuthのリクエスト開始・Callback処理を行う仕組みになっている。 継承関係 OmniAuth::Strategies::Facebookの継承関係は以下の通り。 OAut

    OAuthでomniauth-facebookが何をやっているかを見てみた - Qiita
  • ユーザーをログアウトから守れ!―シーケンス図から読み解くログイン状態維持【Webアプリ編】 | DevelopersIO

    認証というのは面倒なもので、利用者に余計な手間を掛けさせてアクティブ率を下げたくないと日夜工夫を凝らす我々にとっては、やり玉に上がりやすいテーマであると思います。要するに、ユーザーをログアウトさせたくないわけです。さて、どうしましょう? 生魚おじさん、都元です。今月の魚はアジです!アジをべましょう。 さて、認証というのは面倒なもので、利用者に余計な手間を掛けさせてアクティブ率を下げたくないと日夜工夫を凝らす我々にとっては、やり玉に上がりやすいテーマであると思います。要するに、ユーザーをログアウトさせたくないわけです。 例えば Facebook や Twitter のページはいつ訪問しても自分のアカウントでログイン状態になっています。 最後にログインしたのはいつでしたっけ? 覚えていませんよね? これがおそらく皆さんの理想です。 セッションによるログイン ログインには通常、Cookie

    ユーザーをログアウトから守れ!―シーケンス図から読み解くログイン状態維持【Webアプリ編】 | DevelopersIO