登録日
2012年7月4日

メンバー検索

  

aniya

名前(ニックネーム)
aniya
自分のconcrete5サイト
ホームページ
自己紹介
concrete5.org のユーザー名
concrete5 Slack Team ID
Twitterアカウント
フォーラム総投稿数
62

コミュニティバッジ

投稿

31から40までを表示 (計61)

Re: Re: 常時SSL化について

tokami様
5.7.5.8でも不具合が出るとの情報ありがとうございます。

ページ全体のSSL対応は 「URLとリダイレクト」のところの

これはカノニカルURLの設定となりますので、ちょっと違います。
具体的には「https://www.raytron.co.jp」「https://raytron.co.jp」の両方でアクセス可能な場合に、どちらのURLを用いて表示するか?を設定する項目となります。

http で入力された場合でも 自動的にhttpsにするにはどこをさわればよいのでしょうか?

concrete5にその設定は無く、Katz Ueno様が上の方で紹介している「SSL Redirect Configuration」というアドオンを使うか、tokami様が記述しているようにサイト側の.htaccessで設定します。

ただ…それで不具合が出ているのでこのトピックが未解決となっております。

.htaccessのコメントアウトを外してエラーになる件は、さくら側でポート番号80を返しているのが原因です。

会話形式で説明するとこんな感じです。
1)さくら「httpをhttpsに転送します。https通信ですがポート番号は80です」
2)con5「httpsでの接続要求がありましたが、ポート番号が443でないとhttpsとは認められないので、httpとして処理します」
3)さくら「httpをhttpsに転送します…(以下同様)」
といった感じでループが発生しエラーとなります。

一般的なhtml/cssページを処理するだけの場合はhttpsでも接続可能ですが、
フォームブロックやログイン、レイアウト機能、リンクのライトボックス風表示など、動的に内部処理が行われるページの場合は、上記ループが発生してエラーとなるようです。

.htaccess該当部分をコメントアウトしても、フォーム入力時にhttpに戻って暗号化されないページに移動する現象も上記ループと同じ原因です。con5側がhttps通信と認めていないのでhttpに飛ばされます。

この症状はさくらだけの症状で、他のサーバでは起こらない現象なのでしょうか?

https通信時、ポート番号が443になる一般的なサーバーの場合はこの現象は起こりません。
※さくらのhttpsはプロクシとして80番ポートで動作しています。
http://help.sakura.ad.jp/app/answers/detail/a_id/2325/~/ssl%E5%88%A9%E7%94%A8%E6%99%82%E3%81%AE%E6%B3%A8%E6%84%8F%E7%82%B9

またレガシー(5.6)では.htaccessの設定だけでhttps専用にすることができ、バグも発生しません。

フォームブロックのページのみSSL対応でもよいので解決策があれば

私の場合、フォームブロックを使わずcon5外部にメール送信専用phpを設置して対応しました(前述の通り、内部処理を行わないhtml/cssページならばバグが発生しないので)。

参考になれば幸いです。

Posted on 6月 10, 2016 at 4:43 午後

Re: 常時SSL化について

nipper様

ホームへのリンクに関しては、スラッシュが付いていればmod_dirが発動せず、問題解決となると思います。

ただ、一番の問題は「https時のポートは443固定」という前提でコアの部分が処理されており、それが原因で諸々の不具合が出ている事だと思います。

Posted on 6月 10, 2016 at 4:05 午後

Re: 常時SSL化について

さくらの常時SSL化ですが…未だ解決にいたっておりません(T-T)
さらに新たな問題発覚!といった状態です。

→新たな問題その1
 レイアウト機能(ブロックの横並び)を使ったページをhttpsで表示するとレイアウトが崩れる

→新たな問題その2
 リンクをライトボックス風に表示させる設定にした場合、httpsで表示するとリンク先が表示されない。

両方ともhttpだと普通に表示されるので、内部読み込みのcssがhttpで呼ばれているせいでは?と予想しています。

これってソースの各所にある
if (('https' === $this->scheme && $this->port === 443)
のような記述を443から80に書き換えれば解決するのでしょうか?
※もっと簡単な解決方法があれば是非教えてください。

よろしくお願いします。

追伸
shideto様
一緒に頑張りましょ〜〜

Posted on 5月 31, 2016 at 4:29 午後

Re: 常時SSL化について

Katz Ueno様
ありがとうございます。
試してみたところ、動作に変化はありませんでした…。

さくらのSNI SSLの挙動について整理してみました。
・PHP 5.6.18 (cgi-fcgi)
・concrete5 - 5.7.5.6
・キャッシュ全て無効
・プリティーURL有効

a)https://mydomain で閲覧
 基本的に大丈夫。ただし、ページ内のリンクが
 https://mydomain/contents/
 のように最後にスラッシュがついていると
 http://mydomain/contents ←SSL/TLSなし
 に飛ばされます。

b)https://www.mydomain で閲覧
 こちらもwww無しと同様に基本的に大丈夫。
 ただ、上記同様、最後にスラッシュがついていると
 https://www.mydomain/contents/
 から
 http://mydomain/contents ←SSL/TLSなし、wwwなし
 に飛ばされます。

c)https://mydomain でログイン
 ID/PW入力後、ログイン状態でhttp://mydomain(SSL/TLSなし)に飛ばされます。
 改めてURLにhttps://を入力してもログイン状態は保てたままですが、
 TOPページ「https://mydomain/」以外では、ツールバーの管理画面ボタンが「http://mydomain/(SSL/TLSなし)」をリンクしており、ツールバー右の管理用ドロップダウンメニューが表示されない状態です。
 また、TOPページにて管理用ドロップダウンメニューを表示させた際も、サイトマップ等メニュー項目のリンクが全てSSL/TLSなしを指しているので、項目を選ぶとSSL/TLSが外れます。

d)https://www.mydomain でログイン
 ログイン画面、フォームのpost先が「https://mydomain(wwwなし)」となっており、ID/PW入力後は上記c)同様、ログイン状態でhttp://mydomain(SSL/TLSなし wwwもなし)に飛ばされます。
 改めてURLにhttps://www.を追加した場合は当然ながら非ログイン状態となります。
 そのままwww.無しの状態での作業は上記c)と同様です。

こんな感じになりました。

※上記のスラッシュ問題、concrete5をルートにインストールした場合はペー
ジ内のリンクを修正することで解決できるのですが、
http://www.mydomain/concrete5/
のように下位フォルダにインストールした場合は、また厄介なことに…。

Virtualboxで「模擬さくらサーバー」を立て、フルサイト(=Elemental)
をインストールしてテストしてみました。
ホームへのリンクが
http://www.mydomain/concrete5b/index.php?cID=1
となっているとき(つまりデフォルト)、書き出される a hrefは
http://www.mydomain/concrete5 ←最後のスラッシュ無し
を指しています。
結果としてmod_dirが発動し、wwwなしのhttpページ(http://mydomain/concrete5/)へジャンプします。
(ルートにインストールした場合は、最後スラッシュ無しでも正常に動作します)

ポート問題に加え、プリティーURLの「最後のスラッシュは全部取っちゃうぞ」行動が原因の一つを担っているような気がしました。

申し訳ありませんが引き続きよろしくお願いいたします。

Posted on 4月 23, 2016 at 8:23 午前

Re: 常時SSL化について

うちも「さくらスタンダード」で難儀しております。
5.6のときは.htaccessでhttpsにリダイレクトするだけで良かったのですが、
5.7になってから、リダイレクトループが発生したり、ログイン後httpsで表示しているのにhttpへのリンクがあったり…
(現在、発生状況を整理中ですが、既に公開しているサイトなので夜中にしか作業が出来ず整理も難航しております)

とりあえず、5.6は絶対パスでリンクしていて、5.7はURLでリンクしているせいかも?と検討をつけておりますが、どこを治せばよいのやら…

1カ所、気になるところがありましたので報告します。
さくらのSNI SSLを使ってる場合、
_SERVER["HTTPS"] = on
_SERVER["SERVER_PORT"] = 80
という状態になります。
※httpsはプロクシとして動作、だそうです。
http://help.sakura.ad.jp/app/answers/detail/a_id/2325
※添付はphpinfoの該当部分です。

これが/concrete/vendor/zendframework/zend-feed/src/PubSubHubbub/AbstractCallback.phpの241行目〜に抵触して不本意な動作を生むのかなぁ…とか思ったりします。

なにかの参考になれば幸いです。

添付: sakura.png
Posted on 4月 19, 2016 at 3:56 午後

Re: WebARENA SuiteX V2で5.7系は動きますか?

最終的に、何とかクライアントを説き伏せ、別のレンサバで行く事になりました。
akiさん、諸々のアドバイスありがとうございました。

Posted on 2月 22, 2016 at 2:24 午後

Re: WebARENA SuiteX V2で5.7系は動きますか?

ありがとうございます。
通常使用では問題ないとの事、参考になりました。
お手数をおかけいたしました。

Posted on 2月 18, 2016 at 1:40 午後

Re: WebARENA SuiteX V2で5.7系は動きますか?

aki様
アドバイスありがとうございます。
zipに関する諸注意、参考になりました。

mcryptに関しては特に何も問題なく…でしょうか?
もし何かご存知でしたら引き続きアドバイスいただけると助かります。
よろしくお願いいたします。

Posted on 2月 15, 2016 at 6:01 午後

WebARENA SuiteX V2で5.7系は動きますか?

表題のまんまなんですが、
WebARENA SuiteX V2で5.7系を使われている方はいらっしゃいますでしょうか?
サーバスペック的には
・zip
・mcrypt
が無い状態なので、
・それでも動くのか?
・上記二つがないとどういう不具合が発生するのか?
を知りたくてトピックを立てさせていただきました。

よろしくお願いいたします。

Posted on 2月 13, 2016 at 5:05 午後

Re: コンポーザーの共同編集について【5.6.3.2】

ありがとうございます。
もう一度、環境を構築して再確認してみます。
お手数おかけしてすみません。

Posted on 1月 15, 2015 at 1:23 午後