Any possibility we can exchange 1.9.2.0 for 1.6.2.0?
The file downloading for Magento 1.6.2.0 suffered a numeral inversion problem
PATCH_SUPEE-6788_CE_1.9.2.0_v1-2015-10-30-06-24-02-1.sh
and it fails with the expected results.
One highly informative line from the patch that indicates it's totally wrong for 1.6.2.0 is this:
--- dev/tests/functional/.htaccess |
The dev/tests/ directory structure is introduced in Magento CE 1.9
Solved! Go to Solution.
Sorry for the delay, and error, everyone. The corrected version is uploaded for 1.6.2.0 now.
Having the exact same problem right now. Can we get a solution please?
On the new corrected 1.6.2.0 Magento Patch with 1.6.2.0 in the file name:
BEFORE APPLYING THIS PATCH, BACK UP THE FOLLOWING FILE!!!
app/code/core/Mage/Core/Controller/Request/Http.php
Anybody notice anything odd with app/code/core/Mage/Core/Controller/Request/Http.php ?
It appears to be attempting to patch the original 1.6.2.0 version, not the SUPEE-5344/5346 patched version
So, if you have it fail on app/code/core/Mage/Core/Controller/Request/Http.php and copy in the original 1.6.2.0 version of Http.php and have the patch successfully apply then...
Your backend probably falls over looking for a protected_forward function.
Working through the mess, I'm working on merging the two patched files for getting a functioning website post patch...
REMEMBER, DON'T MODIFY CORE CODE... Bwahahaha
Hoping to be beyond this version SOON!!!
Sorry for the delay, and error, everyone. The corrected version is uploaded for 1.6.2.0 now.
Modified 1.6.2.0 SUPEE-6788 function getHttpHost() /** * Retrieve HTTP HOST * * @param bool $trimPort * @return string */ public function getHttpHost($trimPort = true) { if (!isset($_SERVER['HTTP_HOST'])) { return false; } $host = $_SERVER['HTTP_HOST']; if ($trimPort) { $hostParts = explode(':', $_SERVER['HTTP_HOST']); $host = $hostParts[0]; } if (strpos($host, ',') !== false || strpos($host, ';') !== false) { $response = new Zend_Controller_Response_Http(); $response->setHttpResponseCode(400)->sendHeaders(); exit(); } return $host; }
SUPEE-5344/5346 Modifications /** * Flag for recognizing if request internally forwarded * * @var bool */ protected $_internallyForwarded = false; /** * Define that request was forwarded internally * * @param boolean $flag * @return Mage_Core_Controller_Request_Http */ public function setInternallyForwarded($flag = true) { $this->_internallyForwarded = (bool)$flag; return $this; } /** * Checks if request was forwarded internally * * @return bool */ public function getInternallyForwarded() { return $this->_internallyForwarded; }
Thanks chiefair for saving my time... Is magento going to release a patch tested SUPEE6788 or do we need to revert previous patches to install that one... as far as I've seen nothing is said about that...
Is that particular file giving you issues? => app/code/core/Mage/Core/Controller/Request/Http.php
I run a third party FPC and between me and the developer, we backported what was the SUPEE-6482 EE patch for the header issue as documented here.
The developer was none too pleased with a comment made elsewhere than Magento Community as to why the SUPEE-6482 patch for CE didn't include it and that there was no vulnerability whatsoever (well, until you load any of about 8 FPC modules for CE) at which point you rock the vulnerability meter at per the official Magento SUPEE-6788 page:
CVSSv3 Severity: | 9.3 (Critical) |
And so we come forward to SUPE-6488 where kick myself for being proactive, go back, snag the file output originally by SUPEE-6482 and suddenly everything is all Bristol fashion and ship-shape...
All you out there with stock 1.6.2.0 with SUPEE-6482 and SUPEE-5344/5346 installed should have no issue with the above mentioned file
REMEMBER, DON'T MODIFY CORE CODE... Bwahahaha
Sorry @chiefair! The error you're experiencing is because of modifying the last patch, not because of the current patch, correct? Just making sure there's nothing I need to bring to the team about 6788.