You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
やり方 私は、SNS認証をポップアップで行い、認証成功時にポップアップを閉じて、親ウィンドウ(元ウィンドウ)を閉じる、為に使いました。 ポップアップのページ(コールバックで指定したURLのページ)に以下のコードを記載するといいです。
なんかどうも OmniAuth を使おうと思ったらまず Session を有効にしろやと言われたり言われなかったりするので久しぶりにがっつりコードリーディングしてみた。 以下のバージョンで確認した。 Sinatra 1.4.7Rack 1.6.4OmniAuth 1.3.1まとめrack middlewareは記述順に依存する 具体的には OmniAuth の前に Rack::Session を use しておかないとダメなぜなら OmniAuth は session を利用できる前提で書かれているからrack middlewareの組み立てられ方 より正確にはアプリケーション本体をいちばん内側に包むたまねぎ構造sinatraのset :sessions, trueはどこに書いてもよい set :sessions, true は書く位置を自由にできるが、use Rack::Session:
読み返してたら滑ってて恥ずかしかったので冒頭の文を消しました。 タイトルでも滑ってるのに2重で滑るのは耐えられません。 今回は @pjxiao が SSHを使いこなしているのを見て悔しかったので自分もちゃんと理解しようと思い記事にしました。 Local forwarding開発者にとってはこれが最も一般的な使い方かなーと勝手に思ってます。 DBや内部システムで使われるサーバではアクセス元制限がかかっていることが多いんですが、動作確認のために接続したくなることはよくあります。 特に開発用のDBのレコードをローカル環境のプログラムで表示したくなるケースはとっても多いです。ね? こんなときに使うのが俗にSSHポートフォワーディングと呼ばれるもので、ローカルに対するアクセスをリモートに受け流す方法です。 (以降はローカルフォワーディングとか、単にフォワーディングという) L option具体的には
コメント欄で「Software Design 誌 (2018/12) に寄稿した内容や修正などをこちらの記事にも適用したい」と言ったあと、やるやる詐欺でずっと放置していましたが、三年近く経ってようやく 2021年 7月に大幅に改訂し、同時に Zenn に引っ越すことにしました。 タイムゾーン呪いの書 (知識編) タイムゾーン呪いの書 (実装編) タイムゾーン呪いの書 (Java 編) なにやら長くなりすぎたので三部構成になっています。 この Qiita 版は、しばらく (最低一年は) 改訂前のまま残しておきます。 タイムゾーンの存在はほぼ全ての人が知っていると思います。ソフトウェア・エンジニアなら多くの方が、自分の得意な言語で、タイムゾーンが関わるなにかしらのコードを書いたことがあるでしょう。ですが、日本に住んで日本の仕事をしていると国内時差もなく1 夏時間もない2 日本標準時 (Japa
この投稿は社内の Qiita:Team に書いた記事を加筆・修正したものです。 「まずは当たり前のことをやってから言え」 この言葉は前職でお世話になった先輩の言葉です。障害が起きたときに最後の砦と信頼されていたエンジニアの方です。 いま思うとこの言葉が自分のエンジニア人生をより良くしてくれました。 「信頼されるエンジニア = 技術力が高いエンジニア」とは限らない 以前は「信頼されるエンジニア = 技術力が高いエンジニア」だと思っていましたが、実際にはそうとは限りません(技術力が高いエンジニアを批判する意図はありません)。 社内で周りを見渡せば納得すると思いますが、多くの人から信頼を得ているエンジニアはこんな人ではありませんか? 有言実行である 仕事の納期をきっちり守る どんな仕事でもムラがない 困ったときに快く相談に乗ってくれる 皆がやりたがらないタスクを拾ってくれる チームの雰囲気を良い
TLS 1.3は現在策定中ですが、 前方秘匿性 の問題から RSAのみ を用いた鍵委共有が禁止になる見込みです。(詳細は後述します) HTTPSとは 次に、HTTPSです。 HTTPS - Wikipedia HTTPS(Hypertext Transfer Protocol Secure)は、HTTPによる通信を安全に(セキュアに)行うためのプロトコルおよびURIスキームである。 厳密に言えば、HTTPS自体はプロトコルではなく、SSL/TLSプロトコルによって提供される セキュアな接続の上でHTTP通信を行うこと をHTTPSと呼んでいる。 とのことです。 HTTPの説明を割愛するとすれば、「SSL/TLSでセキュアにHTTPをやる」というだけの説明で済んでしまいます。 最近では個人情報等の観点から全てのサイトをHTTPSにするような動きが見られますが、元々HTTPSが使われやすかった
もう3回目だよ DroidKaigi 2016のスタッフをやったはなし - S_Shimotori’s diary DroidKaigi直前のCONBUさんにお邪魔してきた - S_Shimotori’s diary 3週連続で西新宿に行ってきた #tryswiftconf #droidkaigi #落し物 - S_Shimotori’s diary なぜ参加したの 2016が大学を借りての開催で、会場案内くらいならできそうだったから その後は惰性 スタッフを辞める理由はなかったから 私以外のスタッフがAndroid開発のプロ、つよい わたしはSwiftを書きたいので仕方なくiOSやってる(バイト辞めたのでそれすらわからなくなった) iOSDCやtry! Swiftのコアスタッフをやろうものなら聞きたいセッションを全部聞くのは難しいだろうから、ここは専門分野を外してAndroidのスタッフ
ひつじです。 DroidKaigiおわったんですよ。みなさん、おつかれさまっした!!!!!!! このエントリはブログタイトルどおり、ひさしぶりの個人の日記並の感想文です。読んでも得られることは、ひつじのひととなり*1がわかる以外のメリットは無さそうです。 1000人規模のイベント(珍しい規模だけど特別ではないと思う)をどうやって運営したかという部分も興味があるひといるかもしれないので、ちゃんとしたまとめは別途やるかもしれないけど今回は、この一年間オーガナイザーとして関わってきたDroidKaigiが終わったあとの感想文です。読み進めてもヤマとオチはないので理解いただきたい。なお時系列も無視されているので気をつけて。 DroidKaigi 2018が終わった夜と、はじめてのDroidKaigi DroidKaigi 2018が終わった2月9日の夜、スタッフでささやか*2に打ち上げた帰り道。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く