ビックカメラでヘッドホンを視聴 audio-technica アートモニターシリーズ 密閉型ヘッドホン ATH-A500X Audio Technica(オーディオテクニカ)Amazon 気に入って使っていたオーディオテクニカのATH-A500Xが壊れて片耳が聴こえなくなってしまったので、同じオーディオテクニカでヘッドホンを買い換えたいと思っていた。 年始の帰省帰りに名古屋駅近くのビックカメラに寄る機会があったので、ヘッドホンを試聴してみる。オーディオテクニカのヘッドホンに的を絞って手持ちのiPhoneに挿して聴き比べてみる。最初にビックカメラおすすめヘッドホンランキング的なコーナーにあるヘッドホンを聴いてみた（機種は確認しておらず不明）。音に迫力はあるものの低音がゴツ過ぎてちょっとキツい。 次に元々持っていたATH-A500Xに見た目が似ているヘッドホンを聴いてみる。これは素晴らしく感動

2020年1月9日 6時18分 リンクをコピーする by ライブドアニュース編集部 ざっくり言うと Twitterが、投稿にリプライできる人を制限するオプションの追加を予告した 従来通り誰でも会話に参加できる形か、制限する形か選択できるようになる 4種類が用意され、それぞれのオプションはツイートの下に表示されるという Twitter が「会話に参加できる人」、つまりツイートにリプライできる人の制限オプションを予告しました。 年内に提供予定のアップデート後は、ツイートを入力する際に「グローバル」(従来どおり誰でもスレッドに参加できる)や「グループ」(自分がフォローしているユーザーとメンションしたユーザーのみ)など、会話に参加できるユーザーの種類を選択できるようになります。 Twitter は従来、 オープンな対話を促進する云々のミッションから、プライベートな会話には鍵付きアカウントやグループ

カルロス・ゴーンのスペルがGhosnからGoneに変わってしまった今回の脱出劇。海外でも｢映画化決定！｣なんて言われています。特に海外から見て目がテンになる部分をまとめてみました。 No one suspected his disguise pic.twitter.com/yHl4MDrjtn — Elon Musk (@elonmusk) January 1, 2020｢まさか変装だとは誰も見抜けなかった｣ 1. GPSアンクレットがない逃亡の恐れのある保釈中の容疑者は孫悟空のような輪っかが足にかけられて、圏外に出るとビビビビーッとアラートが鳴るのがアメリカなどでは普通です。そのため｢ゴーン逃亡｣と聞いてみな真っ先に考えるのは｢すごいハッカー雇ったな｣ということ。｢装着していなかった｣と聞いて二度驚くポイント。 2. 新幹線に普通に乗っている トランクに身を潜めたと思いきや、｢新幹線で品

ユーザー認証周りのAPIを作っていたのですが、その中でJWTの仕組みを使いました。使い方はシンプルで分かりやすく比較的簡単にセキュリティ向上を見込めると感じたのですが、日本語の資料がまだ少なく敷居が高い印象でした。使ってみたら予想以上に便利だったのでメモを共有します。 間違いなどありましたら指摘お願いします。 JWT概要 JWTは「Json Web Token」の略 JWTはjsonをトークン化する仕組み 改ざん出来ないjsonと思ってもらえればOK Signed JWT JWTがサポートしている署名アルゴリズム HMAC : 共通鍵方式 RSA : 公開鍵方式 ECDSA : 楕円曲線暗号（あまり使われ得ていない） 運用 秘密鍵と公開鍵を作っておく 送りたいデータを秘密鍵でエンコードし、レスポンスとして返す 帰ってきたJWTをセッションに保存 受信側は公開鍵を使ってトークンをデコードし、

Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up

とくに、英語の decryption を日本語でなんと呼ぶかは人によってまちまちです。 復号 と呼んでいる人もいるのですが、復号は decode の訳語として使いたいので、このエントリでは 平文化 を使います。 公開鍵暗号とは 玄関の鍵は閉めるときも開けるときも同じ鍵を使います。金庫の鍵も普通はそうです。では 金庫に貴重品を詰めて送ってもらう時はどうでしょう? 金庫を閉める鍵と開ける鍵が同じだと、金庫にものを詰めてもらう相手にその鍵を渡す必要があります。その鍵を郵送で送ろうとしたら、途中で誰かに見られて複製を作られてしまうかもしれません。大事なものを送るために鍵をかけようとしているのに、同じ労力をかけて鍵を受け渡さなければいけないとなると本末転倒です。 これは、暗号通信でも同じことが言えます。 そこで、暗号通信において 閉めることしかできない鍵 と 開けることしかできない鍵 のペアを使うこ

この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "公開鍵暗号" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2012年2月） 推測できない数（典型的にはランダムに生成した巨大な数）を用いて、最初に非対称鍵アルゴリズムに適した鍵のペアを生成する。 非対称鍵暗号化のスキームでは、公開鍵を使用して誰でもメッセージを暗号化できるが、そのメッセージを復号できるのはペアの秘密鍵の所有者だけである。システムの安全性は、秘密鍵が秘匿されているという点に依存するので、秘密鍵は決して他の誰にも知られてはいけない。 この例では、メッセージは暗号化されたデジタル署名である。まず、Aliceはメッセージを秘密鍵

はじめに OAuth や OpenID Connect に関連する仕様を紹介していこうと思います。 仕様はたくさんあるものの、ほとんどオプショナルです。しかし、「認可サーバーを実装する際は、RFC 6749 だけではなく、認可コード横取り攻撃への対抗策である RFC 7636 も実装すべきである」* という点は強調しておきたいと思います。 * 「PKCE: 認可コード横取り攻撃対策のために OAuth サーバーとクライアントが実装すべきこと」という記事もご参照ください。 1. OAuth 2.0 (RFC 6749) OAuth 2.0 の仕様の本体は RFC 6749 (The OAuth 2.0 Authorization Framework) です。RFC 6749 の解説記事は世の中にたくさんあるので、ここでは要点だけ手短に紹介します。 RFC 6749 は、アクセストークンを発行

パッチ会や地域 Ruby コミュニティなどで集めた知見を元に、勤務先の永和システムマネジメントなんかで度々話している表題についてテキスト化しておく。 TL;DR Ruby 2.8.0 の開発が始まっているが、それは 2020 年のどこかで Ruby 3.0 になるらしい Ruby 3.0 ではキーワード引数 (以下 kwargs) の分離という破壊的変更があり、Ruby 2.7 系は事実上の移行パスバージョン的な位置付けになるだろう 2020年1月8日の現時点では、Ruby 2.7 の kwargs の分離警告について対応された安定版の Rails はなく、周辺 Gem も WIP なので OSS エコシステムに参加していくと良い 2.8.0 (tentative; to be 3.0.0) development has started 2019年の ruby/ruby での matz

Font Awesome アイコンの基本的な使い方をはじめ、Webサイトやスマホアプリでアイコンを使う時の便利な機能をまとめて紹介します。 Font Awesome guide and useful tricks you might not know about. by Kiss Patrik 下記は各ポイントを意訳・加筆したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 更新: 2021/2/1現在の最新情報にアップデートしました。 Font Awesomeとは Font Awesomeへの登録方法・アイコンの基本的な使い方 Font Awesome アイコンのサイズの指定方法 Font Awesome リスト用のアイコン Font Awesome アイコンの回転 Font Awesome アイコンのアニメーション Font Awesome アイコンを

（新元号が発表されましたね。いらすとや さん仕事早い.....!） 新社会人・学生の皆さま、御入社・御入学おめでとうございます！ はじめまして。プラットフォーム事業本部の Kikuchi です。 普段は Cloud IoT OS のアカウント管理・認証・権限管理周りの機能検討や設計・開発をやっています。 主な開発言語 は Rust ではなく Ruby です。 Object#tap とか可愛いですよね。 さて、少し前のことですが、OpenID TechNight #16 ~ OpenID Connect 5周年記念 というイベントで、「OPTiM サービスでの OAuth 2.0/OpenID Connect と周辺技術の活用事例」というテーマで Lightning Talks をさせていただきました。 LT ということもあり時間が限られていたため、今回はネタ落ちした内容をご紹介していこうか

連載 INDEX 次回 → はじめまして、OpenID Foundation Japan事務局長のNovです。 このたびは、Build InsiderでOAuth 2.0とOpenID Connectに関する記事を書かせていただくことになりました。 今回はOAuth 2.0、次回はOpenID Connectについて、ユースケースごとのフロー（Flow）や関連仕様についてまとめていきます。 OAuth 2.0仕様策定から5年 OAuth 2.0はIETF OAuth WG*1で仕様策定されている標準仕様群である。 最もコアとなるRFC 6749＆RFC 6750はどちらも2012年にRFC化されており、すでに策定から5年以上が経過している。OpenID Foundation Japanの翻訳WGでもこれらは翻訳済みである。 The OAuth 2.0 Authorization Frame

おはようございます、ritouです。 今回は、一部で先週話題なりましたOAuth 2.0のImplicit Flowについてのエントリになります。 (2012/2/7 いろいろと修正しました。) 単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる | @_Nat Zone Thread Safe: The problem with OAuth for Authentication. 今回は以下の内容について整理したいと思います。 OAuth 2.0のどの機能にセキュリティホールがあるのか 誰が攻撃者になれるのか 対策 OAuth 2.0 Implicit Flowとは OAuth 2.0ではサードパーティーアプリケーションが保護リソースへのアクセス権限を得るためのいくつかのフローが定義されています。 (仕様中ではFlowやGrant Type

HTTP ガイド リソースと URI ウェブ上のリソースの識別 データ URL MIME タイプ入門 よくある MIME タイプ www 付きと www なしの URL の選択 HTTP ガイド HTTP の基本 HTTP の概要 HTTP の進化 HTTP メッセージ 典型的な HTTP セッション HTTP/1.x のコネクション管理 プロトコルのアップグレードの仕組み HTTP セキュリティ Content Security Policy (CSP) HTTP Strict Transport Security (HSTS) X-Content-Type-Options X-Frame-Options X-XSS-Protection サイトの安全化 HTTP Observatory HTTP アクセス制御 (CORS) HTTP 認証 HTTP キャッシュ HTTP の圧縮 HTT

Speee開発部では、ものづくり組織を強固にし、プロダクト開発力を高めていくため、社内外関わらず最適な手法で日々改善改良に努めています。 今回はSpeee開発部の中でも、リアル産業の進化に対しデータとテクノロジーを用いて取り組んでいるデジタルトランスフォーメーション事業本部に、Ruby界隈で幅広く活躍されている角谷信太郎さんにお手伝いしていただいたお話を紹介したいと思います。 なぜこの記事を書くのか？Speee開発チームをもっと赤裸々に知ってもらいたい！という思いです。 私たちは日々新たな課題にぶつかり、改善し、PDCAを回していく成長途中のフェーズ。今回のような事例を紹介する事により、外からは見えづらい現場の様子や課題をお伝えできるのではないかと思いました。 この記事で話すことなぜ角谷さんを呼んだのか？角谷さんはどんな人？Speeeとの接点は？開発チームの課題、どうやって改善したのか？そ

base64とは base64という言葉を聞いたことがあるでしょうか？？ base64とは、64進数を意味する言葉で、すべてのデータをアルファベット(a~z, A~z)と数字(0~9)、一部の記号(+,/)の64文字で表すエンコード方式です ただ、データ長を揃えるためにパディングとして末尾に記号の=を使用するので、厳密にはbase64は、65文字の英数字から表現されます (URLや正規表現のなかでbase64を用いると一部の記号(+,/)は特別な意味を持つことがあるので-や_などが用いられることがあります) なぜbase64をつかうの？？ かつての電子メールを送るためのプロトコルSMTPでは、ASCIIといわれる7bitで表現される英数字しか送ることができませんでした したがって、メールを使って画像や音声などのデータをやりとりしたいと思った時に、英数字しか対応していないSMTPでは、それら

これは tl;dr curl で Basic 認証を利用する場合 Authorization ヘッダ を利用する場合 RFC で Authorization ヘッダや Basic 認証周りの情報をチェックしてみた RFC2617 HTTP Authentication: Basic and Digest Access Authentication RFC7235 Hypertext Transfer Protocol (HTTP/1.1): Authentication 以上 これは qiita.com 初老丸 Advent Calendar 2017 3 日目になる予定の記事です. tl;dr ヘッダに付与する認証文字列を Base64 でエンコードする時にハマったのでメモ curl で Basic 認証を利用する場合 これは皆さんご存知の書き方. curl --basic -u $us

HTTP ガイド HTTP の概要 典型的な HTTP セッション HTTP メッセージ MIME タイプ（IANA メディア種別） HTTP の圧縮 HTTP キャッシュ HTTP 認証 HTTP Cookie の使用 HTTP のリダイレクト HTTP 条件付きリクエスト HTTP 範囲リクエスト コンテンツネゴシエーション HTTP/1.x のコネクション管理 HTTP の進化 プロトコルのアップグレードの仕組み プロキシサーバーとトンネリング HTTP クライアントヒント HTTP セキュリティ サイトの安全化 HTTP Observatory Permissions Policy コンテンツセキュリティポリシー (CSP) オリジン間リソース共有 (CORS) Cross-Origin Resource Policy (CORP) Strict-Transport-Securit