Automatically create an account record from information in a received email

Hi Jerry, 

What about including a link in the email that will go to the create a new record page for your website membership accounts section, and fills out the fields with the details of the user. Then the admin just has to check the details are correct and press save.

For example, if you had a section called members, and you want to create a new record, and fill the field username with the value test and the field email with test@example.com, the following link would work:

http://test.net/cmsb/admin.php?menu=members&action=add&username=test&email=test%40example.com

Here is a breakdown of each variable in the url:

menu=members - Tells the CMS to go to the members section

action=add - Tells the CMS to create a new record.

username=test - Set the username value to test.

email= test%40example.com - Set the email field to test@example.com (%40 is the url encoded @ charecter).

So you can add the data required for each field in the url, and it will appear in the appropriate field when the link is clicked. 

Let me know if you have any questions. 

Cheers,

Greg

Hi Greg,

Good to hear from you (and so quickly too...)

What started this quest, is the assumption that allowing an unknown person to fill out a web form and directly create a record in a database is a potentially big security breach.

I guess I don't quite understand your suggestion to "include a link in the email " part, without the sender being able to see (and potentially hack) the code, and have no idea how to implement the automatic functionality in steps 3, 4 or the "automatically pulled" part of 5 below.

Here's a hopefully clearer outline of the process.

1) A number of prospective members submit a sign up form on the web site requesting to listed in a free on-line "services available" directory.

2) Each submission sends an email to the admin with the form results.(no database records are created as yet)

3) At intervals, the admin manually culls through the emails, decides which ones are valid and  deletes the bogus ones

4) (At this point the information in the valid emails need to somehow be made  accessible to CMSB)

5) The appropriate  information is automatically pulled from the new, valid emails, and account records are created for each with a generic password and an approved box checked..

6) The emailOnApproved plugin would send an email to those accepted members with their log in information.

7) Since all accepted members received he same generic password, they would be required to change their password on first login. (I've already done steps 6 and 7 before)

Thanks,

Jerry Kornbluth

.

Thanks for the insights Greg,

Your suggestions would certainly be a much simpler approach,

And I now get what you mean about the email (not the form). Don't know why it was so confusing at first. (Maybe it's time for a vacation...)

I certainly would hide the information until it was approved.approved (I've used the emaiOnApproved plugin for that before.)

I'm going to include recaptcha on the form as well.

Can you suggest any specific code for limiting the character input in say, a name field that should have only alphabetical characters and spaces?  I'll work through the rest based on that model.

I'd like to post the code and hope you can take a look at it before I take it live, just in case you can offer any additional suggestions, or find any errors.

Again, thanks for your help,

Jerry Kornbluth

Hey Jerry,

Can you suggest any specific code for limiting the character input in say, a name field that should have only alphabetical characters and spaces?  I'll work through the rest based on that model.

There are a lot of times when users need to enter non alphanumeric symbols into the name field, for example the names O'hare or BjÖrn. So it's best to filter out certain characters that defiantely can't be in names, you can use preg_match to check if the certain characters are present:

  if(preg_match("/[?!\"\[\]<>\(\).]/", $nameField)){
    echo "String matched";
  }else{
    echo 'no match found';
  }

So the above code checks if the characters ?, !, ", [, ], <, >, (, ), and . are present in $nameField variable. If they are, "String matched will be shown. There shouldn't be any names that have those characters in, so you could set an error at this point. 

Cheers,

Greg

Thanks Greg.

I'll post my finished code as soon as it's done

Jerry Kornbluth

Hi Greg,

I've attached the viewer that I created and hope you'll get a moment to look at it from a security perspective.

Also, the body of the email template that I'm using is below.

I can't seem to get the code in the link right to set the updatedDate field to the same time that the record was created, and hope you can offer some guidance.

Thank you,

Jerry Kornbluth.

#contact.firstName# #contact.lastName# has submitted a directory listing request for #practice#.

After you've determined that the request is from a valid DBT provider, AND THAT THE PROVIDER IS NOT ALREADY LISTED IN THE DIRECTORY, click on the link below to create a listing in the directory


NOTE: You'll have to un-hide their listing after they've updated their profile, or it will not be available in the directory..


http://dbtproviders.com/cmsAdmin/admin.php?menu=accounts&action=add&username=#contact.username#&email=#contact.email#&password=2xyz3&hidden=1&contact_first_name=#contact.firstName#&contact_last_name=#contact.lastName#&practice_name=#practice#&approved=1

Hey Jerry, 

Assuming you've validated the values entered by the user before it gets passed to the template (for example, by checking the email address is a valid structure), the code in the previous post looks good. 

I can't seem to get the code in the link right to set the updatedDate field to the same time that the record was created, and hope you can offer some guidance.

I've done some local testing, and if you don't pass any value in the URL for the createdDate or updatedDate, I think they should automatically be set to the current date and time.

Cheers,

Greg

Thanks Greg,

Silly me...

I actually meant the lastLoginDate field.

I guess I can use the updatedDate just as well, and since it does auto update,  it will work to determine if a mandatory profile update is required (if a provider has not updated their profile in 6 months).

I think I have all of the security bases covered as well.

Thanks again for all your help

Jerry Kornbluth