OpenPNE 3

http://sns.openpne.jp/communityTopic/6460 でも、似た報告が上がっています。

【　環境　】
バージョン 3.4.7
ドメイン(仮) mydomain.jp
OpenPNEのURL http://mydomain.jp/openpne/

【　症状　】
新規登録の時、get@mydomain.jpに空メールを送り、
サイトからの返信メールの中のURLは下記通り、
ドメインの後の「openpne/」が抜けていますが（PC携帯同様）、
http://mydomain.jp/opAuthMailAddress/register/token/90d07...

初期アカウントより発行された招待URLは
ちゃんと「openpne/」が入っています。
http://mydomain.jp/openpne/opAuthMailAddress/register/tok...

どこを弄れば、ドメインの後にちゃんと「openpne/」が着くようになるでしょうか？

宜しくお願いします。

すぐに再現の確認ができなかったのでいったん手放します。優先度は変わりませんので再現でき次第修正に取りかかってください。

着手します。再現性を検証します。（再現できそうになければ情報をまとめた上で、担当者を手放すかもしれません）

スクリプト名（例えば pc_frontend_dev.php) が含まれている場合にはディレクトリ名のみを取得してくる必要があり、その目的で dirname() が用いられているものと思われるが、スクリプト名が存在しない場合には dirname() は期待されている動作をしない。この点を考慮した修正が必要と思われます。

91ed78f7 で修正を行いました。

具体的には、base_url が "http://example.com" と定義されている場合（あるいは未定義時）にopApplicationConfiguration::getAppRouting() において、options['context']['prefix'] （pathInfoPrefix）からディレクトリ名だけ抽出したものにスクリプト名を追加していた処理を削除し、pathInfoPrefix をそのまま利用するように変更しています。

この変更により、

• SNS設置場所がサブディレクトリで、
• かつ base_url が "http://example.com" あるいは未定義

の場合に、

1. 絶対URLの補完が（設置場所がサブディレクトリを含む場合も含まない場合も）正しく行われる
2. スクリプト名（eg. pc_frontend_dev.php）付きでアクセスした場合にも同様に正しく（スクリプト名をそのまま含んだ形で）補完される

ことを確認済です。

以上の修正についてレビューをお願い致します。

$this->getAppScriptName() を削除したことによって、スクリプトファイルと環境の設定が付加されない状態となっています。
指定したアプリケーションの no_script_name が false であった場合スクリプトファイルがURLに付加し、
dev モードでアクセスした場合には "/mobile_frontend_dev.php" のように生成されるべきです。

例¶

招待メールのテンプレート中に以下のような mobile_frontend へのURL生成を追加し、
pc_frontend_dev.php 経由から招待メールを送信した場合

{% app_url_for('mobile_frontend', 'member/register?token='~token, true) %}

修正前の挙動¶

/mobile_frontend_dev.php/member/register/token/***

修正後の挙動¶

mobile_frontend を指定したはずが、dirname() を削除したことによって pc_frontend_dev.php が除去されずに残ってしまう。

/pc_frontend_dev.php/member/register/token/***

このチケットを整理します。

このチケットが作成された当初の問題内容¶

• OpenPNE3をインストールし、設定ファイル等を正しく設定している
• 送られてくる招待メールが正しいURLではなく、招待メールから新規登録ができない

具体的な利用者からの報告内容¶

• 報告(1)
  

  http://sns.openpne.jp/communityTopic/6423 より転記
  
  招待メールに記載されたURLにアクセスできません。
  
  ＜動作環境＞
  OpenPNE3.6beta5
  CentOS5(OpenVZの仮想環境）
  PHP 5.2.11
  mysql Ver 14.14
  
  招待状に記載されていたURL
  http://ドメイン名/member/register/token/3228758dcc32ffb79b61ee61deb73c1b1
  
  実際に利用できた（手で書き換えた）URL
  http://ドメイン名/sns/web/member/registerInput/token/3228758dcc32ffb79b61ee61deb73c1b1
  
  登録完了メールには以下の正しいURLが記載されていました。
  （このURLでOpenPNEにアクセス可能）
  http://ドメイン名/sns/web/
  

• 報告(2)
  

  http://sns.openpne.jp/communityTopic/6460 でも、似た報告が上がっています。
  
  【　環境　】
  バージョン 3.4.7
  ドメイン(仮) mydomain.jp
  OpenPNEのURL http://mydomain.jp/openpne/
  
  【　症状　】
  新規登録の時、get@mydomain.jpに空メールを送り、
  サイトからの返信メールの中のURLは下記通り、
  ドメインの後の「openpne/」が抜けていますが（PC携帯同様）、
  http://mydomain.jp/opAuthMailAddress/register/token/90d07...
  
  初期アカウントより発行された招待URLは
  ちゃんと「openpne/」が入っています。
  http://mydomain.jp/openpne/opAuthMailAddress/register/tok...
  
  どこを弄れば、ドメインの後にちゃんと「openpne/」が着くようになるでしょうか？
  
  宜しくお願いします。
  

• また、公式SNSなどで公に報告されていないかもしれませんが、私(takai)は上記2件以外にも「招待メールに、いわゆるサブディレクトリ部分が抜け落ちている」といった旨の不具合報告を受けたことがあります（つまり、この問題を訴える利用者はそれなりにいるものと思われる）。

この問題（チケット）に適用されるべき対応優先度¶

もしこの問題が、特定のバージョンのOpenPNEおよびプラグインの組み合わせで『OpenPNE3をインストールし、設定ファイル等を正しく設定している』にもかかわらず発生する（あるいは発生する恐れがあると判断される）のであれば、 http://www.openpne.jp/archives/5361/ （「OpenPNE3.6 のチケット優先度と今後のリリーススケジュールについて」）に基づいて、この問題のレベル的には Urgent 以上の優先度として対応することが妥当だと思われます。

しかしながら、本チケットの note-6, note-8, note-9 を含めた、これまでの検証結果を鑑みると、利用者が報告しているような問題は【再現しない】と判断してよいと考えます。

断言はできませんが、少なくともこれまでの検証結果から考えると、この問題は、

• 「OpenPNE3をインストールし、設定ファイル等を正しく設定して『いない』場合」に、招待メールに記載されたURLにアクセスできない（URLが想定通りに生成されない）

という問題であると結論付けられると思われます。

もしもこの問題が「設定ファイル等を正しく設定している場合」にも生じる問題であったとしても、これまでの情報だけでは検証が極めて困難であるため、更なる情報を収集する必要があります（つまり、この修正後に同様の報告があれば、その時点で新たなチケットを作成して調査すべきだと考えます）。

以上の考察を以て、本チケットの優先度を Urgent から引き下げます。

ではどの優先度に下げるべきか（特に、OpenPNE-3.6.0 リリースに含まれるべきか）という判断についてですが、利用者（SNS管理者）の設定ミスとは言え、この問題に出くわす頻度は（どのような時にこの問題が再現できるかという検証結果から）それなりにあり、設定ミスがある場合にこの問題が生じてしまうことを防止する対応には意味があると判断しています。この再現条件と修正方針は本チケット note-9 以降で示されているものを指します。

（具体的な修正内容については note-13 で差し戻しがあり、まだ修正が完了していないが）修正方針は見えており、その対応による意味は少なくないと判断しているため、OpenPNE-3.6.0 への取り込みを前提とすることを含めて優先度を High に設定します。

まとめ¶

本チケットの報告(1)および報告(2)は、「OpenPNE3をインストールし、設定ファイル等を正しく設定している」という前提であるとした上で、その報告内容の問題は【再現せず】と判断します。

その上で、「設定ファイルを正しく設定しないと、この問題が起こったように見える問題がある」ことへの対応を扱うチケットへ切り替えます。

「チケットで扱う問題の切り替え」に併せて、このチケットの優先度を Urgent から High に変更します。

更新履歴 45c07909a4e1ed5d737fd11392778f13154c6303 で適用されました。

メモ¶

具体的には、パスが '.php' で終わる場合にのみ dirname() を使うように修正しています。 91ed78f と合わせると

     else
     {
-      $path = dirname($options['context']['prefix']);
+      $path = $options['context']['prefix'];
+      if (preg_match('/\.php$/', $path))
+      {
+        $path = dirname($path);
+      }
       $options['context']['prefix'] = $this->getAppScriptName($application, sfConfig::get('sf_environment'), $path, $isNoScriptName);
     }

本来 base_url が設定されていない環境では、ブラウザからのリクエスト以外での実行中に正しい URL の生成ができなくなってしまうため、そのような機能が（プラグイン含めて）あれば不具合が発生している（というより仕様）と思われるため、base_url が設定されていない環境での動作をどこまで保証するかは判断が難しいところです。

例えば、 note-3 のような get@ メールによる招待状送信では base_url が設定されていない状態で受け付けると、メール内の登録URLも example.com となります。（ただ、メール投稿を受け付ける設定をするには OpenPNE.yml の mail_domain を設定する必要があるため、その直前にある base_url の設定忘れはあまりないケースだとは思います）

base_url の設定が確実になされるような対応、あるいは、base_url の設定がなくても全機能が正常に動作するような対応ができればベストだとは思いますが、これは Enhancement として将来の開発版で考えるべき事項だと思います。

このチケットで対応している部分は元々 base_url が設定されていなくても正常に動作させるためのコードであるので、不具合として対処すべきものと認識しています。

以下、このチケットでの修正内容についてのフィードバックです。

$options['context']['prefix'] の元となっている値は sfWebRequest::getPathInfoPrefix() で生成されるものですが、この中から呼ばれている getRelativeUrlRoot() に今回変更した内容と類似のコードがあります。

  public function getRelativeUrlRoot()
  {
    if (null === $this->relativeUrlRoot)
    {
      if (!isset($this->options['relative_url_root']))
      {
        $this->relativeUrlRoot = preg_replace('#/[^/]+\.php5?$#', '', $this->getScriptName());
      }
      else
      {
        $this->relativeUrlRoot = $this->options['relative_url_root'];
      }
    }

    return $this->relativeUrlRoot;
  }

この部分を参考にして、preg_match() を使うのであれば、代わりに preg_replace() を使ってしまった方がよいと思います。

-      $path = dirname($options['context']['prefix']);
+      $path = preg_replace('#/[^/]+\.php5?$#', '', $options['context']['prefix']);

OpenPNEとしては opApplicationConfiguration::getAppScriptName() を見る限り、拡張子が .php5 である環境には対応していないように見えるので 5? の部分は外しても構わないです。

更新履歴 5547e0fa0b154a6ea66c1a5d928cb865b1851824 で適用されました。

修正確認しました。問題ないです。

動作テスト¶

チケットの Description を追記しましたが、

• 修正前の動作
  • 【前提】：サブディレクトリ（パス）を持つようなURLでSNSにアクセスする環境で、case3, case4 の場合、
  • 【結果】：招待メールにおいて、SNS参加リンクのサブディレクトリ部分の末のディレクトリ名が抜け落ちる
• 修正後の動作
  • 【前提】：サブディレクトリ（パス）を持つようなURLでSNSにアクセスする環境で、case3, case4 の場合、
  • 【結果】：招待メールにおいて、SNS参加リンクが適切なURL（新規登録画面に遷移できるURL）となっている

この確認を行いました。

• http://mydomain.jp/openpne
• http://mydomain.jp/openpne/hoge
• http://mydomain.jp/openpne/hoge/fuga

このようなURLでSNSにアクセスできる場合（サブディレクトリが1階層〜3階層の場合）をテストし、修正前、修正後とも上記の通りになることを確認しました。

この修正による副作用については、現時点で懸念点が明らかでないため確認すべき動作を示せませんが、

• サブディレクトリをURLに含まない環境
• サブディレクトリをURLに含む環境
• 設定ファイルが正常な場合(case1)
• 設定ファイルを記述していない場合(case3, case4)

このそれぞれにおいて、URLの生成は正常に行われていることは確認しています。ここまでの考察結果を以て、副作用なく問題点を修正できているものとし、チケットを完了とします。