2018年3月23日、24日に開催された MANABIYA -teratail Developer Days- https://manabiya.tech の「2018 年の Web 標準」のセッション資料です。
We — Manton Reece and Brent Simmons — have noticed that JSON has become the developers’ choice for APIs, and that developers will often go out of their way to avoid XML. JSON is simpler to read and write, and it’s less prone to bugs. So we developed JSON Feed, a format similar to RSS and Atom but in JSON. It reflects the lessons learned from our years of work reading and publishing feeds. See the
2014-05-27 URI はクライアントにとって不透明であるべき??? HTTP URI よちよち.rb で『Web を支える技術』の読書会をしています。先日、P.63「5.6 URIの不透明性」の部分を読み合わせてのですが、ここに書いてあることが私には腑に落ちませんでした。この章での主張を引用します。 URI の内部構造を想像して操作したり、クライアント側でURIを構築したりしてはいけません。なぜなら、サーバ側の実装でURIの構造を変更したとたんにシステムが動かなくなってしまう、いわゆる密結合状態になるからです このように、URIをクライアント側で組み立てたり、拡張子からリソースの内容を推測したりできないことを、「URIはクライアントにとって不透明(Opaque)である」と言います。 「クライアントにとって不透明ではない URI を使うと密結合状態になってしまうのではないか」という
This post will explore the concept of refresh tokens as defined by OAuth 2.0. We will learn how they compare to other token types and how they let us balance security, usability, and privacy. You can follow the text in this post, or if you prefer learning from presentations, you can watch this article’s companion video: What Is A Token?Tokens are pieces of data that carry just enough information t
Note: JWT の仕様やそもそも論の話は触れません。どう使うか、何が出来るかしか書いていません。 JSON Web Token? JSON Web Token とは、ざっくりいって署名の出来る JSON を含んだ URL Safe なトークンです。 署名とは、署名時に使った鍵を用いて、JSON が改ざんされていないかをチェック出来るようにすることです。 URL Safe とは、文字通り、URL に含めることの出来ない文字を含まないことです。 これだけだとよくわかりませんが、触り心地としては次のような性質があります。 発行者だけが、鍵を使ってトークンが正しいことを検証出来る。 暗号化ではないので、JSON の中身は誰でも見られる。 仕様的には、暗号化のオプションもあります。 しかしながら、JSON の変更は出来ない。(改ざんをすると、検証時に失敗するので。) 全体的には、なんか変更できな
「OAuth 認証」って言葉が出てくると、「認証と認可は違う」とか言い出す人が出てきて、大体の場合「OAuth 認証」言ってた人たちがやりたいことの話とはズレた議論が始まるので、もういっその事「OAuth 認証」とは何かを定義してみましょうかね。 「OAuth 認証」で Relying Party (RP) がやりたかったこと RP (OAuth Client) は、ブラウザの前にいる人を、認証したかったんですよね? もう少し正確にいうと、ブラウザの前にいる Entity が、RP 側で把握しているどの Identity と紐付いているか、というのを知りたかったんですよね? いきなり Entity とか Identity とかいう専門用語が出てきてアレですが、そのあたりのことは先日の OpenID TechNight #13 でもお話ししたので、以下のスライドの Entity・Identi
Strategies, standards, resources to make the Web accessible to people with disabilities This collection of tutorials shows you how to develop web content that is accessible to people with disabilities, and that provides a better user experience for everyone. The tutorials are designed to be used by a variety of individuals, including: Web developers will find guidance and boilerplate solutions for
特定のAPIを利用するコマンドラインツールやサービスを書く場合はClientパッケージ(SDKと呼ばれることも多いが本記事ではClientと呼ぶ)を使うことが多いと思う.広く使われているサービスのAPIであれば大抵はオフィシャルにClientパッケージが提供されている.例えば以下のようなものが挙げられる. https://github.com/aws/aws-sdk-go https://github.com/Azure/azure-sdk-for-go https://github.com/PagerDuty/go-pagerduty https://github.com/hashicorp/atlas-go 特別使いにくい場合を除けば再実装は避けオフィシャルに提供されているものを使ってしまえばよいと思う(まともなものなら互換性などをちゃんと考慮してくれるはずなので).一方で小さなサービ
https://blog.hatena.ne.jp/{はてなID}/{ブログID}/atom/entry/{entry_id} https://blog.hatena.ne.jp/{はてなID}/{ブログID}/atom/page/{page_id} 各変数の意味と書式は次のようになります。 はてなID 意味:あなたのはてなID ブログID 意味:ブログのID 書式:ブログのドメイン (例: example.hatenablog.com) ルートURL 意味:ブログのトップページのURL 書式:ブログのドメイン。サブディレクトリオプションを利用している場合はサブディレクトリも含む (例: example.hatenablog.com, example.com, example.com/subdirectory) entry_id: 意味:ブログエントリのID 書式:epochを表す数値 (
Googleリーダーが2013年7月1日でサービスを終了して依頼、3年近くfeedlyを愛用してきましたが、最近試してみたinoreaderがあまりにも快適だったため、一瞬で乗り換えてしまいました。 過去にも様々なRSSリーダーを試しては消し、試しては消してきましたが、やっと一番使いやすいRSSリーダーに出会えたなという気持ちです。 そこで今回はinoreaderをまだ試したことが無いという方に向けて、魅力をたっぷりとお伝えできればと思います。 <目次> 1. アプリからもウェブブラウザからも! 2. 日本語対応 3. インポート・エクスポート対応。もちろんFeedlyからの乗り換えも可能! 4. フィルタリング機能が凄い 5. 既読の方法も豊富 6. キーボードショートカットも 7. 複数アカウントの購読も可能(アプリのみ) 8. リストビューで完全なタイトルを表示 9. 記事の表示方法
本記事は英語版ブログで公開された記事の翻訳版です。 2013年7月に、米国テキサス州オースティンで開催されたLonestar Ruby Conferenceで、Rubyによるアプリケーションサーバーについてお話させていただきました。その中でいくつかのRubyアプリケーションサーバーのパフォーマンスや、さまざまな状況における挙動の違いを比較しました。この記事では、講演準備として行ったリサーチの中で分かったことをかいつまんでご紹介します。 実際のカンファレンスの録画をご覧になりたい方は、Confreaksで公開されていますのでそちらをご参照ください。テストに使用した簡単な自作アプリケーションはGitHubに、講演スライドはSlideshareにそれぞれ公開しています。 このリサーチは、Passenger 4のパフォーマンス評価以外すべて2013年7月に行ったものなので、情報が多少古くなっている
最近まで、SSL暗号化通信は「あると好ましい機能」という程度にしか考えられていませんでした。そのため、安全なのはアプリのログインページだけというサービスが数多く存在していました。 しかし、状況は良い方向へと変化しています。現在では暗号化は必須と考えられ、ほとんどの開発者が導入を義務付けています。また、巨大検索エンジンGoogleでは、SSLの導入が検索結果の順位を決定する要因にさえなっています。 しかし、SSLが広範に普及しているにも関わらず、セキュアなWebサービスを構築することは、未だに面倒で、時間がかかり、エラーの原因になりやすいと考えられています。 最近この分野では、 Let’s Encrypt が、SSL証明書をより広く普及させ、Webサイトのセキュリティ維持に係るワークフローを大幅に簡略化しようと取り組んでいます。 強力なWebサーバNginxや、他のハードニング方法と組み合わ
By Sean MacEntee SSLを用いたHTTP通信の暗号化を誰でも手軽に行えるようにするために立ち上がったのがEFF、Mozilla、Cisco Systems、Akamai Technologies、IdenTrust、ミシガン大学の研究者などで、これらのメンバーがHTTPS普及のためにスタートした取り組みが「Let's Encrypt」です。これまで手間がかかり金銭的な負担も大きいと言われてきたサーバー証明書の発行を無料で行えるようになるのですが、同取り組みはついにベータ版から正式版にサービスを移行しています。 Leaving Beta, New Sponsors - Let's Encrypt - Free SSL/TLS Certificates https://letsencrypt.org//2016/04/12/leaving-beta-new-sponsors.h
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く