I have a site which has users in two categories - A and B.
I have a CSV file of usernames, email addresses and new passwords for all users in Category A (category B isn't to be affected)
How can I import this CSV to change the passwords?
What I've tried:
Feeds Import - Errors out with "The website encountered an unexpected error. Please try again later." - no clues in Drupal.
User Import - I configure it to update user passwords, but it creates new users with the same usernames as existing ones, suffixed with '2'.
There are over 500 usernames to be updated, so cut-n-paste isn't going to be an option.
All ideas accepted!
Based on your description, it sounds like you might be missing the UID for each user account. Your feed import should be an update records with existing UID as opposed to the standard feed import behavior of creating new data records (in this case, it may be trying to create new user accounts rather than update existing ones- but since you can only have one account per email, it would fail to import on all the users in the list)
If the feeds import still bombs after adding the UID column and mapping the feed to update corresponding user data, it could be a result of the server just timing out. Recommend you check the server logs to see if it timed out or hit a memory limit.
Otherwise, you should be able to use the Feeds module to import your csv. Check out https://www.isovera.com/blog/using-feeds-module-bulk-import-drupal-7 for a general rundown of importing a csv with feeds.
Before importing, you'll also want to make sure the passwords are properly hashed. refer to https://www.drupal.org/node/1058316 which would put you on track to hash plain text with a simple php function.
Just an update on how I ended up doing this task;
I used the drush command upwd (update password)
drush upwd --password={newpassword} {existingusername}
I built the unique drush commands in a column on the spreadsheet, then pasted them into an SSH command line.
Extensible? No. Reusable? Not very. Effective? Yes. And time/cost-effective.
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 have followed most of the tutorials on the luminusweb.net website, setting up a database system using the +h2 new app. What I have currently mirrors the guestbook setup like the tutorial shows. I am now wondering how I can access specific entries into the migrations up table. More specifically, I am trying to have restricted access to webpages (a login system) based on the entries inside of the table.
The migration file purpose is to create the tables in your database. To access those tables you will have to write queries in the file located here: your_project > resources > sql > queries.sql
Here you should write queries, there are a few examples on the Luminus website. When you see parameters with semicolumns, it means that you have to pass a map with those parameters when you call these queries in your program. Ex: if you have this query:
-- name: accounts_for_user
-- retrieve all accounts a user has access to and the associated rights
SELECT account_name, admin
FROM accounts_users
WHERE email = :email;
The call:
(db/accounts_for_user {:email "laurent#test.com"})
will return a lazy sequence like this:
[{"account_name":"account1","admin":false},
{"account_name":"account2","admin":true},
{"account_name":"account2","admin":true}]
Then if you want to restrict the access to a specific page based on what's in your database, there are a few options. The Buddy auth library offers a few options, the easiest to use is the session one. First, when a user enters a correct password, you inject their identifier in :session :identity in any request. For instance
(-> (redirect "/accounts-list")
(assoc :session {:identity "user#test.com"}))
The identity parameter will be in every request until the session dies (30 minutes by default) or you overwrite it. In your pages, you can test buddy.auth/authenticated? on the requests, and redirect to an error page or whatever you like if it returns false. I am currently writing a tutorial for webapps using Luminus, I'll update this answer when it's available.
I would like to know how i could create a log in program with some method of data storage that stores the login information of registered users and then accesses it when users type in their log in details for verification?
I do know how to create a basic login program with labels,buttons and edit boxes but do not know how to store information about the users registered and then access this again.
The fact that you have included the 'database' tag in your question implies that you already know what the solution is - a database. If your program already uses a database, add a table for users which includes their real name, their user name and their encoded password. Your login screen will have to query this table to check whether the user is valid. Make sure that you use parameters to the query; this way you avoid the possibility of sql injection (query 'little bobby tables').
Using PHP, does anyone know how to make it so that when someone registers on a website (and therefore enters data into a database), a folder with a default php file is created on the web root/server???
This is not a good design. Rather, you should have your PHP files look at the session to find the logged in user's id, and query the necessary data about that user id. You don't need a file for each user. You can make your table auto-increment a user id.