danneh.org

Bug in Magento 1.6.1.0/1.6.2.0 affecting development sites using base_url

by on Nov.14, 2011, under Magento, PHP

I installed a copy of Magento 1.6.1.0 on a dev site I setup to do some testing with Varnish with (more on that later). However, in the requirement to be able to get to Magento using 2 different URL’s, I stumbled across this quite annoying bug.

a:5:{i:0;s:67:"Illegal scheme supplied, only alphanumeric characters are permitted";i:1;s:729:"#0 /home/dan/workspace/magento1610/app/code/core/Mage/Core/Model/Store.php(712): Zend_Uri::factory('{{base_url}}')
#1 /home/dan/workspace/magento1610/app/code/core/Mage/Core/Controller/Varien/Front.php(313): Mage_Core_Model_Store->isCurrentlySecure()
#2 /home/dan/workspace/magento1610/app/code/core/Mage/Core/Controller/Varien/Front.php(161): Mage_Core_Controller_Varien_Front->_checkBaseUrl(Object(Mage_Core_Controller_Request_Http))
#3 /home/dan/workspace/magento1610/app/code/core/Mage/Core/Model/App.php(349): Mage_Core_Controller_Varien_Front->dispatch()
#4 /home/dan/workspace/magento1610/app/Mage.php(640): Mage_Core_Model_App->run(Array)
#5 /home/dan/workspace/magento1610/index.php(80): Mage::run('', 'store')
#6 {main}";s:3:"url";s:85:"/index.php/admin/system_config/edit/section/web/key/41c8c3d3f4bcb72e3c267ae0b73333d7/";s:11:"script_name";s:10:"/index.php";s:4:"skin";s:7:"default";}

Bug reports on Magento’s site here, here, here and here. Not being patient enough for Varien to fix it, I developed a small extension which resolves the problem. It’s available to download below.

Put the tarball in the Magento webroot and extract. After you install this extension, you’ll need to empty the cache manually (if it was enabled). I assume if you’re reading this, then your Magento installation is broken. To do this, simply remove the contents of var/cache in Magento’s webroot.

When you re-visit your Magento’s front or backend, the problem should vanish.

BTS_1610Fix.tar.gz (md5: 8316468f4e179cf2f512edaaf62a12db)

Updated 9th January 2012: It apparent that, attempting to login before applying this update with {{base_url}} set screws up the admin login cookies somehow. When you apply this patch, you’ll probably need to empty out your chosen browser’s cookie jar before attempting to login. You can tell if you need to or not by trying to login, and Magento coming back to you with a login screen, with no failed login message.

Updated 12th January 2012: Magento 1.6.2.0 was released today. I can confirm that this problem still exists and has not yet been fixed (despite what the developers have written on one of the bug reports).

Updated 25th April 2012: I can confirm that this problem has been resolved in the latest 1.7.0.0 version, released 24th April 2012.

:, , ,

77 Comments for this entry

  • Sky
    November 19th, 2011 on 9:11 pm

    Extracted contents cleared cache, and still same issue. Can you help me? Thanks!

  • Ivo
    November 20th, 2011 on 4:32 pm

    Thanks man worked !

  • Lilly
    November 21st, 2011 on 4:59 pm

    Thank you SOO much for solving my headache! And in such a clean and nice way ^^

  • Dan
    November 21st, 2011 on 7:38 pm

    @Sky;
    It sounds to me like there’s still some caching going on. Are you using an opcode cacher like APC or similar? If you are, try flushing this out as well (simply restarting your favorite web server usually suffices). Make sure the contents of var/cache are completely emptied out, and your browser hasn’t cached anything either.
    Other than that, I don’t really know what else could be causing the issue. Though, if you’re still having problems after that, contact me directly with FTP and Magento admin details and I’ll see if I can help you out.
    Dan

  • Anis
    November 21st, 2011 on 9:47 pm

    thanks it works

  • delaFuzz
    November 22nd, 2011 on 12:44 am

    Thanks mate, it worked flawlessly.

  • Dinesh
    November 22nd, 2011 on 11:22 am

    Thanks its working fine

  • Raghav
    November 23rd, 2011 on 7:47 am

    Thank a lot man I was facing this ridiculous problem from the past one week.

  • James Strong
    November 25th, 2011 on 2:52 am

    You rule man. YOU RULE.

  • Son
    November 25th, 2011 on 4:44 pm

    Great! Thank a lot, it worked for me

  • Craig
    December 2nd, 2011 on 3:31 pm

    This worked for me as well.

    Would you mind explaining at a high level what this issue is and how you go about solving it?

  • Dan
    December 3rd, 2011 on 12:07 pm

    Well, from what I can see, Magento has changed the method in which it detects whether the store is in SSL mode or not. This is something they’ve been messing with for a while. In v1.6 (I think) they introduced this “SSL_OFFLOADED” HTTP header which allows you to tell Magento it’s in SSL mode, even if the web server (Apache) believes it isn’t (for instance, if you offload SSL encryption to a load balancer, or front-end static-content web server like nginx). This has obviously changed the isCurrentlySecure() function inside the code in order to accommodate for this new feature (which I already have made use of on production sites, so it’s not all bad!). However, I can’t explain why they changed what they did and released 1.6.1.0 with it breaking {{base_url}}. It’s a common thing to use this on development sites, and they know that developers do use it because they put that warning up saying “you really shouldn’t use {{base_url}} on production systems”.

    Basically, my fix overloads the function that does the detection, and if the secure base URL parameter is indeed {{base_url}}, to parse it out into an actual URL (comprised of HTTP_HOST, SERVER_PORT, etc) before passing it into Zend_Uri::factory(). The extra 3 lines I provided into this function simply calls another built-in Magento function which substitutes {{base_url}} into the real thing. This end result then gets passed into Zend_Uri::factory() which then provides the relevant methods for Magento to reliably detect whether it’s in secure mode or not.

    Zend_Uri fails because it’s illegal to have { and } characters in the URL string at the domain level, which is where the exception that we’re seeing is thrown from.

    What’s more interesting is that Magento have yet to officially respond with a fix for this yet. They’re normally quite slow at that sort of thing anyway, but it makes me wonder if they’ve done this on purpose and they don’t intend to fix it. I guess only the release of 1.6.2.0, 1.6.1.1, or 1.7.0.0 (whichever comes first) will tell us!

  • dejame
    December 7th, 2011 on 9:05 am

    thanks a lot! it works….

  • vacu
    December 10th, 2011 on 7:04 am

    Cheers mate! Worked like a charm!

  • mlan
    December 16th, 2011 on 8:42 pm

    Congrats, man! Realy works!

  • M. Rubin
    December 21st, 2011 on 9:58 pm

    It works! Thank you so much, I was ready to give up on Magento.

  • gmooxs
    December 22nd, 2011 on 2:01 pm

    it’s works good now, thanks for the tutorials :)

  • vale011
    December 29th, 2011 on 10:40 am

    Thanks mate! worked on WampServer 2.1

  • Kaulik
    January 1st, 2012 on 11:27 am

    Thanks man that worked..

  • Diana
    January 3rd, 2012 on 1:22 am

    Worked well, but now I can’t login to the admin backend anymore. I see even reset my pasword in the database, but it doesn’t let me in… any clues? does it have to do anything with this fix?
    thanks for your help.

  • Johannes
    January 4th, 2012 on 9:35 am

    Hi Dan!
    Thanks for the fix – it worked!
    And thanks for the explanations!

    @ Diana: I have the same problem, tried the same to solve it; so far without success.
    Have you tried the reset-password option?
    In my case, it resulted in a blanc email; I reckon some misconfiguration of the testshop i’m currently working on.

  • shawn
    January 4th, 2012 on 2:38 pm

    it’s fixed.
    Thanks so much!

  • Johannes
    January 4th, 2012 on 2:46 pm

    Yup – still not able to access the backend anymore.

    Any help greately apprechiated!

  • Dan
    January 4th, 2012 on 3:22 pm

    @Johannes, @Diana

    I highly doubt this extension is causing admin login issues. All this does is replace {{base_url}} with the correct URL so that Magento can reliably detect if it’s running in secure mode or not. The code I provided does nothing of the nature surrounding admin login, and I also strongly suspect a configuration issue with the store itself.

    However, without any more to go on (error logs, access to be able to diagnose myself) I can’t really offer any more information/help. If you want to use the contact form and give me URL’s to the test store, admin login credentials to try to use, and access to the codebase (FTP, etc), I can try and see why you’re having issues.

    Dan

  • Johannes
    January 4th, 2012 on 4:19 pm

    @Dan,

    I apprechiate your reply and helpfulness very much!

    You could very well be right – in that case of cause, I deeply apologize!

    Here’s some more details; some more via the contact form.

    It’s not really causing errors which one could see, but simply leads one back to the login page after sending the data. No JS error, no errors anymore in var/report/ – that was fixed by your code ;-)

    I compared the HTML source of the login pages of both productive and testshop – no differences apart from paths and (of cause) different form_key values.

    Again: frontend is ok! :-) thanks again!

  • Johannes
    January 5th, 2012 on 7:32 am

    Hello Dan & all,

    no more login-problems: after clearing all browser sessions and the corresponding cookies, the problems to login to the backend vanished.

    So thanks to Dan again!

    cheers,
    Johannes

  • shani
    January 7th, 2012 on 8:31 am

    you are real hero of magento :)
    great effort

  • Isaac
    January 9th, 2012 on 4:44 pm

    Thanks for the fix, works like a charm!
    A shiny star sticker for you!
    Encountered the problem with backend login, I’m guessing it only applies to new installations with sample products?
    Anyway, it can be solved by changing your email in the database manually, and retrieve password from the login prompt, or
    http://www.magentocommerce.com/wiki/recover/resetting-admin-password

  • Garynb
    January 9th, 2012 on 5:17 pm

    Excellent worked perfectly. Well done!

  • Shivam
    January 9th, 2012 on 7:13 pm

    Worked well, but now I can’t login to the admin backend anymore using chrome. If i use mozilla firefox it works fine.

  • Dan
    January 9th, 2012 on 7:14 pm

    @Shivam; Clear your cookies. The problem is cookie related.

  • momfer
    January 10th, 2012 on 2:47 pm

    Thanks a lot! Worked like a charm!

  • Tiago
    January 10th, 2012 on 3:35 pm

    it works like a charm!!

  • rickyg
    January 13th, 2012 on 5:55 am

    thank you – you saved many hours!

  • Anthony Munene
    January 15th, 2012 on 11:01 am

    Thanks for this fix!

  • mark
    January 17th, 2012 on 7:11 am

    thank you, it works!!

  • Dennis
    January 17th, 2012 on 5:08 pm

    Hi Dan,

    im running Mamp with a clean install and the fix isn’t working,

    i copied the files, restarted my webserver but a no go for me

    http://localhost:80/store/ out shoot i reinstall with the disable url fix check on

    Cheers

    Dennis

  • Dan
    January 17th, 2012 on 5:12 pm

    Hi Dennis,
    Did you clear your browser cookies?
    Dan

  • Kirstin
    January 17th, 2012 on 11:35 pm

    Worked! Thank you!

  • Bijal
    January 22nd, 2012 on 3:25 pm

    thank you so much. it works for me…

  • Marc Falk
    January 23rd, 2012 on 11:06 am

    Thank you very much, the extension works like a charm.

    I had problems logging into the backend as well, but cleared cache and sessions after which it worked perfectly.

    (Running MAMP 2.0.5 and Magento 1.6.2.0)

  • Amit
    January 23rd, 2012 on 3:10 pm

    Thanks Man!! I worked like a Charm.

  • Domenico
    January 25th, 2012 on 8:38 pm

    Thanks. It works like a charm!!

  • Lior
    January 27th, 2012 on 12:45 pm

    Thank you so much man, your the best!

  • 天野之谜
    February 1st, 2012 on 6:49 am

    you are great

  • sonny
    February 8th, 2012 on 3:45 am

    Hello,

    I still can’t login even after clearing the var/cache folder and my browser (google chrome). Any idea as to what may be going?

  • sonny
    February 8th, 2012 on 3:50 am

    It’s strange because I was able to log in using safari. Google Chrome however, not so much.

  • Bubulix
    February 13th, 2012 on 10:57 am

    Work’s perfect. Thanks

Newer Comments »

5 Trackbacks / Pingbacks for this entry

Leave a Reply

 

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

Blogroll

A few highly recommended websites...

Archives

All entries, chronologically...