問題タブ [psgi]

webapp には starman を使用しています。'/request'Apache Web サーバーはポート 8080 でリッスンします。starman でこの Apache Web サーバーへのような要求を書き直したいと思います。午後を見つけようとしましたが、役立つ例はほとんど見つかりませんでした。

シンプルな構成ファイルと標準インターフェイスを介して、異なるポートでリッスンしている複数の Twiggy インスタンスを管理する方法を探しています。

たとえば、次のような構成が必要です

そして、 /etc/init.d のスクリプトは次のように使用されます

私の同僚の何人かはrunitを提案しており、有望そうに見えますが、私はまだ十分に慣れていません。

独自のスクリプトを書き始める前に、あえて SO に尋ねます: スクリプトは既に存在しますか?

フォームからアップロードを取得し、処理のために別のスクリプトに渡す小さな PSGI アプリがあります。

ファイルは のように正常にアップロードされます/tmp/Fw8n6j0ICn.txt。問題は、処理がアップロード時の名前のファイルに依存していることです。

ファイルのアップロード方法を変更して に移動することはできます/tmp/Fw8n6j0ICn/original_name.txtか?

MovableType 5.2 には組み込みの PSGI サポートがあり (メイン ディレクトリの mt.psgi を介して)、starman/plackup を使用してそれを利用しようとしています。

Starman w/ MT は起動しますが、mt-upgrade.cgi を実行すると、奇妙な Not Found が表示され、サイレント ハング & 失敗します。

スターマンの実行方法:

謎 1: 私のブラウザは index.html に対して "Not Found" を返しますが、mt-static と mt.cgi にはアクセスできます。

謎 2: リダイレクトにより、MT コードが実行されていると思います。しかし、さまざまな MT デバッグ オプションを試しても、starman ログにはほとんど何も表示されません。さらに悪いことに、mt-upgrade.cgi に到達したように見えますが、starman ログに次のメッセージが表示されて失敗します。

この非バッファリング メッセージは、情報を提供するものであり、通常のように見え、MT コードベースからのものです。

また、starman の直下で実行したところ、同じ結果が得られました。

アイデアや助けをいただければ幸いです。

システム/環境:

CPAN モジュール:

MT 構成:

同じマシン上で実行されるPSGIアプリの多くの（分離された）インストールがあるため、PSGIサーバーを一意のポートで実行する必要があります。これは、リソース/管理の観点からは理想的ではありませんが、同じマシンで実行する場合にUnixドメインソケットがより明白な選択であると思われる場合は、TCP / IPの（まだ測定されておらず、おそらく重要ではない）「オーバーヘッド」も必要です。 。

幸い、アプリはPlackのHTTPインターフェース（mod_proxyの「ProxyPass」を介してApacheからプロキシされます）で動作しますが、残念ながら、FastCGIインターフェースでは機能しません（https://stackoverflow.com/questions/14643165/can-psgi-apps-を参照）。 fork-under-plackhandlerfcgi）。

mod_fastcgiのFastCgiExternalServer以外（またはこのテストされていないユーザー提供のパッチでmod_proxyにパッチを適用する：http：//mail-archives.apache.org/mod_mbox/httpd-dev/201207.mbox/%3C20120731200351.GB11038@gmail.com%3E） 、 Unixドメインソケットを介してApache接続をPSGIアプリにプロキシする方法はありますか？

単純なPayPalIPNモジュールを機能させるためにしばらくの間試みてきましたが、LWP::UserAgentから400BadRequestエラーが発生し続けます。なぜこれが起こっているのかわかりません。PayPalは私に正常にpingを送信し（私はIPNシミュレーターを使用しています）、アプリのログでプロセスを確認できます。フォームコンテンツなしでLWP::UserAgentを介してPayPal検証URLを呼び出すことができますが、これは正常に機能しますが、検証のリクエストコンテンツを含めると、エラー400が発生します。これについて誰かが知っている場合はお知らせください。

-$self->{'_req'}のタイプはPlack::Requestです

シンプルな Web アプリケーションを構築する必要があります。Plack を使用するPoet ( Mason2 ) で行うことにしました。

アプリケーションは認証されたユーザーのみが使用できるようにする必要があるため、ログイン/パスワード機能を構築する必要があります。

チェックなどのセットアップを可能にする Basic ユーザー認証を使用できるPlack モジュールPlack::Middleware::Auth::Basic.htpasswdが既にあります。しかし、基本認証はあまり安全ではありません。誰でもパケットキャプチャなどでログインパスワードを取得できます。

考えられる解決策は次の 2 つです。

• HTTPS(443) 経由で app.psgi を実行 - リンクレベルの暗号化
• または、httpsなしで安全な認証を可能にするより良い認証方法はありますか?

質問：

• HTTPS について - HTTPS 経由で実行する方法がわかりませんapp.psgi。アプリケーションを多少変更する必要がありますか? plackuphttpsを介して実行する方法を示すリンクはありますか?
• または 2 つ目:標準の暗号化されていないポートを介して安全な認証を構築できる方法 (ミドルウェア/または perl モジュール) はあり ますか?(80)

では、Plack アプリケーションで安全な認証を実現する比較的簡単な方法は何でしょうか?

PS: 残りの通信は気にしません。パスワードの取得を許可しない安全な認証のみが必要です。

PPS: https は、apache (および自己署名) 証明書を使用すると簡単です。しかし、plackup（およびまたは他のPlackベースのサーバー）でそれを行う方法がわかりません

これは私のシナリオです:

そう、

1. 暗号化された HTTPS 経由のリクエストは、次のように Apache に送信されます。https://server1/MyPerlApp
2. ユーザーがログインしていない場合、ログイン ページ (server1 内) へのリダイレクトが行われ、Apache は要求を Server2 にプロキシしません。
3. ユーザーがログインすると - IS 認証されます - Apache はhttps://server1/MyPerlApp、http://server2:5000

質問1: これは可能ですか? (私は Apache について十分に詳しく知りません。これは簡単なことではありません。

ProxyPassserver1 でユーザーを認証し、認証された場合のみを設定する必要があるためです。Apacheは非常に柔軟なので、上記の答えはイエスだと思います（ただし、確認と詳細は大歓迎です）-主な具体的な質問は次のとおりです。

• Plack アプリケーションは、どのユーザーが Apache レベル (つまり、最初のサーバー) で認証されているかをどのように認識しますか?
• ユーザー情報の一部perlをサーバー上のアプリに配信する簡単な方法は何ですか? たとえば、各クエリにパラメーターをmod_rewrite追加するApache の場合、user=username
• Apache は、perlアプリが読み取るべき HTTP ヘッダーを設定できますか?
• 簡単で推奨される方法はありますか？

starman/perl アプリで認証ルーチンを回避する方法を探しています。

• とにかく、ユーザーは server1 にログインする必要があります (ワークフローの他のタスクのために)
• 彼がすでにログインしている場合、アプリでの認証は必要ありません (不必要な二重ログインを避ける)
• ただし、どのユーザーがログインしているかを知る必要があります(server1 の Apache 経由)

すでに同様の質問がありますが、次のとおりです。

• https://stackoverflow.com/q/12561830/734304 (回答なし)
• https://stackoverflow.com/q/11907797/734304 (回答なし)
• 基本認証を使用した Apache リバース プロキシ(同様ですが、バックエンドは同じサーバーと同じ apache にあります)

いくつかのミッション クリティカルなアプリのために社内で使用する FastCGI ベースの Web フレームワークがあります。したがって、既存の PSGI 準拠フレームワークへの移行はあまり現実的ではありません。フレームワークを単純な古い CGI.pm から Plack ハンドラに移行することに成功しました。

ただし、Apache の構成ファイル内には、mod_rewrite ルールの形式で、非常に多くのルーティング ロジックがあります。Apache のリバース プロキシ経由で Plack::Handler::FCGI を使用して、新しく PSGI に準拠したフレームワークを使用するアプリをデプロイする場合、mod_rewrite ルールはいくつかの微調整を加えて、そこで引き続き機能すると思います。（これを行う予定ですが、まだ試していません）。

しかし、mod_rewrite の代わりとしての Plack::Middleware::Rewrite について読んで興味をそそられました。

mod_rewrite ルールを Plack::Middleware::Rewrite ルールに変換し、すべてのアプリ ロジックを完全に Perl に移行して、PSGI の利点を最大限に活用する必要がありますか?

答えはイエスだと思いますが、私は PSGI アプリをデプロイした経験がないので、正しい道をたどっていることを確認するために経験を共有できる人がいれば幸いです。

サブ質問 PSGI のアイデアは、Web サーバーの処理をできるだけ少なく (そしてできるだけ速く) し、他のすべてのものをアプリケーション サーバー (ミドルウェア) に委譲することですか?**