Magento

dazzercommerce - 10 April 2009 05:01 AM

I would just like to say that I have honestly never seen anything like this. These clowns are obviously doing this on purpose. Why do you think they are not posting the correct solutions here? They want you to pay for support. Has anyone here paid for support, could you let us know the solution they gave to this problem? This is supposed to be open source but I think we are all being played, and I think this is the first sight of a larger corporation monopolising the open source community (i.e. people who use Joomla! oscommerce etc.) and profiteering from the bugs instead of fixing them.

Anyone interested in branching off and creating a proper version of this software that actually works without the need of the developers to fix each installation? Trust me do what Joomla did on Mambo and it would be a revolution.

Another thing that worries me is: when I finally do get this damn thing working and hand it over to my client, am I going to be constantly hounded for support because login, or submit buttons, or cart functions magically stop working.

What a con!! If i cant get this working by the end of the day I’m using oscommerce. Might not look all shiny but at least it bloody well works and has a solid supporting community behind it.

I have to agree here…
Just installed version 1.3.2 and STILL ran into this problem!!
Imagine looking for a new ecommerce solution, installing this package, and not even being able to login after installing it out of the box!
Then looking in these forums, I find this particular problem hasn’t been solved now for 2 Years!!!

Also, reading comments from people who had the store working already, and THEN run into this problem doesn’t give a lot of confidence in this package either…

So, haven’t even started, and already thinking of going back to osCommerce…

Yeah I do agree with you (Zappo).  Magento should have fixed this problem by now…

But regardless.... It seems that my problem is fixed for both 1.2 and 1.3 with IE, FF, Chrome, Opera

I personally prefer magento over oscommerce due to the professional look and functionality of the backend and frontend.

There should be some sort of free manual explaining in detail all the programs and files of magento, what they are used for, how they can be edited.....

PS.  here are a couple of notes ive been making for myself…

Designnotes.htm  (File Size: 63KB - Downloads: 832)

I resolved my issue by adding

extension=pdo.so
extension=pdo_mysql.so to my php.ini file

This is a long thread, and there are lots of fixes mentioned - I’ve tried them all with no success. 

Here’s my problem: one of our staff, when first experiencing the problem logging in to Magento, requested a new password emailed to us.  We got the email . . .

Dear, ,
Your new password is:
You can change your password at any time by logging into your account.
Thank you again,
Herbs of Light.com/strong>

As you can see, there is nothing there, after “your new password is: “ That’s exactly how the email came to us - no new password.  Now, when we try to login with the old user information, even after implementing all the fixes mentioned in this thread, we get the “Access Denied” message.  How can we figure out what our password was reset to?

Any clue as to why our password email was missing a password?

I just went into phpMyAdmin, admin_user to see users and passwords.  All our passwords looked bizarre - very long, random letters and numbers.  I changed one of the administrator’s passwords to the correct value.  Still no good.  I got “Access Denied” again.

Same problem here.  Logged in by using Opera.

Solution 1: Domain Name with no dots

This is the most common solution, if you have set up Magento to run locally (on MAMP for example) then you may be accessing the Apache webserver using the localhost hostname. A security setting in browsers means that the cookie will not be set
Souce: http://www.aschroder.com/2009/05/fixing-magento-login-problem-after-a-fresh-installation/comment-page-1/

Same problem here.  Logged in by using Opera.

Solution 1: Domain Name with no dots

This is the most common solution, if you have set up Magento to run locally (on MAMP for example) then you may be accessing the Apache webserver using the localhost hostname. A security setting in browsers means that the cookie will not be set
Source: http://www.aschroder.com/2009/05/fixing-magento-login-problem-after-a-fresh-installation/comment-page-1/

You may get some help from this link:
http://blog.chapagain.com.np/magento-admin-login-problem/

I had the same problem. I could not log in to the admin interface.
The system requirements say that mhash is required. As soon as I installed it, my problem was solved.

i meet this problem,but with diff situation:

1,for the one who installed magento on local host,if you can not logged in admin backend,you can just make a fack dns record on your local hosts file

linux: /etc/hosts add new line like 127.0.0.1 http://www.example.com

or just use ip to access.
2.for those who have prob in remote server,

i prefer to use filesystem to store session,seems db have prob.

second,make sure you apache user have the right permission on var directory

then,set the right locale,which have relation with time zone of the server.

if this still not solve the prob,you then need to change the session time out to 86400(one day) as this can solve the time diff caused by timezone.

last if you still can not get into it.i thought the following way can absolutely solve it:

-Go to app/code/core/Mage/Core/Model/Session/Abstract/Varien.php file within your magento directory.

-Find the code,

session_set_cookie_params(
$this->getCookie()->getLifetime(),
$this->getCookie()->getPath(),
$this->getCookie()->getDomain(),
$this->getCookie()->isSecure(),
$this->getCookie()->getHttponly()
);

-Replace above code by,

session_set_cookie_params(
$this->getCookie()->getLifetime(),
$this->getCookie()->getPath()
//$this->getCookie()->getDomain(),
//$this->getCookie()->isSecure(),
//$this->getCookie()->getHttponly()
);

Thanks for your help, it really works.

Go to app/code/core/Mage/Core/Model/Session/Abstract/Varien.php file within your magento directory.

-Find the code,

session_set_cookie_params(
$this->getCookie()->getLifetime(),
$this->getCookie()->getPath(),
$this->getCookie()->getDomain(),
$this->getCookie()->isSecure(),
$this->getCookie()->getHttponly()
);

-Replace above code by,

session_set_cookie_params(
$this->getCookie()->getLifetime(),
$this->getCookie()->getPath()
//$this->getCookie()->getDomain(),
//$this->getCookie()->isSecure(),
//$this->getCookie()->getHttponly()
);

Approved for implementation to not set these parameters to session cookie by default.
Planned to be in 1.4 stable

imrantariq - 28 August 2009 03:05 AM

Thanks for your help, it really works.

Go to app/code/core/Mage/Core/Model/Session/Abstract/Varien.php file within your magento directory.

-Replace above code by,

session_set_cookie_params(
$this->getCookie()->getLifetime(),
$this->getCookie()->getPath()
//$this->getCookie()->getDomain(),
//$this->getCookie()->isSecure(),
//$this->getCookie()->getHttponly()
);

Did all this.
Still can’t get into backend!

I tried everything suggested in this thread, but without success. Keep it up developers, good sense of humor.

This is the right path.  All of the reported issues revolved around the way the specifics of the cookies were being managed by the browser and by the server.  When the cookie was used by Magento to do it’s conditional checking it was failing because the cookie was seen as invalid.  Increasing the timeout of the cookie to basically turned off the time zone checking.

I’d hazard a guess that the different behaviour of the browsers was because of the way they stored the information and served it back to the server. FF working was a fluke.  It might even be a bug in the way FF works with cookies.

I got the same behaviour on VIsta, XAMPP, and Magento 1.3.2.4.  I eventually logged in by removing the lines specified.  Once I logged in I checked the ‘locale’ options and they were completely wrong.  They were set to the first entry in the dropdown.  I’m pretty sure I set the locale information correctly on installation.  This might be the major issue. The next thing I think is happening is that testing for Magento is only being done in a production environment like you would find in a hosting service.  This would explain the issues with domain names affecting login.

Everything points to the testing being insufficient, and not varied enough.  Also, IMHO the session cookie information being stored is overkill as well.  You don’t need that level of information for a login or for much else in ecommerce.

The truly embarrassing thing is Magento not fixing this and then adopting a solution from the forums when they charge so much for support.  Shame on you Magento.

This is basic, basic stuff.  Not even being able to log in is inexcusable, regardless of the number of people it affected.

You should be giving the fella with the solution a free year of support at the very least.  He did what you didn’t do.  Provide service to the community. 

Because of this approach to problem solving I would be very hesitant to use Magento for anything commercial.  If you won’t provide good service to a community (which you claim to support, or is that nice orange section of the menu bar just for looks?), which is the stepping stone to the paid version, why should we trust you with thousands of dollars per year?

The handling of what should have been a trivial issue has been very poor.

quote author="imrantariq" date="1251471905"]Thanks for your help, it really works.

Go to app/code/core/Mage/Core/Model/Session/Abstract/Varien.php file within your magento directory.

-Find the code,

session_set_cookie_params(
$this->getCookie()->getLifetime(),
$this->getCookie()->getPath(),
$this->getCookie()->getDomain(),
$this->getCookie()->isSecure(),
$this->getCookie()->getHttponly()
);

-Replace above code by,

session_set_cookie_params(
$this->getCookie()->getLifetime(),
$this->getCookie()->getPath()
//$this->getCookie()->getDomain(),
//$this->getCookie()->isSecure(),
//$this->getCookie()->getHttponly()
);

;-)