ecshop还能用吗？部署现状与替代方案

ecShop是一套开源的B2C电商系统, 它是基于PHP和MySQL构建的。这个软件是由上海博思软件开发出来的。它最早是在2004年发布的。一直到2025年, 官方已经停止了主动更新工作。

最后一个公开版本是3.6.13, 这个版本大约是在2019年前后发布的时候推出的。

如果用户的需求仅仅是去快速地搭建一个非常小型的静态商品展示页面, 那么这个旧版本的程序仍然能够在本地环境里面成功运行和启动；但是, 如果后续的需求中包含了需要对支付接口进行功能迭代, 需要去修复各类安全方面的补丁, 或者是为了适配手机端移动终端的操作界面, 那么基于当前的技术状态, 它就已经不具备了持续可用的条件, 因此明确不建议将其使用在生产环境中所开展的新项目里。

当前维护状态与版本信息

基于ecShop官方GitHub仓库, 还有就是那个叫ecshop.com.cn的官方网站上面公开的这些信息来看, 这个项目最后一次有实质意义的代码提交的情况, 一直停顿在了3.6.x这个分支上面。

另外呢, 对于名为bbs.ecshop.com的这个官方论坛来说, 近两年的时间内, 活跃的帖子数量是非常低的, 低到几乎可以忽略不计的这种程度, 负责维护的人员那边, 也没有再发布任何关于安全方面的更新, 或者是为了修复兼容性而做的修补工作。

根据那些已经对外公开的资料来进行梳理之后, 主要版本的各个关键时间点的列表就展示出来了。

这个意思就是, 要是你在PHP 7.4以及比7.4更高的版本里, 去装那个原版的3.6.13。那么你就会触发非常多关于已废弃内容的警告消息。还有部分函数, 比如说create_function。

这些函数在PHP 8里面, 已经被完全移除掉了。这时候直接报错就会发生。如果你按照测试环境的情况来核对的话。那么PHP 7.2加上MySQL 5.7这两个组合到一起, 会是兼容性表现得最好的一个状态。

部署步骤与核心参数

我们可以将3.6.13作为具体的例子, 然后我们按照官方提供的安装文档上面所说的内容来进行操作, 这个操作环境指的是在本地搭建好的LAMP环境之中。

1. 先把源码给解压出来, 放到/var/www/html/这个路径下面去, 然后要让uploads/以及data/cache/这两个目录的写入权限能够达到755这个样子。

2. 在创建MySQL数据库的时候, 请把字符集选成utf8mb4, 这是因为旧版的安装脚本默认的字符集是latin1, 如果不去修改它就会导致中文的商品名出现乱码, 这是一个非常容易出错的环节。

3. 你需要去访问那个安装程序的向导界面, 然后按照顺序一步一步地把数据库连接的设置信息填进去, 把管理员账号的信息也填上, 最后再把这个Shop的名称给输入完毕。

4. 等安装工作做完了以后, 要把那个/install/这个目录给删掉, 或者把它锁起来, 如果不对它的访问进行严格的限制的话, 那么就有可能导致未授权访问的风险的存在。

那些关键的参数, 是在data/config.php生成之后, 可以在后台进行修改的。

会话存储, 默认的session, 在高并发场景下需要改为database模式。

缓存引擎的默认值是file, 这种情况对于单个实例来说是足够的, 但是在多服务器部署的时候, 需要将其切换成 memcached 或者 redis。

支付网关的具体配置，是在后台中的“支付管理”部分来处理的, 具体来说就是关于支付宝和微信支付的配置情况, 在旧版系统里面, 仅仅支持那种MD5的签名方式, 这一点是需要用户去手动进行改造和调整的, 目的是为了能够适配后来的RSA2这种标准方案。

已知限制与常见故障

这个问题在公开的社区讨论帖子里面, 还有那个代码审查的过程当中, 被多次反复地提到过, 它并不是一个特殊的个案情况。

支付签名不兼容: 在版本为3.6.13的时候, 支付宝模块只能够支持MD5这种签名方式。从2023年开始, 支付宝方面逐渐关闭了使用MD5的通道。

当那些旧的代码上线以后, 交易的回调结果将会返回invalid sign这样的错误信息。如果要进行修复的话, 就必须手动把签名算法替换成RSA2, 官方并没有提供现有的补丁。

移动端体验缺失: 原生模板是为纯PC端而设计的, 不存在响应式布局的结构。如果需要制作H5页面, 就得自己开发模板, 或者安装第三方插件, 但是这些插件的质量是参差不齐的。

无后台权限分级: 管理员只有一个角色, 没办法给不同的运营人员分配合适的权限。

SQL注入历史漏洞: 在3.4以及更早的版本里面, 存在着一个因为使用了没有进行参数化处理的查询而导致的漏洞。这个漏洞的CVE编号可以在国家漏洞数据库(NVD)那里去检索到。

到了3.6.x这个版本, 大部分的问题已经得到了修复。但是, 如果是使用社区版的话, 一旦把旧的代码混合进去了, 那么仍然有可能引入这种风险。

替代方案对比

如果是新的项目, 并且没有历史遗留问题的负担的话, 可以依据网络上公开可查询的资料信息, 对目前市场上主流的那些属于开源类型的电商系统进行相关内容的整理对比。

选择依据是什么呢? 这个需要你看清楚。如果你的团队只熟悉PHP, 而且还有预算有限的情况。那么, CRMEB或者WooCommerce是更务实的起点。反过来讲, 如果你是需要API优先的。还需要微服务架构的话。那么Medusa.js或者是自研Spring Boot方案就更合适一些。

FAQ

ecShop 3.6还能直接对接微信支付V3接口吗?

答案是不能。因为内置的支付模块仅仅适配了旧版的API, 这些旧版API使用的是MD5签名以及XML报文格式。然而, 新版V3接口要求使用RSA签名并且采用JSON格式的报文。所以, 开发人员需要自己重写位于pay目录下面的回调逻辑以及下单逻辑。根据测试环境进行核对的工作量, 大概需要2-3天的时间。

在安装完毕之后, 如果进入后台的登录页面时系统提示500错误, 应当如何执行排查工作。

第一步, 请先去data/cache/这个目录检查一下, 看它现在是不是具备了写入内容的权限。与此同时, 还要看一看PHP里面的safe_mode或者open_basedir这两个设置, 它们有没有对路径的访问进行某种限制。

另外要记住的是, 如果你当前使用的是PHP 8的话, 必须先把版本降低, 回退到PHP 7.4上面去再进行尝试。这么做的原因是3.6.13这个版本还没有办法兼容PHP 8的操作要求。

ecShop这个平台到底是存在官方认可的商业使用许可呢, 还是说有专门的提供技术支持的渠道可以找到?

在最初的时候, 官方是提供了一种需要花钱的定制开发服务的, 这种服务是不包含开源授权的, 但是根据大家能公开看到的信息显示, 这个服务在最近几年里面已经没有了实际的交付案例, 现在根本就没有官方的服务等级协议或者响应时间的承诺, 所以所有的技术支持都要依靠社区论坛来进行。

在停止更新之后, 还能够获取到安全补丁吗?

官方已经不再进行发布了。在GitHub上面, 存在一些零星的社区成员通过fork的方式对部分CVE问题进行了修补。然而, 这些修补版本并没有经过专业审计, 也没有进行测试, 更没有任何形式的官方背书。

如果在生产环境中确实必须使用该版本, 那么相关的团队需要自行开展代码审计工作, 并且还需要添加WAF规则作为最后一道防线来兜底。