Go で書いたプログラムで、HTTP(S) による通信を行うとなぜか10秒間プログラム (goroutine) がストールして、その後正常に通信が行えるという謎な現象に悩まされ、無事解決できたのでここにメモしておきます。 といっても、解決のためにやったことといえば、Go のバージョンを 1.11.1（バグが修正されたバージョン）に上げただけなのですが😅 「同様の問題にハマっている人が多いみたいなので知見を共有すればよいのでは」という同僚の id:moznion のすすめもあって書いてみることにしました。 TL;DR 問題の内容と、解決に至るまでの経緯を時系列順に書き下してみます。 まず問題に気づいたのは、私が関わっているある Web サイトのログインなどの処理がやけにもっさりしているという報告を受け、それを私も確認したタイミングです。 エラーになるわけではないのですが、特定の API を

ForSchool事業部の石上です。ウェブのフロントエンドを中心にStudyplus for Schoolの開発に携わっています。 あるアプリケーションのElmのバージョンを0.18から0.19に上げる対応をしました。今回はこのことについて書きます。 背景 Studyplus for School で新たにちょっとしたサブシステムが必要になり、その小さなSPAのためのウェブフロントエンドの言語として今回、Elmを採用しました。 弊社のプロダクトのほとんどは、サーバーサイドはRuby on Railsで作られており、ウェブフロントエンドはJavaScriptかTypeScriptです。Elmでウェブのフロントエンドを書くことはけっこう挑戦的でしたが、会社としても他の言語に手を伸ばしていきたいという話もあり、CTOとチームリーダーから許しをいただきElmでの実装に至りました。 ある程度実装が終

どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ - co3k.org JWT認証、便利やん？ - ブログ JWT 認証のメリットとセキュリティトレードオフの私感 - ..たれろぐ.. JWTをセッションに使うことに関して最近少し議論があったので、自分のお気持ちを表明したいと思います。 私は以前SPAを書く時にJWTをセッション管理に使おうとしたことがありましたが、仔細に検討していくとJWTをセッション管理に使うのは無意味にセキュリティ上のリスクを増やすだけで、伝統的なクッキーを使ったセッション管理を使った方が良いという結論に至りました。 前提を整理するためにあらかじめ前置きすると、「JWTをセッション管理に使う」というのは認証APIなどで返ってきたJWTをlocalstorageなどJavaScriptからアクセスできるストレージに保管しておいて、ajaxでサーバ

どうして JWT をセッションに使っちゃうわけ？ - co3k.org　に対して思うことを書く。 (ステートレスな) JWT をセッションに使うことは、セッション ID を用いる伝統的なセッション機構に比べて、あらゆるセキュリティ上のリスクを負うことになります。 と大口叩いておいて、それに続く理由がほとんどお粗末な運用によるものなのはどうなのか。最後に、 でもそこまでしてステートレスに JWT を使わなくてはいけないか？ とまで行っていますが、JWT認証のメリットはその実装のシンプルさとステートレスなことにあります。現実的には実際はDB参照とか必要になったりするんですが、ほとんど改ざん検証だけで済むのは魅力的です。トレードオフでリアルタイムでユーザー無効化ができないことくらいですかね。ライブラリなんて使う必要ないほどシンプルだし、トレードオフさえ許容できればむしろ、なぜこれ以上に複雑な認証

2020/5/9追記: 考えた結果、Authorization Bearer ヘッダを使った正規のJWTの場合、同一ドメイン下で読み込む全 JavaScript が信用できる場合でないとブラウザ上で安全にトークンを保持できないのでブラウザからのAPIアクセス時の認証用には使うべきではないというところに着陸しました。ブラウザからのアクセスでは http only cookie にトークンを入れ、 CSRF 対策も忘れずにというこれまで通りの定石が手堅いように思います。 JWTを使うのはトークンの安全な保管ができる非ブラウザなネイティブクライアントからのAPIアクセス時に限った方がよさそうです。 APIサーバ側ではアクセス元に合わせて認証方法を使い分ける両対応が要求されるので手間は増えますが手抜きできる場所でもないので仕方なしと。 React(SPA)での認証についてまとめ - エンジニアの本

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

MCHバトルベータでは、大部分の実装をLoom Networkを採用したサイドチェーンで実現しています。 現状のEthereumにおいて、Gasやトランザクションの確定速度の面からゲームのようなアプリケーションには、サイドチェーンもしくはオフチェーン技術が必須といえます。 Ethereumの秘密鍵情報はWalletブラウザが握っており、アプリケーション側から触るべきではないこと。Loom NetworkとEthereumの暗号方式が違うことからEIP 191 Signed Dataを使ったログイン機能を実装しました。 Go言語で作成したスマートコントラクトプラグインで実現しています。以降、KeyManagerと呼びます。 Metamaskによる署名リクエスト署名リクエストにより、「メッセージ」部分を署名し、シグニチャを作成します。 Tokenはワンタイムトークンです。MCH ベータバトルで

概要 先日リリースされた1.11でソケットオプションを設定できるようになりました。 これによってLinux 3.9から導入されたSO_REUSEPORTという、同じポートでbindすることが可能になる機能が利用可能になります。 環境 golang 1.11 macOS 10.13.6 (Darwin Kernel Version 17.7.0) Ubuntu 16.04 (4.4.0-87-generic) 何が嬉しい？ 一言で言うとGraceful Restartが可能になるという点です。 通常サーバプロセスを再起動するとその瞬間はリクエストを捌けなくなります。 Rolling updateのような事ができる環境であればいいですが、そうではない場合 a) Listenしているsocketのfile descriptorの複製 b) SO_REUSEPORTを使う といった手段でデプロイ時

WikiLeaksがこれまでベールに包まれていたAmazonが運用するデータセンター(クラウド向けサーバー)の正確な所在地を暴露しました。世界9カ国15都市に分散されたAmazonデータセンターは東京、大阪にも設置されているようです。 WikiLeaks - Amazon Atlas https://wikileaks.org/amazon-atlas/ WikiLeaksはAmazonの「機密性の高い内部文書」を入手することに成功。これは、世界9カ国15都市にまたがって設置された100以上のデータセンターの所在地と運用に関する文書だとのこと。なお、この文書についても上記ページで公開されています。 AWSによって世界最大のクラウドプロバイダーとして君臨するAmazonは、世界のクラウドインフラストラクチャサービス市場の34％を占めているという調査が出されていますが、その所在地や運用内容につ

私たちのプロジェクトではいつも、非常に長い Makefile を使用して、インストールやビルド、テスト、デプロイメントの処理を自動化しています。ターゲット名はほとんど標準化されていますが（ make install 、 make deploy ）、中には説明が必要なものもあります（ make run-dev 、 make restart-api ）。そして、詳細なmakeターゲットを追加するほど、それらの処理内容をテキスト形式で大量に記載しなければなりません。私たちのプロジェクトでは通常、このような文書を README ファイルに書いています。 しかしCLI（コマンドラインインタフェース）を用いる場合は、主に自己文書化ツールを使っています。 make と打つだけで、利用可能なコマンドとその説明が一覧表示されたら便利だと思いませんか？ それを実現するのは、実はとても簡単です。まずは各ターゲッ

Webアプリケーションエンジニアの id:tanishiking24 です。 今年で11年目となるはてなサマーインターンを2018/08/13 〜 2018/09/07という日程で開催しました。 developer.hatenastaff.com はてなサマーインターンの期間は前半と後半に分かれています。前半課程でははてなのサービス開発・運用に必要な技術を習得するための講義パート、後半課程では実際にサービスやシステム開発チームに参加していただいています。 はてなサマーインターンの講義パートで使用している「はてな教科書」はGitHubで公開しておりますが、今年のインターンで利用した講義資料を新たに公開しました。 今年のサマーインターンではカリキュラムを一新し、前半課程で利用するプログラミング言語にはGo言語を採用し、また進化するWeb技術に対応するためにデータベース基礎、インフラ、Webの基

某社で自分が React/Redux + TypeScript などの講習をやってみた結果、TypeScript 入門用資料が必要だと思って書いたやつです。 このドキュメントのターゲット TypeScript で書かれたプロジェクトに参加する人 TypeScript を導入するために、その事前知識が必要な人 このドキュメントの読み方 ES2015 for Beginners ES2015 for ES5 Programmers ES Modules 非同期表現: Promise と async/await TypeScript エコシステム編 自分が React/Redux などの講習でいろいろやってみた結果、 ES2015 と TypeScript を同時に教えると、初学者は何がどの概念に由来するかの区別が出来ずに混乱します。なので、ES5 -> ES2015, ES2015 -> Ty

オリジナルのThe Go gopher（Gopherくん）は、Renée Frenchによってデザインされました。こんにちは。エウレカ APIチームの小島です。 先日エウレカではサマーインターンを開催しました 。今回の課題は「マッチングサービスに必要なAPIをGolangで実装する」という内容でした。 ※ 詳細については高橋の記事[エウレカサマーインターンを開催しました！ エウレカサマーインターンを開催しました！(サーバーサイド編) にあるので割愛します。 課題は当日発表だったこともあり、その日からGolangを始めた学生も少なくありませんでしたが、苦戦しつつも皆さん課題に一生懸命取り組んでいました。 本記事では、初心者が知っておきたいGolangの扱い方など今回のサマーインターンの課題の内容をふまえつついくつか紹介します。 基本的な書き方1. Golangでは基本的にキャメルケースを使う

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.

マーチン・ファウラー氏の新著「リファクタリング 2nd Edition」が完成、ほぼ全面的な刷新。日本でも11月22日発売 マーチン・ファウラー氏が約2年を費やして執筆してきた新著「リファクタリング 2nd Edition」が完成し、日本のAmazon.comなどで予約が始まりました。発売日は11月22日と表示されています（下記の表紙画像からもAmazon.comへリンクしています。記事執筆時点でのAmazon.comでの販売価格は7279円）。 「リファクタリング」とは、ソフトウェアの機能追加や変更、性能向上などに備えるため、開発されたコードの外部に対する振る舞いは変えずに、より整理された、あるいは洗練されたコードに書き換えること、あるいはその手法のことを指します。 いまでは開発者の間で広く知られているこのリファクタリングの意義や方法論をはじめて系統的に解説し、普及に大きな貢献を果たした

Motivation 「Web について話す場」 というか「Web そのものをテーマにした場」というのが、意外と少ないなとずっと思っていました。 (もちろん、結果として Web について話しているカンファレンスや勉強会はたくさんありますが。) そして、スライドなどを用いて何かを「発表する」ニュアンスではなく、進化の早い Web で「今何が起こっているか?」と「これからどうなっていくのか?」という、答えの無いもの、でもみんなが気になり考えていること、今だからこそ考えないといけないことを真っ向から議論する場というのが、もっとあっても良いのではないかと考えていました。 今回開催するカンファレンスは、この「議論」だけからなるものです、それ以外のことはしません。 この趣旨に賛同してくださった、各分野のプロフェッショナルに協力頂き、「次世代 Web カンファレンス」として、開催させていただくことになり