Rubyで簡単、マッシュアップサービスを公開してみよう! - 第2回 - 簡単Sinatra!WebAPI・OAuth認証を使ってみよう 今回のワークは、前回学んだ「Sinatra Framework」と「Ruby」を応用し、皆さんが使ってみたいTwitter APIを使用したソースコードを提出するというものです。この記事ではオープンソースライブラリのRubygemsの使い方も解説しているので、参考に課題にチャレンジしてみてください。 第1回目だった前回は、「Ruby言語」とは何か、そしてRuby Frameworkである「Sinatra」とは何かについてお話した後、簡単にコーディングの仕方についてお伝えしました。 第2回目となる今回は、オープンソースライブラリである「Rubygems」と、前回学んだ「Ruby」と「Sinatra」を利用して、WebAPIやOAuth認証の利用方法をお
第8章 マッシュアップ セキュリティトークンとOAuth 2.0 OAuth 2.0は、アクセス認可の判断結果(誰々は、どこそこのリソースにアクセスしてよいということ)をネットワーク越しに安全に伝達することを目的としたプロトコル仕様である。このプロトコル仕様を公式に規定した RFC 6749,“The OAuth 2.0 Authorization Framework” が2012年10月に発行された。 マッシュアップに使われる素材サーバ中のリソースを、資格あるユーザに対してのみ開示するように保護して制御する案件において、OAuth 2.0は有用な手段となる。 セキュリティトークンと引き換えにリソースを得る構図 マッシュアップに組み入れるゲストリソースには、有償のものや守秘性の高いものもあり得る。このようなリソースを提供する素材サーバは、通常、アクセス制限を設け、これらを保護するようにする
今まで仕事上、業務システムを開発してきましたが、ブラウザでアクセスするWebアプリケーションばかりでした。 しばらくはWebアプリ開発も続くでしょうが、ようやくタブレット端末を会社で活用する流れが出てきたので、 せっかく開発したWebアプリにタブレット端末からでもアクセスできるように、WebAPIの実装について考えてみました。 なおjQueryMobileなどを使ったWebアプリにする選択肢もありますが、ここはあえてJSON/JSONPを返すWebAPIの実装を考えます。 仕様 http/httpsアクセスできるものとし、レスポンスはJSON/JSONPで選択できる。 業務システムなので、認証がある。 認証は一度行ったらログアウトなどをしない限り継続する。 認証部分はなるべく簡単に独自実装。 ログアウトも可能。 システムの利用ユーザーを変更する場合はログアウトして再ログイン。 エラーが発生
WebAPIの公開 APIとは、何らかの機能を提供するプログラムのことです。WebAPIとは、Webで提供されたAPIということです。たとえば、地図データを提供するAPIや商品の検索結果を提供するAPIが有名です。なるべく多くの人にアクセスしてほしい情報を持っている企業は、WebAPIとして情報を提供することが多くなりました。WebAPIという便利なインターフェースを用意することで多くのユーザにアクセスしてもらい、広告ビジネス等につなげていくのが狙いです。 またWebAPIは、多くの形式に対応していたほうが、多くのユーザに利用してもらうことができるため、なるべく多くの出力形式に対応しようとする傾向があります。以前はSOAPという形式が多く使われていましたが、実装方法が煩雑であったため、現在ではREST、JSON、JSONPのように実装がシンプルな形式のものが多く使われています。 WebAP
Google グループでは、オンライン フォーラムやメール ベースのグループを作成したり、こうしたフォーラムやグループに参加したりすることで、大勢のユーザーと情報の共有やディスカッションを行うことができます。
最近、Web APIの認証をどうすべきか考えている。 例えば次のようなケースをどうするか。 「既存のWebサイトがあり、既にユーザIDとパスワードによる認証によって、ブラウザでデータを提供している。 今回、この提供データをブラウザの画面ではなく、REST APIにて取得可能にしたい。 このデータはユーザ毎に取得可能な値が違うので、認証、または認可によって制限をかけたい。」 ユーザーがブラウザからIDとパスワード(以下ID/PW)を使ってログインする方式を、そのままWeb APIにも適用しても安全なのだろうか。 Web APIの先にはスマホアプリやシェルスクリプトなどから直接ログインするものなどが考えられるが、安全かつシンプルに実装するにはどうしたらいいのだろうか。 私はセキュリティの専門家ではないので間違った考え方をしている可能性もあるが、誰かの目に留まって助言いただけるかもしれないので、
CRYPTREC暗号リスト (電子政府推奨暗号リスト) 電子政府における調達のために参照すべき暗号のリスト (CRYPTREC暗号リスト) デジタル庁、総務省及び経済産業省は、CRYPTRECの活動を通して電子政府で利用される暗号技術の評価を行っており、2023年3月に 「電子政府における調達のために参照すべき暗号のリスト(CRYPTREC暗号リスト)」(最終更新:2024年(令和6年)5月16日、CRYPTREC LS-0001-2022R1、初版:2023年(令和5年)3月30日)を策定しました。 CRYPTREC暗号リストは、電子政府推奨暗号リスト、推奨候補暗号リスト及び運用監視暗号リストで構成されています。 「政府機関等のサイバーセキュリティ対策のための統一基準(令和5年度版)」(令和5年(2023年)7月4日、サイバーセキュリティ戦略本部)において、以下のとおり記載されており、政
Copyright © 2004-2024 Impress Corporation. An Impress Group Company. All rights reserved.
Special Publication 800-92 コンピュータセキュリティログ管理ガイド 米国国立標準技術研究所による勧告 Karen Kent Murugiah Souppaya この文書は下記団体によって翻訳監修されています NIST Special Publication 800-92 コンピュータセキュリティログ管理ガイド 米国国立標準技術研究所による勧告 Karen Kent Murugiah Souppaya コンピュータ セキュリティ 米国国立標準技術研究所 情報技術ラボラトリ コンピュータセキュリティ部門 Gaithersburg, MD 20899-8930 2006 年 9 月 米国商務省 長官 Carlos M. Gutierrez 技術管理局 技術担当商務次官 Robert C. Cresanti 米国国立標準技術研究所 所長 Willia
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く