I disagree with you russian-dima, stored passwords in plain text does NOT mean that they’re insecure, you can set the collection access only for Admins, and check the passwords on the Backend , and only return approved or disapproved status to the Frontend , pretty mush how Wix handles the login process, except that the passwords aren’t stored in a collection that you can access, but a collection that they - might - have access to.
Good luck Peter
And remember that you can always hire a developer to build it for you.
When the DEMOlist is ready, you have just to push the green button, to fullfil the registration of all USERS which are in the list. The result can be seen in the “Private-Member-Collection” -table. All users should be in the “Private-Members-Database”.
Attention! After running this procedure, you will just see the first registered user in the table, because you will be logged-in as this first user, right now.
To see the whole “Private-Member-Collection” -you have to log-in as site-owner!
Of course you may now say… —> ok and what is now the advantage of this, i can also register the users the same way of my own, one by another.
The advantage is, that you now are able to import a CSV-file to one of your custom-created-DATABASE (in this case —> “Member-Data-List” look at the first table) and then just press the green button! And that’s it No? I am wrong?
The result should be like this one from this example…
Well done But with one major flaw, this process is NOT secure, and it’s vulnerable to phishing attacks, this kind of sensitive processing should always be done on the Backend .
Yes i know, i just did not want to mention it here, this could give some bad ideas .
And yes, i mentioned it in my posts, that this way is not the secure one
Unfortunately i did not worked with “back-end” yet, but i will do it in future (sure).
Hey Ahmad, thanks for good info.
But let me bring it to the end to be sure if i think right.
You say they (ADMINS) can store the PASSWORDS in another database and can protect this database not to be seen by a foreign-user (of course i agree), but the admin himself can see the PW right? Is this not a lack of security, isn’t it? There is already a person who knows the PW, or not?
I was talking about security breaches from the outside, of course admins can still see it.
To overcome this issue, I’ve built a mechanism to encrypt passwords before they’re saved in the collection, the encryption-decryption process is handled by an external API on other websites, the main goal for this mechanism is to make a one-password for multiple websites that are owned by the same vendor, and store the passwords locally on each website but encrypted, so the admins of these websites can’t see what the password is, and these encrypted-passwords can’t be used to login by themselves, the login process is handled on an external API on the main website, and there’s also a mechanism to sync the password automatically on all the websites when it’s changed on any of them.
The reason why I’m telling about this is that there’s always a way to secure the process.
Peter we’re sorry, I’m sure you’re annoyed by the notifications that are off the topic, hope that our discussion didn’t bother you. We’ll move the discussion to a new post.
So another option is build the web page and set it up like my own chapter page with members area, and then get all 27 secretory of each chapter to add each of their own chapter members one by one (make each chapter sec a admin moderator) and then i dont have to add all the active members and the secs can add other content to the national page on behalf of their respective chapters. Its just i think WIX is a bit behind the times and not listening to users, Some basic stuff they are really missing and it should be already in the wix web page building tools. another thing, ie. a serch button for a datapase (collection) is this not an option ATM ?
The simplest and easiest way to solve your problem making an email verification process and when they verify their email register them as members with the emails and passwords that are stored, this way they become new members without creating new passwords.
Then you set a jobScheduler to delete the already registered members data from the collection that you’ve imported, or at least clear their passwords.
There might be other ways, but I think this is the easiest one.
But with one major flaw, this process is NOT secure, and it’s vulnerable to phishing attacks, this kind of sensitive processing should always be done on the Backend .
.