ver2.4.3をネットショップをだすために見ています。

管理画面などもSSLでうごかしたかったのでHTTPドメインにもSSLのドメインを指定したのですが、動きませんでした。
管理ページの複数各所で、ハイパーリンクでの画面呼び出しの指定が$smarty.server.PHP_SELFとなっているので、SSLや、違う階層からアクセスすると、リンクアドレスがずれ上記のようなリンク方法で書かれている部分は動かなくなります。

相対パスでやるなら./でつないでほしいかなと思います。
もしくは$smarty.const.URL_DIRをつかって絶対パスにする必要があるのではないでしょうか。


サーバー変数から取得できるそのファイルが動いているディレクトリ階層とドメインの階層は必ずしも一致するものではないと思います。
管理情報のようなシビアな情報をいじるのにサーバー変数からの相対パスとかが混じっててだいじょうぶかなと少し不安になりました。

仕様というには統一されていないので、不具合として報告させていただきます。

引用：
というのは至極もっともな話だと思いますが、具体的にどのような設定をしたのかなどを書かれたほうがよいのではないでしょうか？

「どんな設定でもそれなりに動く」ようにした場合に、セキュリティ的にはどうなのかもみなければいけないでしょうし...

初めてご利用になる方へ
http://xoops.ec-cube.net/modules/tinyd0/index.php?id=8

> サーバー変数から取得できるそのファイルが動いているディレクトリ階層とドメインの階層は必ずしも一致するものではないと思います。

どのような利用を想定されているか、気になります。

私は、HTTPS を好まないので、通常は HTTP で管理作業をしていますが、私どものお客様の中には HTTPS で EC-CUBE の管理作業をしているケースもあります。しかし、問題があるという話しは、あまり聞かないです。(正式版のページ編集で、若干不自然な挙動は耳にしていますが。)

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

------------------------------------------------------------------------------------------
[EC-CUBE] 2.4.3正式版
[レンタルサーバ] xrea.com
[OS]
[PHP] PHP 5.2.5
[データベース] MySQL 5.1.11
[WEBサーバ] apache1.3.37
[ブラウザ]
[現象] SSLでアクセスすると動かない
------------------------------------------------------------------------------------------
いちおう書いておきます。
あちこちのサーバーに入れて検証していますが、まだ検討をはじめたばかりなので理解不足のところがあるかもしれません。
掲題の問題にはxreaに入れたときに遭遇したのですが、xreaでは共用SSLで、実際の階層とサーバ変数でとれる階層が異なります。
一番最初の設定でSSLとHTTPで階層が違う設定ができないとのことだったので(これもこれで困りますが)、SSLをつかわないぐらいなら全部SSLのほうがいいとおもって最初のインストールでHTTPとSSLを同じSSLのほうのURLを指定しました。


xreaでは、SSLは次のようなドメインで与えられます。
https://ss1.xrea.com/www.example.com/ec-cube/html/

この状態で管理画面にアクセスすると、一部挙動がおかしいものが混じっていました。
内容をみてみると「$smarty.server.PHP_SELF」にてリンクを設定しているものでした。挙動がおかしいのではなくリンクがおかしいことになっていました。
この場合は、$smarty.server.PHP_SELFはこの場合/ec-cube以下のパスを返してきます。
たとえば、このようなパスは
https://ss1.xrea.com/www.example.com/ec-cube/html/admin/products/category.php
このように返されます。
/ec-cube/html/admin/products/category.php
結果として↓にアクセスすることになります。
https://ss1.xrea.com/ec-cube/html/admin/products/category.php
当然そのようなパスのファイルはないのでエラーとなります。


上記はあくまで例です。
ベースファイル名をつかって./でつなげてくれるか、$smarty.const.URL_DIRで書いてくれればまだ動いたのですが、これだと動きません。xreaのような共用SSLは階層がずれてくるので若干特殊ですが、同様の問題はWEBサーバー側の設定ではなく、DNSやhostsでリダイレクトしてるときなどでも発生すると思います。


サーバー変数で取得できるパスと動作ドメインのパスは必ずしも一致するものではないのではないか、ということをいいたかったのですが分かりにくかったようなので例を交えました。
階層がずれることには対応していないということなのかもしれませんが、何かポリシーがあってそのように統一されているのなら対応もしやすいのですが、混在していたので、そもそもあまり想定されていないのかなと思った次第です。
できるならどちらかに統一したほうがいいのではないかと思いました。
（もしかしたらGETのescape処理を導入されたタイミングで各所に導入されたのかな…）


セキュリティ的にどうかと思ったというのは、漠然とした感想です。ここまでいじった印象にすぎません。
実際にクラックを試みたわけでもありません。既に他に根源的な対策がされているのかもしれませんが、たとえば/admin/のパスを変更したいと言った場合にも、このように実装方法がばらばらだと、ディレクトリパスを動かすだけでもしんどそうです。

/admin/を別の名前にするだけで、管理ユーザーへのフィッシングやCSRFに対して、OSSでディレクトリ構成やデータ構成がばれているOSSではある程度効果があるんじゃないかと思います。
特に、パスワードに英数字しかつかえなかったので、なにか手当をしておかなきゃダメかなと思ったのですが、管理ディレクトリのパスを動かすのも手数が多くなりそうだったので残念だなと思いました。


SSLを使わないという選択肢ですが、環境によってはありだとは思いますが…
無線LANとかが混じるような環境だったり、乗り入れだと、パケットモニタされたり、MACをごにょごにょされたりしたらダダ漏れる危険性もあるので、毎回でなくともSSLを使える状態ぐらいにはしておきたいなとおもう次第です。
うちは喫茶業務もやっているので…、出店ショップの立場からすると、お店を利用されたお客様の情報をHTTPでいじるのは抵抗があります。
万が一のときの被害は最小限におさえられるようにしたいです。


＞(正式版のページ編集で、若干不自然な挙動は耳にしていますが。)
ちなみにxreaだと、デザイン編集のページ詳細設定、編集可能ページの個別画面へのアクセスも同じ理由から動きません。上記で指摘したようなリンクの貼られ方がなされています。
問題だなあと思うのは、これが混在していることです。
デザインのメイン編集は動くけど、個別画面へのアクセスは動かないとか、そういう事態になっています。
環境にあわせて手をいれれば動きそうですが、そもそも、なんでこうことになっているのか疑問におもったので書きこみました。

スイマセン、長文で十分に読めていませんので、ポイントを伺わせてください。

フロント機能で HTTPS の利用予定はありますか? 利用する場合、URL をお知らせください。(HTTPは http://www.example.com/ec-cube/ の想定で)

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

まず、私が知っている範囲でですが、

【告知】EC-CUBE 2.1.1β版をリリース致しました。
http://xoops.ec-cube.net/modules/newbb/viewtopic.php?viewmode=flat&topic_id=1861&forum=4

という告知がありました。
そのときの修正が

チェンジセット 17118 共有SSL対応
http://svn.ec-cube.net/open_trac/changeset/17118

で、正式版となった2.1.2あたりから皆さんチャレンジするわけですけど

EC-CUBE 2.1.2正式版 共有SSLについて
http://xoops.ec-cube.net/modules/newbb/viewtopic.php?viewmode=flat&topic_id=2044&forum=2

とどのつまりこういうことでした。

Re: 【告知】EC-CUBE2.3.0をリリースいたしました。
http://xoops.ec-cube.net/modules/newbb/viewtopic.php?viewmode=thread&topic_id=2803&forum=4&post_id=10685#forumpost10685

EC-CUBE Tracトップページの中ほどにある、講演資料 OSC-KANSAI2009（2009/7/11 パワーポイントのファイル）をみると、共有SSLに対応させる方向で考えているようです。

EC-CUBE Trac
http://svn.ec-cube.net/open_trac


ちなみに私のテストサイトでバージョンはちと古いですが、一応共有SSLに（それなりに）対応させております（汗）。
-----

いろいろな経緯があったんですね。
なんでこうなっているのかわからなかったのでバグとしてあげてしまいました。ドラフトレベルのコードが混じりながら対応中ということであれば納得です。
管理ユーザー権限機能とかあと一歩なのに、なんで機能のせてないんだろうとかコード見てておもったのですが、実装予定のコードも紛れているのか・・・な。


フロントのSSL運用ですが、SSLはお客さまが個人情報を入力されるページにはあったほうがよいと思うのですが、そうされてないお店も増えてきてるんでしょうか？
まだ検証段階なので、なにをどのように運用するかとか決めてません。自分のお店のショップなので、のんびりやってます。
ただ何かあったときに被害を最小限におさめたいんで、管理関係まわりだけあれこれみてる感じです。

引用：
利用するほうにしてみればSSLで暗号化されていることが重要なんですが、実際のところは証明書で身元を保証することが重要視されていて、証明書がオレオレだと最近のブラウザでは蹴られてしまいますよね？

共有SSLではPCのブラウザで問題になりませんが、携帯に対応した証明書ではなかったりします。

そんなこんなで結局のところ、それなりのサーバーと独自ドメイン、専用SSLが必要になってくるのだと思います。
費用次第...　かなと。