#13 ロリポップのWordpressにソーシャルログイン(Facebook、 Google)をPluginのGianismで実装する - Qiita
#13 ロリポップのWordpressにソーシャルログイン(Facebook、 Google)をPluginのGianismで実装するWordPressFacebookgoogleapi ロリポップ上にインストールしているWordpressに対して、ソーシャルログインを実装します。 ソーシャルログインの方法はいくつかありますが、 今回はメジャーどころのFacebookとGoogleでやってみます。 普通にSDKで実装してもいいですが、せっかくWordpressを使っているということでPluginを利用します。Pluginは国産のGianismを利用します。 Gianismは使いやすいのでオススメです。他のプラグインなどと組み合わせたりすれば、 より柔軟に会員サイトのように作ることも可能です。 利用するもの ・サーバーロリポップ ・Wordpress ・Plugin Gianism ・Fac
Facebook Relayについてまとめ - Qiita
Reactがもっと広まって欲しいと思っている今日このごろ。React EuropeでJoseph Savona氏の講演でRelayについての「モヤっと」がいっきにかなり解消された気がするので、要点を本編を翻訳しながら自分なりにまとめておきます。 私の理解が誤っている可能性は十二分にありえるので、ご指摘いただければ幸いです。 はじめに ReactとFluxって組み合わせと共によく目にするのが↓の図。 矢印は一方向にしか進まないのが特徴で、わかりやすいってのがいろんなところで書かれているんですけど、 結局データをサーバからとってくるところってどうなってるの？ってのが疑問として残ります。つまり、図で表現すると↓の部分の仕組みがどうなっているかってところです。 その部分を、Instagramのようなサービスを例に説明しています。 クライアントはどのようにしてサーバからデータを取得すべきか まず、I
Titanium ＋Alloy＋ACSの構成でユーザーログインでFacebookアカウントを利用する - Qiita
はじめに Titanium SDK 3.1以降、Titianium.Facebookモジュールではなく、Modules.Facebookに変更になってます。（詳しくは公式サイトを） モジュールの導入時のセットアップで多少異なる点があるけど基本的な使い方としては大きな変更は無くその点での戸惑いはなかったのですが、Modules.Facebookを利用してACSへのユーザーログインでFacebookアカウントを利用する処理方法について情報がまとまっておらず、仕事で必要だったので調べたものをまとめることにしました。 想定する方 一応以下のような方を想定してまとめてみました。 Titanium Mobileでサンプルコードを書いたことはある ACSという言葉は聞いたことがある OAuthの概念はなんとなく知ってる やりたいことはシンプルなのですがそれに関連するベースの知識が色々問われてくるため関連
RailsでいろんなSNSとOAuth連携/ログインする方法 - Qiita
Deviseというgemのomniauthableを利用して、いろんなOAuth提供元サービスと連携orそのサービスを用いたログインを実現する方法。 こういうことやりたい人結構いるんじゃないかと思って、Wantedlyで実際にやってみた経験を大公開！！ Gemのインストール deviseと各providerのomniauth関連Gemをインストール gem 'devise' gem 'omniauth' gem 'omniauth-facebook' gem 'omniauth-github' gem 'omniauth-google-oauth2' gem 'omniauth-hatena' gem 'omniauth-linkedin' gem 'omniauth-mixi' gem 'omniauth-twitter' とりあえず、omniauth-'provider'でググって出て
Facebook, Twitter, Instagram等がどうやってIDを生成しているのか まとめ - Qiita
まえがき データにIDを持たせたいとき、単純な方法としては、DBの提供するauto incrementを使う場合やUUIDを利用することがある。それぞれの方法の利点欠点は以下の通り。 データベースのauto incrementを使う場合 利点: 特別な実装が必要ない 欠点: DBを1台で運用するとデータベースがパフォーマンス・障害のボトルネックになる DBを二台にするとIDのユニークさや順序の保証が困難 UUID(v4)※1を利用する場合 利点: 分散環境で各々がIDを生成しても衝突しない IDを公開したくない場合に、推測されにくいIDを生成できる 欠点: 128ビット必要、DBのインデクシングやプログラミング言語で扱うときに不利なことがある IDから時間の情報が失われる、例えば2つのIDを比べてどちらが古い投稿か判断できない 世界の大企業がどうしてるか 調べてみると多くの企業がブログなど
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://qiita.com/kenokabe/items/7bc03b751776ec080da8
