ec-cube-extended
ec-cube-extended copied to clipboard
EC-CUBE2系の非公式ミラーです。既に本家のサポートを終えた旧バージョンの保守を独自に続けようと思っています。
GDPR 対応
- 対応内容は要検討 - 会員情報を物理削除するとか - Myページから履歴をダウンロードできるようにするとか
SC_Query などのコンポーネントを Packagist で公開し、 Composer 経由で利用できるようにする。 そうすることで、 3系でも 2系の資産を活用することができる可能性がある。 また、メンテナンス性も向上する
郵便番号の自動登録部分でエラー。 PEARのHTTP_REQUESTが原因 ほかの使用部分はLC_Page_Upgrade_Base.php
{include file='file:index.tpl'} という書き方に変更する必要がある @see http://www.smarty.net/docs/ja/template.resources.tpl
HttpSession での認証と比較して、以下のような利点がある - CSRF の脆弱性が無い - Web API などにも応用可能 - サーバー側でのセッション管理不要(ステートレス) 特に、EC-CUBE2.4以下のバージョンの CSRF 対策として有効であると思われるが、 Authorization ヘッダで JWT を送る場合は JavaScript でハンドリングする必要がある https://github.com/lcobucci/jwt/tree/3.2 https://github.com/firebase/php-jwt https://www.sitepoint.com/php-authorization-jwt-json-web-tokens/
[CVE-2016-10033](http://blog.tokumaru.org/2016/12/PHPMailer-Vulnerability-CVE-2016-10033.html) への対策 PHPMailer のみならず、 EC-CUBE3 系で使用している SwiftMailer にも該当する。 EC-CUBE2系で使用している Pear::Mail でも同様の脆弱性が潜在していると考えられるが、以下の理由から攻撃は困難と思われる。 - 管理画面からのみの入力が対象 - そもそもバリデーションエラーになるため、通常は設定できない また、 MTA に Postfix を使用している場合は該当しない。 将来的には、 `MAIL_BACKEND` は SMTP のみのサポートとするのが良いと思われる。
#32 で削除されているが、本当に削除してよいのか要調査 ### see - https://github.com/nanasess/ec-cube-extended/pull/30#issuecomment-301464352 - http://svn.ec-cube.net/open_trac/ticket/2165 - https://xoops.ec-cube.net/modules/newbb/viewtopic.php?viewmode=thread&topic_id=9756&forum=14&post_id=48944#forumpost48944