OK, Sorry for my newbie-ism. I only started using it this week. I've been tasked with testing and performing an upgrade on an umbraco 4.03 site to 4.7. I think I know roughly what I'm doing. I had a little trouble with schema table ownership but solved that all by myself without any help from my mummy :-)
I have however come across a strange thing. I moved the db and eventually got the site homepage working on my machine with a few broken macros.
The problem is that I couldn't log into the admin area at http://localhost:<portnumber>/umbraco/ the username and password didn't work. I went to have a look in the db. hmmm. It's hashed.
So I took the strange bundle of heiroglyphics that had been entered into the box and logged in with that. It worked.
The strange thing is that the web config doesn't contain a hashed keyword. passwordFormat="Hashed". Looking a the membership providers I see three multiple providers and the default set to the custom provider which has presumably been written by the guys at umbraco.
Strangely I tried going into the admin area and changing the password. Managed to change one of the passwords but I can no longer see anything other than the admin password in the umbraco user table.
I then go back to the admin area and all the users are still there even though changing the password removed the users. Questions:
Does the xml for the admin area cache somewhere?
Why are the passwords no longer hashed when I move the database?
OK, Now I feel a bit stupid. The users didn't get deleted (I was looking at the wrong db, it's been a tough introduction and I have the plague at the moment, OK) anyway the trouble is that the passwords are now in plain text and I changed the user's password as a test and it is also still in plain text again.
How is this working on production but not when I move the db and site locally? Where was the hashcode stashed on 4.03? Why does moving the db or site do this?
Which is it? moving the db or moving the site? Is it a machine key thing or something?
Could you maybe post the web config settings you have for the different Membership Providers? I guess for some reason the current web config saves the password in plain text instead of hashed, and seeing the actual settings might help find the problem.
Also, you might indeed look for a hashing key in the web.config from your production server, and copy it over to your test server.
I've just solved it and now I feel rediculous. Basically I'd been a Very silly man and had taken the database from where the other dev told me it was. In reality the database wasn't where I was told. I only started 2 weeks ago so I'm not too sure where the pots and pans are yet and I'm a wee bit of a newb.
I was looking at a version of the db which had hashed passwords and was clearly overwriting them with unhashed passwords when I changed them. Basically I think that the db had once had encrypted passwords then had it turned off.
I'm now going to turn it back on after wasting a few hours trying to work out why nothing was working.The moral TRUST NOBODY and double check the querystring before overwriting it
password hash key not working when database moved
OK,
Sorry for my newbie-ism. I only started using it this week. I've been tasked with testing and performing an upgrade on an umbraco 4.03 site to 4.7. I think I know roughly what I'm doing. I had a little trouble with schema table ownership but solved that all by myself without any help from my mummy :-)
I have however come across a strange thing. I moved the db and eventually got the site homepage working on my machine with a few broken macros.
The problem is that I couldn't log into the admin area at http://localhost:<portnumber>/umbraco/ the username and password didn't work. I went to have a look in the db. hmmm. It's hashed.
So I took the strange bundle of heiroglyphics that had been entered into the box and logged in with that. It worked.
The strange thing is that the web config doesn't contain a hashed keyword. passwordFormat="Hashed". Looking a the membership providers I see three multiple providers and the default set to the custom provider which has presumably been written by the guys at umbraco.
Strangely I tried going into the admin area and changing the password. Managed to change one of the passwords but I can no longer see anything other than the admin password in the umbraco user table.
I then go back to the admin area and all the users are still there even though changing the password removed the users. Questions:
OK,
Now I feel a bit stupid. The users didn't get deleted (I was looking at the wrong db, it's been a tough introduction and I have the plague at the moment, OK) anyway the trouble is that the passwords are now in plain text and I changed the user's password as a test and it is also still in plain text again.
How is this working on production but not when I move the db and site locally? Where was the hashcode stashed on 4.03? Why does moving the db or site do this?
Which is it? moving the db or moving the site? Is it a machine key thing or something?
Stranger still.....
Looking into the web config and adding the additional hashed value and changing a password still stores the password in clear text
Hi,
Could you maybe post the web config settings you have for the different Membership Providers? I guess for some reason the current web config saves the password in plain text instead of hashed, and seeing the actual settings might help find the problem.
Also, you might indeed look for a hashing key in the web.config from your production server, and copy it over to your test server.
Cheers,
Michael.
Thanks Michael,
I've just solved it and now I feel rediculous. Basically I'd been a Very silly man and had taken the database from where the other dev told me it was. In reality the database wasn't where I was told. I only started 2 weeks ago so I'm not too sure where the pots and pans are yet and I'm a wee bit of a newb.
I was looking at a version of the db which had hashed passwords and was clearly overwriting them with unhashed passwords when I changed them. Basically I think that the db had once had encrypted passwords then had it turned off.
I'm now going to turn it back on after wasting a few hours trying to work out why nothing was working.The moral TRUST NOBODY and double check the querystring before overwriting it
:-) The important thing is that you got it sorted out :-)
Have a nice week-end!
Cheers,
Michael.
is working on a reply...