登録日
2011年2月4日

メンバー検索

  

shin2

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

コミュニティバッジ

インテグレートパートナー concrete5 でサイト制作を行うことができるインテグレートパートナーです。お仕事で concrete5 サイトを構築している個人・企業の方であれば申請できます。詳しくはインテグレートパートナー紹介ページ
エバンジェリスト 宣伝・普及活動を行っていただいている concrete5 の伝道師です!エバンジェリストについて

投稿

1から10までを表示 (計18)

Re: 【ワークフロー】ページの新規作成について

トピックをたてておきがながら、自己レス&自己解決です。

システムページの「下書き」の権限に「ワークフロー」を設定することで、即時公開は回避できました。

新規作成からの編集モード時は、一旦「下書き」に属して、「下書き」の権限が適応されるということですね。
「お知らせ」の新規作成で、「お知らせ」の権限が使われていない感じだったので迷ってました。
お騒がせしました。

ただ、「下書き」は共通の箇所なので、ワークフローを分けている場合に調整しづらいですね。。。

Posted on 11月 04, 2015 at 10:07 午前

【ワークフロー】ページの新規作成について

お世話になっております。

ワークフローの設定ついて、以下のトピックと類似しているかとも思いますが、
対処方法があればご教示願いたく。

▼ページをコピーした際にワークフローに送られず即時公開になってしまう?
http://concrete5-japan.org/community/forums/usage/post-10302/

-----------------
ver 5.7.5.1
-----------------
【確認したいこと】
ページを新規作成した時に、編集モード経由後にワークフローをのせて公開処理を行いたい

【権限設定】
・変更を承認: 承認者グループ / 編集者グループ
└>承認者グループが承認するワークフローを設定

  ※「変更を承認」に編集者グループが入っているのは、
   「ワークフローに送信」ボタンを表示するための必要な認識

・サブページを追加: 承認者グループ / 編集者グループ
└>ワークフローの設定は不可(メニュー無し)


【運用の流れ】
(1)ページ編集時は、「編集者グループ」に属するユーザーがページを編集。
 編集後は「ワークフローに送信」して、「承認者グループ」のユーザーが承認処理をして公開。

=> OK 問題なし

(2)【コンポーザーから即公開】
  ページ新規作成時は、「編集者グループ」がコンポーザーを使用してページ作成。
  コンポーザーで入力後「ページを公開」をクリック。
  ワークフローにのって「承認者グループ」のユーザーが承認処理をして公開。

=> OK 問題なし((ページを公開)というボタン名が悩ましい)


(3)【コンポーザーから編集モード経由で公開】
  (2)の流れから、「編集モード」で該当ページを開きコンテンツを編集。
  その後「ページを公開」をクリックすると、
  ワークフローにのってはいるものの、ページが既に公開されている。

=> NG 編集モードにいくと、ページが公開されている?


編集モードに行くと、サイトマップ上にまだページがないために「ワークフロー」の設定が当たっていない ような感じでした。


新規作成時に、「編集者が公開できる」のがよくないので、回避策があればお教えいただければ助かります。

Posted on 11月 04, 2015 at 10:02 午前

Re: Page List Plus

お疲れ様です。
自分もPage List Plusは利用させていただいておりますが、まだフィルターの部分が不安定な感じが否めないですね。

・Date属性の「is today or after」などの日付制御が効いていない
・「転載(エイリアス)ページを表示」が効いていない
など

場合によっては、パッケージ直に修正を施したりもしています。
5.6のPL+とは、動作面では同じレベルではなさそうですね。

Posted on 11月 04, 2015 at 9:25 午前

Re: ページコピーからブロックの移動について

ブロックの順番変更処理時に、Where句条件に cID と bID として、他に影響でないか様子を見てみます。

ページコピーしてからブロックの順番を変更せずにブロックの更新をかけると、新たにbIDが発行されるので問題ないですが、コピーしてからすぐに順番を変更すると、コピー元に影響しますね。

Posted on 9月 29, 2015 at 8:50 午後

Re: 管理画面へのアクセスを「httpsのみ」にしたい

菱川さん 遠藤さん

ありがとうございます!

アプリケーション診断にて、「ログイン情報をCookieに入れている場合は、セキュアな状態にしてね」という指摘がありました。

ログイン画面をhttpsにしても、ログイン後以降がhttpになってしまうのが、悩ましかった部分です。

管理機能全般もSSLで使用することになりますので、
httpsでのアクセス時は、フルページキャッシュをしないような処理も加えています。

SSLが使えるサーバ前提になりますが、セキュリティ診断が入る案件に対しては、幾分調整が必要な感じでした。

他には、細かいですが、
ログイン画面の「パスワード入力」には、オートコンプリートをOFFにしてね。
とか
ログイン後ページは、ブラウザキャッシュもno-cacheにしてね。
とか、小さい指摘は諸々ありますね。

Posted on 9月 29, 2015 at 11:51 午前

ページコピーからブロックの移動について

「ページをコピーしてからブロックの移動をすると、コピー元のブロックも一緒に移動してしまう」という現象が出たのですが、同じような症状になったかたおられますか?
------------------------
ver 5.7.5.1
------------------------

テーブルを見ますと、以下のデータ処理になっているようです。
(1)ページコピー
└>CollectionVersionBlocks に、同じbIDを持つレコードが作られる

 | cID | bID | cbDisplayOrder |
| 1 | 1 | 1 | ←コピー元
| 2 | 1 | 1 | ←コピー先

(2)コピー先でブロックの場所移動
└>CollectionVersionBlocks テーブルのbIDのみを条件にしているようで、同じbIDを持つレコードのソート順が全部変わる

 | cID | bID | cbDisplayOrder |
| 1 | 1 | 2 | ←コピー元(こっちのソートが変わった)
| 2 | 1 | 2 | ←コピー先


(1)は、過去バージョンもコピーしているので「複製」と考えれれば、コピーの仕様として合点がいくのですが、(2)のソート時にbIDのみを条件としているのが問題ありそうに感じています。

(2)の移動時は、bIDだけではなく、cIDも条件に入れるようにするべきかどうか判断したく、ご意見いただけないでしょうか。

Posted on 9月 29, 2015 at 11:34 午前

Re: 管理画面へのアクセスを「httpsのみ」にしたい

菱川さん >

考慮いたただきましてありがとうございます!

某セキュリティ会社のセキュリティチェックで「MIDDLE」の指摘を受けたところで、
「ログイン以降はhttpsにする」ということで対策を宣言したのですが、
つまずいてしまった次第です。


一旦、こちらでもとりあえずの回避をしたので、共有します。
resolverをいじって、httpsアクセスの時の判定に追加しました。


▼ CanonicalUrlResolver.php
/application/src/Url/Resolver/CanonicalUrlResolver.php へ

・namespace変更

・resolve変更
public function resolve(array $arguments, $resolved = null) {
$url = Url::createFromUrl('');

$url->setHost(null);
$url->setScheme(null);

----ここから追加 -------
$ssl = false;
$u = new \User();
try {
$ssl = $u->isLoggedIn();
} catch (\Exception $e) {
}

$request = \Request::getInstance();
if ($request && strpos($request->getPath(), "/login") === 0){
$ssl = true;
}

----ここからまで -------

if (\Config::get('concrete.seo.canonical_url')) {
$canonical = UrlImmutable::createFromUrl(\Config::get('concrete.seo.canonical_url'));

----ここから追加 -------
if ($ssl && \Config::get('concrete.seo.canonical_ssl_url')) {
$canonical = UrlImmutable::createFromUrl(\Config::get('concrete.seo.canonical_ssl_url'));
}
----ここからまで -------
$url->getHost()->set($canonical->getHost());
$url->getScheme()->set($canonical->getScheme());
if (intval($canonical->getPort()->get()) > 0) {
$url->getPort()->set($canonical->getPort());
}




▼application/bootstrap/app.php
以下を追加
--------------------------------
// CanonicalUrlResolver override
Core::singleton(
'url/canonical/resolver',
function () {
return new \Application\Src\Url\Resolver\CanonicalUrlResolver();
});
Core::singleton(
'url/canonical',
function () {
return \Core::make('url/canonical/resolver')->resolve(array());
});
--------------------------------


▼application/config/concrete.php

・secure属性を有効に(Cookie名/httponlyも変えています)
-----------------------------------
'session' => array(
'name' => 'ssid',
'handler' => 'file',
'save_path' => null,
'max_lifetime' => 7200,
'cookie' => array(
'cookie_path' => false, // set a specific path here if you know it, otherwise it'll default to relative
'cookie_lifetime' => 0,
'cookie_domain' => false,
- 'cookie_secure' => false,
+ 'cookie_secure' => true,
'cookie_httponly' => true
)
),
-----------------------------------

Posted on 9月 23, 2015 at 4:03 午後

管理画面へのアクセスを「httpsのみ」にしたい

いつもお世話になっております。
----------------------------
version : 5.7.5.1 を利用
----------------------------

セキュリティチェックに基づき、ログイン画面以降をhttpsでアクセスしたく思っております。
※CookieにSecure属性を付けて

ログイン画面を「https」 にしても、ログイン成功後に「http」になってしまいます。
ログイン後も「https」にしなおしても、各メニューへのリンクが「http」となっています。

※フロントは、Domain Mapper を使用している関係上、
 カノニカルURL以外のアクセスを、全SSLにする(concrete.seo.canonical_ssl_url)ことはできません。

管理画面をセキュアにする方法がありましたら、回避方法等ないでしょうか。
 

Posted on 9月 14, 2015 at 2:04 午後

【5.7.0.4】PDO_MYSQL - PHP5.3.6以前は charset指定 が効かない

【5.7.0.4】PDO_MYSQL - PHP5.3.6以前は charset指定 が効かない
------------------------

PHPのバージョンの問題だったのですが、
だいぶはまってしまったので共有させていただきます。

==================
<インストール先サーバ>
==================
PHP:5.3.5
MySQL :5.1.47
※concrete5 は、composerは使用しないで、サイトからの標準のインストールです。

==================
<現象>
==================
5.7 をインストールし、コンテンツを投入していったのですが、
MySQLの実データを確認してみると、charaset指定している「UTF-8」で入っておらず
「latin1」にエンコードされていました。
※「サイト上の表示は、文字化け無く表示されていた」ので気づかなかったのですが、
 単にUTF-8にデコードされていたただけっぽいです。


==================
<問題点>
==================
▼pdo-mysql
http://php.net/manual/ja/ref.pdo-mysql.connection.phpcharset

charasetの句ですが、
------------------------------------
「PHP 5.3.6 より前のバージョンでは、この要素は黙って無視されていました。
同じ挙動は、ドライバのオプション PDO::MYSQL_ATTR_INIT_COMMAND を使って部分的に複製できます。」
------
となっており、config/database.php に指定している charset は、 PHP5.3.6以前では認識されない模様です。


==================
<対処(暫定)>
==================
【■インストール前■】
ファイル:concrete/config/database.php

driverOptions部分を追加
------------------------
<略>
/**
* The database charset
*/
'charset' => 'utf8',
'driverOptions' => array(
PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES utf8'
)
<略>
------------------------

【■インストール後■】
ファイル:application/config/database.php

生成されたdatabase.php にdriverOptionsを追記
------------------------
<略>
'charset' => 'utf8',
'driverOptions' => array(
PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES utf8'
)
<略>
------------------------

SET NAMES が毎回通ってしまうので、あまりよろしくない方法かも知れませんが、
これで正常にMySQL Clientが「UTF-8」でデータを扱うようになりました。
==================

5.7.x は、 「PHP5.3.3 以降」がシステム要件っぽいですが、
PDO_MYSQLを使っている以上、「PHP5.3.6以降」の方がいいかもしれませんね。

Posted on 10月 17, 2014 at 2:15 午後

Re: CODA 新バージョンの意見募集 2011/9/22 (木) まで

・ソース管理に、Subversionの「クリーンアップ」を実行できるように。
 (今はsvnコマンドでクリーンアップするしか方法がない?)

・サイト設定で、リモートホストを複数設定できるように。
 (開発サーバと本番サーバをデプロイし分けることを想定)

・インデントを整形してくれる機能
 (ソースを綺麗に)

・DBの可視化できる機能。SQLの実行など。
 (CSEのようなもの)

・Eclipseのように、Ctrl + メソッド名クリック で、該当箇所にジャンプするなどの機能。

・構文のエラーチェック

・ソースコードのメトリクス計測(コードの大きさ、複雑さ、重複 など)を数値化するなど
(リファクタリング用)

Posted on 9月 14, 2011 at 3:33 午後
« 前12次 »