タグ

ブックマーク / qiita.com/uasi (7)

  • トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita

    トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べたAPIOAuthWeb TL;DR HTTP でトークンを利用した認証・認可をする手法として RFC 6750 がある OAuth に限らず、トークンを利用して認証・認可する機構の一部として Authorization: Bearer ヘッダを使うことができる 使い方について詳しくはこの記事の下のほうに書いた 要求 トークンを利用した認証・認可機構を持つ API を作りたい クライアントがトークンを HTTP リクエストに含めて送信し、サーバはトークンを検証してリソースへのアクセスを許可したい Authorization: Bearer トークン ヘッダでトークンを送る API あるよね、ああいうやつ 疑問 Authorization: Bearer ヘッダは OA

    トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita
  • Phoenix のコントローラで render/3 を呼んでからのレンダリング処理の流れを追う - Qiita

    Phoenix のコントローラでは render(conn, "index.html", foos: foos) のように render/3 を呼ぶことでビューをレンダリングすることができる。もろもろの事情があって、この処理の途中にフックして引数の値を書き換えてみたいと思った。 というわけで、コントローラで render/3 を呼んだら何がどうなって HTML がレンダリングされるのか追いかけてみた。 ネタバレ:この記事を読んで得られること この記事では、生成されたコードで使われているもののどこで定義されているか分からない関数から始まって、マクロで生成された関数定義に辿り着くまでを順を追って書いていきます。マクロを駆使した Elixir のコードにおいて、関数がどこで定義されているかを探す方法や考え方のヒントを得られる……はずです。分かりづらい箇所があればお気軽にコメントをください。 準備

    Phoenix のコントローラで render/3 を呼んでからのレンダリング処理の流れを追う - Qiita
  • Elixir の DSL がどう実装されているか、マクロの展開順を追ってみた(Plug.Builder を例に) - Qiita

    use Plug.Builder したモジュール内で plug :atom, [optional args] と書くことで、モジュールに他の plug を組み込むことができる。 マクロを駆使して実装された plug の中身がどうなっているのか、 Plug.Builder を再実装しながら追ってみることにした。 マクロの参考資料 Elixir Docs - Kernel Getting Started - Macros MyPlugBuilder の概要 Plug.Builder を丸ごと再実装するのは骨が折れるので、 plug マクロだけを提供するように単純化したモジュール MyPlugBuilder を作ることにする。 MyPlugBuilder は以下のように使う:

    Elixir の DSL がどう実装されているか、マクロの展開順を追ってみた(Plug.Builder を例に) - Qiita
  • English - 英語では「0オリジン」「1オリジン」とは(あまり)言わない - Qiita [キータ]

    配列の添字が0または1から始まることを日では「0オリジン」「1オリジン」と言うが、どうやらこれは和製英語らしい。一般的に英語ではそれぞれ zero-based, one-based と言う。 「添字が0から始まるインデックス方式」は "zero-based indexing"、「1から始まる添字を使った文字列アクセス」は "one-based string access" となる。 追記:zero-origin も使われているようだ。 zero-based index の検索結果、約170万件 zero-origin index の検索結果、約3万件 Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read ba

    English - 英語では「0オリジン」「1オリジン」とは(あまり)言わない - Qiita [キータ]
  • めちゃくちゃにコンフリクトしたファイルを一歩一歩マージする方法 - Qiita

    あるファイルに大量のコンフリクトが発生し解決が面倒なとき、パッチを使ってファイルに1コミットずつ変更を適用する方法を示す。この方法のメリットは: ファイルへの変更を1コミットずつ適用・コンフリクト解決することができる それぞれのコミットを適用する前に、コミットをパッチファイルの形で編集できる 注目するファイル以外への変更をいったん無視し、そのファイルに関係する変更に集中できる の3点である。複数コミットの変更が混ざった大量のコンフリクトマーカーを手作業で消すような状況に陥ったとき、この方法を使えばいくぶんかは楽にマージ作業を進められる。 概要 マージ中に特定のファイルに大量のコンフリクトが起きたら、マージを中止する。一時作業用ブランチを作り、そのファイルに1コミットずつパッチを当てて編集する。パッチを当て終わったらマージをやり直し、コンフリクト解決作業中に、コンフリクトしたファイルを一時作

    めちゃくちゃにコンフリクトしたファイルを一歩一歩マージする方法 - Qiita
  • Objective-C のコードレビューチェックリスト - Qiita

    はじめに 稿は Juri Pakaste 氏による Cocoa review checklist (commit fff5703)の翻訳です。他人の Objective-C のコードをレビューするとき注意する点、また普段のコーディングで心がけるべき点についてまとめられています。 なお、原文のタイトルは Cocoa review checklist となっていますが、内容が Cocoa に限らない範囲のトピックをカバーしているため、稿のタイトルは「Objective-C の〜」としました。 誤訳の指摘や例の補足を歓迎します。 コードの見た目とコード以外の問題 不要な #import や @class 宣言を消す #import をソートする .m ファイルの中では、対応する .h ファイルの #import を最初の行に書く。空行をはさんで、ソートされた他の #import を書く。 X

    Objective-C のコードレビューチェックリスト - Qiita
  • 英語のコメントや issue で頻出する略語の意味 (FYI, AFAIK, ...) - Qiita

    〔提案に対して〕いいと思う;問題ないと思う;〔コードレビュアーが、問題ないコードに対して〕レビュー終了;(コードの)承認

    英語のコメントや issue で頻出する略語の意味 (FYI, AFAIK, ...) - Qiita
  • 1