Sometime ago I moved a shop on PrestasShop 1.5 from one server to another. Today I tried to log in to my account, but it says that employee doesn't exist or password is incorrect.
I thought I must have changed the password than - so I used forgotten password option, but it told me that this user doen't exist...
So I logged in with my other account (without superadmin rights) to see if maybe the e-mail was wrong. But what I saw was the strangest thing: there were two employees listed: superadmin and testing account, but in the e-mail field of the superadmin account there was the value of actual database name instead of valid e-mail. I couldn't change that from admin panel because this user didn't have the rights to edit superadmin account.
But that's not all. In testing account edit form there was superadmin's e-mail inserted instead of the one i actually logged in with...
That's messed up!
So I went to my phpmyadmin to check what's going on. But there everything seems to be ok. E-mail addresses are correct. I even changed the superadmin password using this tutorial: http://paikialog.wordpress.com/2010/11/08/prestashop-generate-and-change-cookie-key/
Nothing works. But it's even worse now - testing account stopped working also. Changing it's password doesn't work. I cannot log in to admin panel at all.
What's wrong?
You may try changing the email id of the user from phpmyadmin and try forget password option from admin.
Related
I have a user who is attempting to sign into their account on our domain, and whenever they do so they are presented with the message 'The referenced account is currently locked out and may not be logged on to'.
However, when I view their profile in AD, I can see that their profile is unlocked and there is no unlocking to do. Their password has also not expired and is still valid, but they have possibly entered their password wrong a few times - but not enough to lock the profile.
I don't think their computer is attempting to login to a local user profile and I tried to sign them on with domain\username and that still did not work. However, after I reset their password (through AD) and had them sign in with that password, they were able to sign in again.
Any clue why this might be?
Checked in AD if the user was locked, which they weren't. I expected it to be locked.
Checked when their password was made/when it expires, and it was valid. After it not being locked, this is the next likely option.
Checked that they weren't trying to sign in with a local account as opposed to a domain account, which they weren't. Was curious to see if this was the issue, but seemed unlikely.
Reset their password and afterwards they were able to sign in. Expected this to work based on previous accounts of this happening, but do not know why the issue occurs in the first place.
I'm always told I write "biblical length" emails, but hey, I'm trying to characterize the situation the best I can for ya.
I created my sandbox. The Business account was auto created. I created a Personal account.
I successfully paid to the Business account with the Personal account with my Buy-now setup and my IPN works correctly (after changing the fsockopen to use SSL, changing \n to \r\n, etc). No problems with the "front side" of all the account business.
Part of the "Backend" needs are to transfer some of the Business account money to another account after 3 days (my Business account is a middle-man).
I switched from Firefox to Chrome. I had done all the account setups in FF, so I didn't want to try to have two logins running under one browser, sandbox or not.
I tried to login as the Business account and it failed and ended up in the "make sure your email and password are correct" loop.
I tried to login with the Personal account (the one which successfully paid into the Business account via the application). Same error.
I tried changing the password on the original Business account, flushed cache/cookies, still cannot login. There should not be any password errors because the accounts have the same password!!! I cannot use the "forgot my password" logic to see what it thinks my password is, because the email is fake and it won't get sent anywhere.
I created a second Business account, and I tried to login and it logged in correctly and showed my balance correctly. I logged out and tried the other two accounts, but the only one that ever logs in is the second Business account.
I could solve the issue by changing the target of my front side Business transfers to the second Business account, because I know I can log into that one, but that would be condoning the fact that the system is flawed, and I'd rather push this issue to find out what is wrong.
I switched to IE (argh!)
I tried the original Business account. Failed.
I tried the Personal account. WORKED!!!!
I tried the second Business account. WORKED !!!! and I didn't have to flush cache or cookies. It still won't allow the original Business account, even with IE.
I don't have time to wait 2 hours (in case it's the "too many times" problem). There was nothing wrong with the account/passwords in the first place, and since I'd never tried logging in with any of the accounts directly before, there was no history of failed transactions.
I switched to Safari.
Once again, original Business account fails, but the other two accounts work correctly!!!!
I switched back to Chrome.
Again, original Business account fails, but the other two accounts work correctly!!!!
So, it appears once I have successfully used an account, it will work regardless of the browser, cookies or cache. IE, Chrome and Safari all work with two accounts but none of them work with the original Business account.
Finally, I tried changing the password again for the original Business account. Still doesn't work.
My suggestion is to add a button to the "test accounts" setup page, "LOGIN AS" and just let us automatically login as that user (after first successfully logging into the sandbox with our validated paypal account) and bypass the whole password thing, if you aren't going to get it to work.
2 things.
1) Apparently I should have used "Paypal" in the initial title, I had assumed the tool was already in a Paypal specific sub-forum (wrong) and I have added the word to the title. Sorry for the confusion.
2) To answer my own question ...
I tried to login to the orig. Business account first thing this morning and it worked. I tried to do a transfer and it wanted login validation and failed again and again. If your results do not prove out your premise, then there is probably something wrong with your original premise in the first place, right? So I went back to my original course of action, which was to switch from Firefox to Chrome when I went to login (because I didn't think someone would have you logging in as two different users within the same window). WRONG AGAIN. I logged in as Developer, but instead of going to a different window or browser, I logged in a second time by using the "Enter Sandbox" link, and was able to succesfully login with each of the accounts.
You have to be logged in as a developer in the top portion of the sandbox interface window, while you login as one of the Business or Personal accounts in the lower half of the test window or else it doesn't work. If that is the case, and I am now doing it as it was designed, then that would explain why it was failing when trying to login when using Chrome/Safari/IE, since I wasn't logged in as the Developer account in those browsers. Why it did occasionally PASS is crazy. Software should be consistent, if anything.
Is it safe to login user automatically after registration?
User fills registration form, some info message is sent to his mailbox, and what then:
User redirected to login page asking him for credentials;
OR
User auto-logins as his newly created user?
I feel something not safe enough in auto-login, but can't figure it out!
If they just filled out the login information and you're not concerned about confirming that the email address is legit, then there shouldn't be a problem just logging them in directly.
However, you open yourself up to people/bots creating bogus accounts (at least ones without legitimate email addresses). If you're concerned about that (not sure it this is a public facing app or intranet, etc) then you should at least verify the email address by sending a link with a guid or some identifier that you can track back. Then you can let them log-in once they are confirmed.
You could also just tie it to their StackExchange/Facebook/OpenID/etc account and not make users fill out yet another form and worry about maintaining all that information.
They should need to login. Also the confirmation email should not contain their password. If they managed to give you the wrong email address and you automatically log them in then someone else has access to their account now. This holds even if you have them type their email address twice. Sometimes people make the same mistake twice in a row.
It can be safe to auto login if the user already has an active session as the correct user during the confirmation step. If you think about it, it's not actually "automatically logging them in" but simply keeping them logged in as they was before.
User registers
Keep a session identifying the user
User navigates to the confirmation page (linked in email)
You activate the account
During all that time, there was no reason to end the session. The only reason you would want to end the session (or not create one in the first place) is if your permissions are not properly set to allow someone to login / create a session without giving them higher privileges than an unregistered user.
Now, be sure not to automatically identify the user as X simply because this person navigated to the confirmation page of user X. If a user navigates to this page but does not already have a session open, do not assume he knows the password.
I have SugarCRM running and able to log in and out using the super admin account. I created a new user with type Regular User and defined it password because I unchecked the auto generation of password.
Even if I change the password through the database I cannot log in. But, if I changed the the type to Administrator that user can now login. Why is that? I want it to be a Regular User only.
Regards,
Ronel
In version 6.5.x I have found that there is a problem with password rules. Perhaps this is the case. Go to config.php and look at passwordsetting array. There is a minpwdlenght and a oneupper. Change 'oneuppper' to 'false' and match minpwdlenght to the lenght you want.
This solved my issue.
I'm trying to decide what to put in a dialog box that tells the user their login doesn't work, there is probably a duplicate. The system uses email addresses as user names, then requires a password.
Right now, I'm using "Email Login" but that just sounds stupid.
For instance:
1) Application Starts, recognizes that it has never been run.
2) Prompts user to create a new account.
3) User puts in an email address and password to use as their new credentials.
4) Well, looks like they've already got an account probably. (This is the most likely case the account creation would fail but I'm using an API and I can't be 100% this is why it failed)
5) I ask them to try again with a different "email login".
Could not create account - try a different email login !
After I check with the API provider, I'll probably try to detect that it is in fact a duplicate account and ask them to try to authenticate that account with a password.
Tell them explicitly that their email address is already in use.
Call it an email address, thats what the user thinks of it as. The fact that you are using it as an id or a database primary key or a hash key is irrelevant to them.
Perhaps: An account already exists for this email address. If you already have an account but forgot your password, please click [here], otherwise please choose a different email address.
I agree with mgb that the best choice is to explain the problem and how the user should proceed.
I would just call it what it is: an email address. I wouldn't suggest that they try a different one, though. Just ask them if they already have an account and, if so, to try logging in with the address/password. If they continue to have problems, give them a contact that they can use to get help.
There is a distinction between the process of authenticating ie logging-on/login and the options a user can use ie. username, userid or email address.
As more websites are having allowing users to login with email address it doesn't pay to be ambiguous, do your users a favour and label the field 'Email Address:'. This way your users are clear on what is expected in the field. If you label it "login:" or something else vague they'll be subtly fooled into thinking they might have created a username when creating their account and try all the usernames they usually use before trying email addresses.