Does WebSignup have e-mail verification?

To create admin autorisation on one o my sites i let the users sign up using a document/user group called verifying, i aloud them to view some of the basic pages but each had a notice telling them they wouldn’t be able to go further untill thier account was aproved to then aprove thier accounts i simply changed thier user group to Verified and from there they could access further files...

Im currently trying to work on a paypal IPN intergration snipit so that i can charge a premium membership for my sisters site at http://www.jenniemay.co.uk this takes the whole thing further of upgrading thier account to view further pages and have access to more pages but instead of the current system that i have to check for paypal payments and if there are any track them to the member and upgrade manualy im hoping that the system will upgrade it its self using IPN.

Please Tell me if anyone thinks this will/wont cause any problems.

Quote from: vbrilon at Feb 28, 2006, 12:03 AM

Have a weekly (or whatever) process to check for for any accounts that are older than a week (or whatever time you want) and are still bogus -- those are the ones you want to purge.

Is there some timer functionality in modx to do this? I mean that can this be done somehow with just modx and php? Or would it have to be some automated-shell-script-thingy at the server?

Quote from: doze at Mar 03, 2006, 05:14 PM

Quote from: vbrilon at Feb 28, 2006, 12:03 AM

Have a weekly (or whatever) process to check for for any accounts that are older than a week (or whatever time you want) and are still bogus -- those are the ones you want to purge.

Is there some timer functionality in modx to do this? I mean that can this be done somehow with just modx and php? Or would it have to be some automated-shell-script-thingy at the server?

You need to use crontab on linux, or you can use a crontab manipulation. Basically what it does, the script will be called on every page request, and it will run the crontab process, some kind like weekly based schedule or daily, and if none to be run, then the script quit and let your original script run normally.

I think it will be a good addition as an addon for MODx. You can create a plugin to handle that.

Quote from: doze at Mar 03, 2006, 05:14 PM

Quote from: vbrilon at Feb 28, 2006, 12:03 AM

Have a weekly (or whatever) process to check for for any accounts that are older than a week (or whatever time you want) and are still bogus -- those are the ones you want to purge.

Is there some timer functionality in modx to do this? I mean that can this be done somehow with just modx and php? Or would it have to be some automated-shell-script-thingy at the server?

There’s nothing built into modx to handle this since modx is not a long-running process, but instead only runs during the browser request/response cycle.

You could fake this though by setting up a "last checked" database field, update it when you check, and then just look at that field every request, and only when a certain amount of time has passed since the last check (X number of days or whatever), then run the update code, modify the date field, repeat ad nauseum.

Ok.. I think I got it now I’m thinking that I should make it like this: When someone uses WebSingup to "request" an account, the account is made, set to be blocked and have a "waiting for verification" usergroup that has no special rights (and the verification email is sent to the given address). Then there would be a document with a verification snippet, that gets the users id from querystring and sets the corresponding user unblocked if it is found in the "waiting for verification" usergroup and then sets it to the correct usergroup. The usergroup thing is there to make sure, that the verification document can’t be "exploited" to unblock just any user. Then there would have to be a snippet that gets run on every page request What goes through all users in "waiting for verification" usergroup and checks if the lastlogin date is older than a week. If it is, then delete the user.

Would this be ok? And another question. What is the value of "lastlogin" when the user has just been created and haven’t still logged in? And if the user is blocked and he/she still tries to login, will the lastlogin field change? Or will it change only with a successful login? (later maybe obvious choice, but still thought to ask )

And a third question: it sounds pretty "heavy" to have a script that checks the users on every page load. What do you think, will it cost much in page rendering times?

And by the way, thanks for the great replys and awesome activity! I’m still using Etomite my self, but I’m very seriously thinking that I should move to MODx as soon as possible. It seems that this community is more active and you have tons of very talented programmers here. There are also a lot of ready made snippets/modules for MODx that would come handy for me already on my current sites (some that I have been currently developing my self for eto). I’m pretty sure I’ll start to develop my next site (more portal like) with modx now. Just looked at DocMan by sottwell and drooled. That snippet alone will save me a lot time!

It’s all do able.

To answer some of your questions.
1. Yes it’s do able, but my suggestion will be to use plugin instead of snippet to check the current user data on every page request, with this, you don’t have to include the snippet on every pages that you have, instead you can just set the plugin to listen to onwebpageinit event, than i will run everytime somebody requested a page.
2. I believe the last login date will be the date when the user succesfully login to the system. I’m not 100% sure about this though.
3. Yes it will cause too much overhead to check user database table on every page request. My suggestion will be to create a simple log file. This will be a long answer, I will explain it in the next paragraph.

Basically you will have 1 plain text file as a log file. This file will keep the last time your run the script to clean user database. Everytime you run a user database cleaning script, you need to write the date and time on this log file. SO now on every page request, all you need is to compare the current date with the last date that you run user database cleaning script, if it’s over 1 week, than you run the script and write a log again at the begining of this file. I’m pretty sure it will be a lot more efficient, compare to hitting database back and forth on every page request.

A more so[hiticated approach will be to use config database table to store your last cleaning time. Basically it will be stored in array $modx->config[’var_db_name’]. Just don’t forget to clean up the cache everytime you write a data to the config database table.

Regards,

Quote from: Djamoer at Mar 03, 2006, 09:04 PM

Yes it’s do able, but my suggestion will be to use plugin instead of snippet to check the current user data on every page request, with this, you don’t have to include the snippet on every pages that you have, instead you can just set the plugin to listen to onwebpageinit event, than i will run everytime somebody requested a page.

Sounds much better.. As I’m coming from Etomite, I didn’t know about the plugins yet.. but I’m in the works of going through the modx documentation!

Quote from: Djamoer at Mar 03, 2006, 09:04 PM

Yes it will cause too much overhead to check user database table on every page request. My suggestion will be to create a simple log file.....SO now on every page request, all you need is to compare the current date with the last date that you run user database cleaning script, if it’s over 1 week, than you run the script and write a log again at the begining of this file.

Yes, this will be much better. I think I will also check all registered webusers in the cleaning script, so that if a user have not logged in for a long time, it would send a email remainder to the user that he should login to the site asap to keep the account, and if they don’t do it in a certain time span, they get deleted..

Quote from: Djamoer at Mar 03, 2006, 09:04 PM

Basically you will have 1 plain text file as a log file. This file will keep the last time your run the script to clean user database. Everytime you run a user database cleaning script, you need to write the date and time on this log file. SO now on every page request, all you need is to compare the current date with the last date that you run user database cleaning script, if it’s over 1 week, than you run the script and write a log again at the begining of this file. I’m pretty sure it will be a lot more efficient, compare to hitting database back and forth on every page request.

How do you figure that reading/writing a text file is easier than hitting the DB? I am not saying it’s not, just curious why you think it is

Quote from: Djamoer at Mar 03, 2006, 09:04 PM

A more so[hiticated approach will be to use config database table to store your last cleaning time. Basically it will be stored in array $modx->config[’var_db_name’]. Just don’t forget to clean up the cache everytime you write a data to the config database table.

That’s what I was talking about in my original post. I think this is a much better approach.

Quote from: vbrilon at Mar 04, 2006, 11:02 AM

That’s what I was talking about in my original post. I think this is a much better approach.

lol, sorry for missunderstanding it. I did post that before I left my office, so I’m in a hurry in doing that. Btw, hitting database will be so much better when it comes to reading a large chunk of data I beleve, and that’s why I propose to use config database, considering it will be loaded no matter what, and it also being cached as a cache file, which later it’s going to be run as PHP script, instead of reading the data and parse the data as a text file.

I have done this, but it was a while ago, so i can’t remember the exact details. It is similar to Kunals, but goes a bit further.

I added an "authenticated" and a "date" field to the database.

1. The user signs up with a username, an email address, and a "terms & conditions" checkbox. Both the username and email address are checked for well formedness and uniqueness.

2. An email containing a clickable link is sent with a generated password and an authentication code. The "authenticated" database field is set to ’pending’ and the date to the current date. The user cannot login at this stage, even using the generated password. A message is displayed explaining about the email and what to do.

3. The user clicks on the link and is taken to an activation page where they have to enter their username, password, activation code, and a captcha.

4. When the correct details have been entered the user is logged in, taken to a "change details" page to change their password and enter other optional details. The "authenticated" flag in the database is set to ’authenticated’ and they are upgraded to registered user status.

I intend to use a daily cron task to remove any outstanding "pending" users after a week, but I have not implemented this yet. Also the "verify details" page should be made inacessible once the user has completed registration.

I was going to offer this up once I got round to refining the details but I have (temporarily, I hope) stopped working on this site. If anyone is interested, though, they can have what I’ve got so far.

If you want to see it in action it’s at http://webimageconsultants.co.uk/modx2/marblearch.