インフラエンジニアが一切コードを書かずにWebサーバーに認証機能を実装した話 ｜ Developers.IO
コンニチハ、千葉です。 AWSのサービスを組み合わせれば、独自の認証基盤を構築できます。例えば、WordPressを限定的に公開する、Apache、 Nginx、カスタムWebアプリなどなど、簡単に認証をかけたい場合、ベーシック認証は昔から利用されてきました。ただし、これはスケーラビリティや運用面でどうしてもつらい場面がでてきます。 そこで、ALBに素敵すぎる組み込みの認証機能が追加されたのでこちらを利用し、コードを一切書かずに認証を導入します。また、OIDCなど認証プロトコルに対応していますが、今回はシンプルにCognitoのユーザープールを利用し、ユーザー管理自体もCognitoに任せます。 要件 今回の想定する要件です。 Nginxを社内ユーザーのみに公開 スタンドアローンのユーザープールを用意(AD、OICD、SAMLなどによる連携なしで、独自でユーザーを管理) ユーザーは管理者が
nginx の設定をレビューするときの観点をまとめてみた - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。 インフラチームの野島（@nojima）です。 チームのメンバーに nginx の設定について気をつけるべき点を共有するために、レビュー観点を書きました。 せっかくなのでここで公開します。 ほとんどの項目は自分やチームのメンバーの実体験に基いています。 レビュー観点 server server_name が他のやつと被っていないか。 listen する IP アドレスが同じ場合、server_name で区別できないといけない。 TLS を使う場合、SNI をサポートしないクライアントでは TLS 用の設定が default_server のものが使われる点にも注意。 TLS を使う場合、listen ディレクティブに ssl オプションを書いているか。 location location のマッチの順番に注意 正規表現の location は前方一致の location より
NginxでリバースプロキシをKeepAliveしたときの性能検証 - Qiita
Nginx + Luaを用いた、ハイパフォーマンスで動的なプロキシサーバを考察中です。 そのための施策の一つとして 上流サーバへのアクセスをKeepAliveする という方法がありますが その際、プロキシサーバにどの程度性能に変化があるのかを調査してみました。 リバースプロキシのkeepalive設定 前提条件として Nginx > 1.1.4 が必要。 upstreamに keepalive というattributeがあるのでそれを設定します。 それと同時に、プロキシヘッダーにHTTP/1.1設定などを行いましょう。 ちなみにproxy_passだけだとkeepaliveできないようです。upstream必須。 あと、もちろんバックエンドサーバ側もkeepalive設定しておきます。 upstream http_backend { server oreore.micro.service;
フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews
Randen Pederson 大規模なシステムであれば使っているであろうリバースプロキシ。 セキュリティや稼働率の観点からみて利用することは非常にメリットは高いです。 ただ、社内や周りであまり知見がなく、 「動くからいいや」という理由でApacheをそのままWebサービスの一次受けとして利用されている方も多いと思います。 動くという目的からすれば確かにその通りですが、ただ一枚リバースプロキシを入れるだけで ぐっと運用効率、稼働率も拡張性も上がります。 1. ルーティング処理の簡略化 例えばRESTfulな一般的なAPI構成を作りたいと思った時に以下のようなURL構成になると思います。 http://api.something.com/search/v1/item/list.json?cid=xxxx&gid=xxxxx もしアプリケーション側のルーティングしか知らなければframewor
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
