<![CDATA[Blog]]> https://www.magentodiy.com/blog/ Sat, 09 May 2026 12:05:10 +0000 Zend_Feed http://blogs.law.harvard.edu/tech/rss <![CDATA[常见问题]]> https://www.magentodiy.com/blog/cjwt/ #1031 - Table storage engine for 'catalog_product_relation' doesn't have this option 之类> MYSQL5.7默认打开。innodb_strict_mode = off in my.conf #

 

分树

]]> Tue, 24 Jan 2017 15:41:17 +0000 <![CDATA[睿智的Magento团队 - 洛杉矶]]> https://www.magentodiy.com/blog/magento-tuandui/ Magento 团队

]]> Sat, 21 Dec 2013 16:24:08 +0000 <![CDATA[祝贺MagentoDIY成为GO合作伙伴]]> https://www.magentodiy.com/blog/magentogo-huoban/ 祝贺MagentoDIY成为GO合作伙伴

Magento GO是在线商店，让客户从最简单的方式来运营自己的产品，随着电子商务平台的信任，超过150,000招商 。

 Magento GO 合作伙伴

 

]]> Sat, 01 Dec 2012 14:44:21 +0000 <![CDATA[Magento 2012年秋季电子商务论坛]]> https://www.magentodiy.com/blog/Magento_E-Commerce_Forum_Summit_in_the_fall_of_2012_in_quarter/ 秋季2012年电子商务论坛峰会 
Magento 2012 秋季电商论坛

Magento电子商务论坛给零售商和厂家的机会，以满足电子商务需求从我们的产业链系统，与会者们交流，更多的了解我们的解决方案，工业和托管合作伙伴携手共进，实现成功的Magento网站的零售商增加销售和客户忠诚度的结果。这些论坛也是一个机会，为商户提供有价值的电子商务技巧，采取​​和实施自己的企业。

今年秋天，我们有机会在16个城市，以满足零售商从多伦多到纽约，洛杉矶，迈阿密，和许多城市之间。随着电子商务的持续增长和发展，我们将继续举办这些活动，使我们能够分享电子商务的知识，最佳做法和成功的Magento客户的故事。随着电子商务的持续增长和发展，我们将继续与Magento的社区分享，成功经验和最佳做法，通过这些论坛。

我们非常感谢我们的合作伙伴提供的宝贵支持，使这些事件可能。非常感谢所有的合作伙伴，赞助跌倒事件。

MagentoDIy.Com

最后，谢谢大家，我们的Magento所有参加我们的电子商务活动的伙伴。您的精力，热情和创造力，是鼓舞人心的。

]]> Fri, 09 Nov 2012 02:59:27 +0000 <![CDATA[Magento RPC-Zend框架的漏洞安全更新]]> https://www.magentodiy.com/blog/magento-rpc/ Magento RPC漏洞解决方案：

基于 Zend 的安全漏洞，可直接读取服务器任何信息。各位客户可根据自己的Magento版本,SVN相应补丁，或注释掉以下文件的代码即可。（本司客户，请发站内支援请求，并提供FTP，会有程序员帮您打上补丁的。）

解决方案 / Solution

Magento企业版

  • 根据我们实践总结，我们建议，所有的企业版的客户，尽可能请升级到最新版本（v1.12.0.2）采取最新补丁和功能。
  • 或者根据您的平台版本，请选择相应的解决方案：
您的当前版本 推荐的解决方案
Magento 企业版 1.12.0.0 + 升级到最新版本（浏览下载Magento企业版>发布-登录帐户的要求）
Magento 企业版 1.8.0.0 - 1.11.XX 应用在Zend的安全升级补丁（浏览下载Magento企业版>补丁与支持-登录帐户是必需）
Magento 企业版本1.8.0.0之前的版本 可使用变通办法（以下说明）


Magento的专业版


Magento的社区版

  • 如果可以，我们建议，所有社区版客户尽量升级到最新版本（v1.7.0.2），使用最新的补丁和功能优势。
  • 若不方便升级，可根据您的平台版本，请找到相应的解决方案：
您的当前版本 推荐的解决方案
Magento1.7.0.0 + 升级到最新版本
Magento1.5.0.0 至 1.6.XX 应用此修补程序
Magento1.4.2.0 应用此修补程序
Magento1.4.0.0 至1.4.1.1 应用此修补程序
Magento1.4.0.0以前的版本 可使用变通办法（以下说明）


Magento GO

Magento GO的客户将不需要做任何更新。所有修补程序将在后台自动应用。

Instructions on Applying the Patch

  • 1. Go to the root of your Magento root directory: cd /home/mystore/public_html
  • 2. wget –O patch_name.patch
  • 3. Download the patch from the provided link appropriate for your version (this line allows you to do it from the Unix command prompt)
  • 4. Apply the patch: patch -p0 < patch_name.patch

*Note that if you are running more than one web server, the patch will need to be applied to all the servers.

Workaround

If an upgrade cannot be performed or the patch cannot be applied immediately, the following instructions can be followed to temporarily disable the RPC functionality that contains the vulnerability.

Please note that this workaround can only be applied to versions of CE 1.4 and below and EE 1.8 and below.

Also, please be advised that any integrations that rely on the XMLRPC API functionality will no longer work after this workaround is implemented.

  • 1. On the Magento web server, navigate to the www-root where Magento app files are stored.
  • 2. In the wwwroot, navigate to /app/code/core/Mage/Api/controllers.
  • 3. Open XmlrpcController.php for editing.
  • 4. Comment out or delete the body of the method: public indexAction()
  • 5. Save the changes.

Technical Clarification

As some of our experienced community members have discovered, the development fix in CE 1.7.0.2 and EE 1.12.0.2 differ from the fix provided in the patches. In the latest releases, we decided not modify the Zend library directly, but override vulnerable methods within Magento Code by adding two new classes:

  • app/code/core/Zend/XmlRpc/Response.php
  • app/code/core/Zend/XmlRpc/Request.php

We did this in order to keep coherency of the underlying Zend Framework version 1.11.1 for Magento 1.X. We are planning to upgrade the Zend Framework in Magento in the upcoming releases.

]]> Thu, 05 Jul 2012 00:38:00 +0000 <![CDATA[Magento EE企业版缓存攻击]]> https://www.magentodiy.com/blog/magento-ee-Cache-Poisoning-Attac/ Summary: Magento Enterprise Edition is vulnerable to poisoning of its page cache under some configurations due to inappropriate trust of HTTP Host header values. Impact: Users shopping at online stores driven by Magento EE can be redirected to arbitrary third party sites, allowing malicious entities to entice users to hand over their credit card information inappropriately. Severity: Major -- Exploit allows for content injection, and hijacking of users. Exploits have been observed in the wild. Fix/Workaround Status: At this time, the vendor (Magento Inc) has only stated an intent to fix the problem (as a "product enhancement") but has not provided any patch despite being given considerable lead time by us and being first made aware of the problem in 2008 (see note below for more details). The issue can be worked around using one of several configuration- related changes, including one which the vendor introduced in 2008. Affected Versions: All versions of Magento EE, up to and including 1.9.1.1 (the latest as of this writing) when page caching is enabled. It is unclear if the block-level caching in Magento Community/Professional Edition is similarly impacted, however both are likely vulnerable to the misinterpretation of data. Details: Magento uses a hierarchical configuration mechanism, allowing values such as site URLs to be set at a global level and at a more specific per-storefront level. Magento EE adds a mechanism for caching whole pages. With default URL values, Magento EE can be tricked into generating page cache entries with arbitrary URL values by simply sending an artificial HTTP Host header. Unfortunately, setting the URL value at the *storefront* level is insufficient to prevent this behavior. In order to prevent this issue, one of the following must be true: The key is to have the web server send only trustworthy/cleansed values to PHP. The following are example approaches for Apache: * Your web server is configured in a way that results in untrusted Host values never being sent to PHP. An example of this would be the use of name-based vhosts that do not point the "_default_" vhost to a Magento instance. * Using one or more ServerAlias masks with IP-based vhosting to constrain the range of valid host values. Magento level: * Provide Base Unsecure URL and Base Secure URL values in the "Default Config" (top-level) configuration. The precise values do not appear to matter, just so long as some value is present. Reproducing the problem simply requires requesting any URL with a forged Host header at a time when the page cache is considered invalid. Nota Bene: The vendor's solution to the problem when confronted with it in 2008[1] was to introduce a vaguely worded warning[2] in the admin UI when the base URL value is not defined at the top level of the configuration hierarchy. Given that: 1) It is not made clear that the configuration status presents a severe security hole. 2) A non-default base URL value in the top-level configuration level is never actually *used* in page-cache generation. Its presence apparently serves only to trigger use of the per-storefront configuration value. We therefore hold that the provided warning does not suffice as a 'fix'. The vendor has indicated that they believe otherwise both through their actions and their communications with us. References: [1] http://www.magentocommerce.com/boards/viewthread/8220/ [2] The exact wording of the message is: "{{base_url}} is not recommended to use in a production environment to declare the Base Unsecure URL / Base Secure URL. It is highly recommended to change this value in your Magento configuration."]]> Mon, 07 Feb 2011 04:20:00 +0000 <![CDATA[Magento 系统要求]]> https://www.magentodiy.com/blog/System_Requirements/ System Requirements

At the base level, Magento will require the following software:

1:环境检测器  Magento environment detector
2:权限重置 Magento permissions reset 
3:数据库修复 Magento database repair  

  • Supported Operating Systems:
    • Linux x86, x86-64
  • Supported Web Servers:
    • Apache 1.3.x
    • Apache 2.0.x
    • Apache 2.2.x
    • Nginx (starting from Magento 1.7 Community and 1.12 Enterprise versions)
  • Supported Browsers:
    • Microsoft Internet Explorer 7 and above
    • Mozilla Firefox 3.5 and above
    • Apple Safari 5 and above on Mac only
    • Google Chrome 7 and above
    • Adobe Flash browser plug-in should be installed
  • PHP Compatibility:
    • 5.2.13 - 5.3.15
    • Required extensions:
      • PDO_MySQL
      • simplexml
      • mcrypt
      • hash
      • GD
      • DOM
      • iconv
      • curl
      • SOAP (if Webservices API is to be used)
    • Safe_mode off
    • Memory_limit no less than 256Mb (preferably 512)
  • MySQL:
    • 4.1.20 or newer
    • InnoDB storage engine
  • SSL:
    • If HTTPS is used to work in the admin, SSL certificate should be valid. Self-signed SSL certificates are not supported
  • Server - hosting - setup:
    • Ability to run scheduled jobs (crontab) with PHP 5
    • Ability to override options in .htaccess files
]]> Tue, 17 Mar 2009 06:00:00 +0000