I have a CI project and want to migrate its database to the Laravel's one.
The only problem is that they have different ways of hashing user passwords and so I cannot find a way to move them from one database to another.
I have already googled for the answer but nobody I found speaks about migrating passwords.
Thanks in advance.
I have no experience with CodeIgniter and don't know how it does password hashing, but here's how I would approach the problem.
To make something clear: You can only "convert" the password to a Laravel hash if you have the actual password (in plain text). As you don't store the plain password you only have it at the moment the user logs in our enters the password somewhere.
Therefore you have to realize that this migration isn't done in a few hours. It will take some time for all your users to enter their passwords.
So what I'm getting at is you should add a field to your users table for the CodeIgniter password. Let's call it ci_password. (Or probably you just have to rename the old password column to this and create a new one for the Laravel password).
Now every time a user logs in, you first check if a Laravel password is stored in the database and attempt a log in. If there is no Laravel hash stored, check with the ci_password. (For this you will have to make CodeIgniters hashing work inside your Laravel application. Sorry can't help you with that)
If the ci_password is valid use the password input from the user and generate the Laravel hash (using Hash::make('secret')). Store the new hash in the database and delete (set to NULL) the ci_password.
This way the passwords will be migrated one by one and you have to do nothing. And maybe, on one lucky day, all old hashes will be migrated and you can remove this logic and the column in the database.
Related
This situation might not happen much, but I would rather be safe than sorry. I'm currently trying to make a sign in/sign up system with flutter MongoDB using API call to my database. On the signup screen, I am making checks to see if the data placed into the password and username text fields already exists within the database. In other words, if an account with those credentials already exists then I ask the user to try again, but if there isn't one then I allow for the user to go to the EULA and submit page.
The problem here is that I feel like that two or more users can do the same check at the same time, and will get the same result because, while their information might match, there isn't an instance of an account with those credentials uploaded to the database for the system to tell them to stop before they go to the submit page. And if they submit the data they wrote on their phones to the database at the same time, a situation is made where we have multiple instances of the same kind of account existing in the database.
I know that keys exist and can help in making each account unique from each other, but, in this situation, I am not sure on how to handle or prevent the concurrent uploading of similar or identical data from local devices to the same server. Are calls to my server and MongoDB asynchornous? Is this something that I need to worry about at all?
TL;DR: If you use a unique index on the username field, then it will raise an error on attempting to create a duplicate, and you can forward this to the user's sign up page and let them change their name.
The long answer:
This is more of a UX problem than a DB problem.
If I understand correctly, the user enters a username & password, then reads the EULA before the account is created.
I would disagree with this - you should make the account once they submit their name, and update it with a Boolean for eulaAccepted so that if this process fails (eg. bad connection) they can come back and accept it later.
You should do two sets of unique username validation:
When they type in the name, you can check for them and let them know the name is available. This still means someone else could take it before they hit save.
Once they hit save. Put a unique index on the username field. Then if a user tries saving a duplicate (even if submitted simultaneously, they will be processed sequentially) then it will raise an error. You can forward this onto the user, prompting them to try a different name.
Answering your other questions:
Are calls to my server and MongoDB asynchronous?
Yes, as they go over the network they are naturally asynchronous. But the saves inside the Database itself are sequential and atomic. MongoDB is ACID compliant. have a read through what it means, and what changed in version 4
Is this something that I need to worry about at all?
Yes, it's good to keep an eye on this sort problems. If you don't consider it now, you will have a nasty bug on your hand later.
In a self-hosted C1-CMS (formerly Composite C1), how can I reset or recover the password? Can the password be viewed or reset somewhere on the server?
(Composite C1 4.3, Build 4.3.5555.25838)
If you are using the default XML data store, the users and encrypted passwords are stored in: /App_Data/Composite/DataStores/Composite.Data.Types.IUser.xml
If you have another user with a password you know, you can replace the encrypted password string on the account you are trying to access, with the encrypted password from the account you know. Then login and change the password.
I received this answer from the official Orckestra support team (very helpful, although I am not a paying customer, thumbs up!):
You cannot recover the password, but if you have access to the files (or SQL Database, if you migrated data to SQL) you can reset the password:
This should work for sites running on XML data store (default):
Edit the file ~/App_Data/Composite/DataStores/Composite.Data.Types.IUser.xml
Locate the xml element for the user you want to reset the password for
Change the following two attributes to the shown values:
EncryptedPassword="hsfIeqkVA5yoMIwzYIx4fWny5GjwNwiM3wA5K+9qCug="
PasswordHashSalt="/zgEhlwBe6Vl0HHqMFPxafrtwqlRIGVS"
Save the file.
If your site is on SQL, locate the table Composite_Data_Types_IUser_Published and put the above shown values into the corresponding columns (EncryptedPassword and PasswordHashSalt).
You should now be able to log in using the password "123456" for the user you changed above. Once in the CMS Console, you can set a new password using the top Tools menu (top right user menu n V5 and later).
I recently had a scenario where neither of the suggested methods would work for me. I was able to remedy this by creating a c1 instance locally, creating a user with the same username and the desired password, and then overwriting the password salt and hash from the local site to the one you're locked out of.
I am developing an application (web\mobile). The user have to register the account using a form on the application (it contains some data as username and password).
These data have to be stored in a database table, these data travel on Internet so I think that it is not a good idea that the password is in clear.
I think that the client have to encrypt the password in some ways and that this crypted password have to be stored in the DB.
What could be a decent workflow for this task?
A common way to do this is to send the password as clear text via a HTTPS connection. HTTPS is a must when anything confidential is sent through internet, not only for passwords.
On the server, calculate a hash. There are many algorithms for this, some more secure than others. A hash function works only for one direction: the password cannot be derived from the hash. Store that hash to the database instead of the password. When a User logs in, calculate a hash from that password, and compare it to the hash stored to the database.
Currently I am working on rebuilding an existing website, the old site was written in CakePHP but the new one is in Laravel.
The old users will have to be able to login with the same password as they used on the old site, but those passwords were hashed in CakePHP.
My question is:
Is there a method which would enable me use the CakePHP way of
passwordhashing in Laravel?
I have tried looking for a package that could accomplish this, but to no avail.
I had a similar issue with a migration from a Drupal site. So it should be applicable here, I'll use CakePHP from now on instead of Drupal. I don't know if you are using a package like Sentry to handle the User accounts, or if it is something homegrown.
What I ended up doing was adding a second password field (cakephp_password) to my users table which contained the imported hashed passwords.
Then during the login process, I checked if the cakephp_password field was empty or not. If it was I passed the password typed by the user through the CakePHP hash function which I added to my Class that handled the logins. I then compared the hash from the CakePHP function with the hash in cakephp_password. If the hashes matched I passed the users password through the hashing function of my laravel User management class (Sentry in my case) and added the calculated hash to the password field of the user and deleted the hash in the cakephp_password field.
Now I could just call the login process normally as for any user.
While developing my app, I suddenly can't login using Auth anymore, according to Cake, the password or username is not correct.
When I track the query, the password (hashed) that Cake is looking for is not the one that the user has. I matched the query password to the User table in MAMP.
What can be the reason of this sudden error? What can Cake make looking for another password that not exists in the user table.
all error logs are clear
I can register a user without any issue
I use everything the standard Cake way (Auth, register process etc)
Many thanks!
well, most likely, you changed the salt value in core.php or hash mehod, or both. That's the only 2 reasons the hash is different for the same password.