Looking to be able to take what is essentially an editorial page for a product and add a "request a quote" button. The user will then need to be prompted for basic info: name, email & phone.
Users can have guest status or be logged in. The client would simply like to be notified via email of the request.
The part I'd appreciate thoughts on, or a pre-boiled plugin for (clients site built in Wordpress, looked but can't see anything), is the best method for preventing the system from sending multiple emails if the user makes multiple quote requests within this session.
The solution should effectively allow the user to only enter their details once -> click as many "request quote" buttons as they like -> then after a certain amount of inactivity, email what they are after to the site owner.
This is the bit I'm stuck on, the best way of sending the users request, without the user actually hitting a 'checkout' type button. I'd really appreciate some thoughts on the best methods to achieve this, which keep it simple for the end user.
You save the details in some way I presume. For this answer I'm assuming it's a database, but it really doesn't matter.
When you save name, email and phone, also register a field for the send datetime. This "sendmail_at" is scanned by a process and the mail is send when the time is past.
Every time the user presses a quote button you update the time a bit to give the user time to browse more.
Example:
09:00: User requests the first quote. You ask for name/email/phone, and save this togehter with time 10:00 in the database
09:10 User browses, sees another thing he likes a quote for, and presses the button. The name/email/phone are still there, but the datetim is updated to 10:10 (and the extra quote id ofcourse)
etc
09:20 Last quote request
...
10:20 The mailer checks the database and sees that the 'send' time is past, so gathers all the quotes and sends the email.
For mailing: there are 3 parts to this:
Periodically calling your function
you function for checking if you should mail
a mailer function.
The first and last are probably ready made.
You can use your servers cron-system, or even wordpress's cron system (that on turn can use the servers cronsystem or it's own thing) for this.
You can probably find a plugin for wordpress, but I'm not sure how you would integrate it, or which one to choose. As you are going to fix point 2. anyway, you might just want to use something like PHPMailer.
For the middle part you need to write a script that isn't too complicated. You read your database/file/whatever of users, and filter all users that still have to receive a mail, but where the "senddate" is in the past. If you have those email adresses, you compose your mail, and use the function of the mailer I discussed above to actually send the mail.
Tying it all together:
Make a script that when given a user, it's email and the quotes, generates an email and sends it (with phpmailer for instance)
Make a second script that looks in your database for users to mail, and calls that script
Make a cronjob to call that second script every x minutes
....
profit!
Related
I'm receiving e-mail from my PHP/MySQL application with certain links.
When I click on a certain link (Approve, for example) within the e-mail, I want a message to be sent back to my Application, which it'd translate into a PHP script or SQL statement to update certain fields in the database.
In order to determine which fields to update, certain user and request related information may be included in the link (user name, category, amount, etc.) but I don't want this to be seen as plain text or discovered by someone looking into the e-mail details (can it be encrypted and then decrypted by the PHP application when user Clicks back in the e-mail)
I want this to happen only if I'm clicking on the original e-mail, not if it it's a forward or reply of the original
NOTE: My Application is not SSL enabled
What components/frameworks could be used to accomplish this and ensuring a perfectly secure solution (i.e. it could be PHP web services, details on what method to use to encrypt/decrypt, etc.)
None. There is no such thing as perfect security. And if you consider that a forward may copy each and every byte of the original, it will be tricky to react differently on links in forwarded messages.
what about letting your user simply reply to the email so your original text is returned. You could be relatively sure, that the user is the only person with access to this particular email- address and you could read your secret and encrypted message from the email-text.
You could let a cronjob run every x seconds, let the php- script read the message for a string like:
<SECRET_INGREDIENT>jkbgv7&%%((Nj3js8<SECRET_INGREDIENT_END>
So php looks for <SECRET_INGREDIENT> and for <SECRET_INGREDIENT_END> and decrypts the part between.
I have a registration form on my site. The form is sent to the server via AJAX and is then validated. Then it will output an address for the browser to be redirected to, if it was validated as valid information. PHP will then send a validation email to the email specified. The problem is that the sending of the email takes 10 seconds, and I don't want my users to wait for 10 seconds from they press Register to they get redirected...
Is there a way for PHP to tell the client the information was correctly validated and output the redirection URL, and continue sending the email without the client waiting?
It's called a background job.
To do this in the simplest way (note: not the best, but the simplest):
I'm assuming you're storing your registration details in some form of database. Add an extra column to flag that you need to send the validation email to this user.
In another script, check the database for any rows with this flag set, and send the email from there.
This second script will be triggered by a cronjob or similar, on a schedule of your choosing.
This way, users don't need to wait for that 10 seconds.
There are more efficient solutions that will cope better for larger scale sites, but I'm guessing that you don't yet need to know this, and that if I brought them into the equation it'd confuse matters. Look into Job Queues, if you want to know more.
Most of the examples I see on the web create user accounts in this sequence: user comes to the site, they choose a username and password and enter their email. A confirmation email to sent to this email and if they click the link, the account gets "verified". If they don't verify, the account gets deleted after a while.
I was told about another way: get the user to verify the email first, and when they click the verification link in their email they can start to create a username and password.
Does anyone see any problems with the second way, whether a security concern or anything else? It's not common and I personally cannot find a totally obvious problem with it, but I'd prefer to use it only after many people confirm they don't see problems or loopholes with it either.
Personally I do see an issue that can be inconveniencing for the user:
When most people register with a web site, they expect that they will have to answer quite a few questions, spend some time reading the FAQ and the terms of service and then spend some more time setting up some preliminary aspects of their profile.
The traditional flow allows the user to choose the time to go through that process. Afterwards, the user only receives a verification link, which normally is a 3-second process to use and can be done at practically any time.
Your proposed flow forces the potential user of your site to spend time reading your documentation, then wait until they receive the message and then find some more time, potentially after a few days, to fill in the forms. I, for one, would find that at least slightly annoying - if not outright discouraging - especially if the mail takes its sweet time to arrive, as it's often bound to do.
I also don't like the inherent implication of such a scheme:
Traditional flow: "Oh nice, you filled in our forms, just give us an address to send you a proper verification". The user here is merely waiting to complete what is essentially a done deal.
Mail-first flow: "Oh it's you. Well, wait for a while and we will send you an invitation if we want you". Here, on the other hand, the user is left in a limbo of subconscious uncertainty until they receive your message.
I believe that the first approach is far more open and friendly to the user. It's also the current standard flow for these cases, which should be enough of an incentive to use on its own - you should avoid forcing your users into processes they are not used to, unless there is no other way.
Getting an email from a friend with an invite link to access a site is exciting - it feels exclusive and new and fun. I'm being given something - so I gladly sign up.
Being required to enter an email address in order to start using a site feels draconian and restrictive and annoying. I'm being asked to give something up as the first step then possibly (maybe?) get something of value down the road.
It's not logical - in both cases, my email address is must be verified before an account can be created. In fact, the first case requires my friend to actively SPAM me with an offer I never requested.
Do you know why I first created this StackOverflow account? Because when I wanted to contribute an answer I could click on the Google logo on the login page and start using the site immediately. No username, password, first name, last name, DOB, or other B.S.
Do you know why I never created an Experts Exchange account? Because the first time I tried to access an answer I was prompted to enter a credit card number, billing address and phone number. Before I could even sample what the site had to offer, I had to give something up.
The point is this: barriers to entry make your site suck. Account creation should be as seamless and painless as possible. Being able to access a site immediately after filling out a single-page signup form and a CAPTCHA is awesome, even if access to other features is restricted until email verification is completed. Maybe I'll even tell you my DOB and favorite color if it unlocks more features.
Personally I don't see a problem with it - its a matter of choice. I think the key point though is making it clear to the user that they must
1) enter their email address
2) wait for a confirmation email before they can get to step 3
3) sign up for the account.
It potentially removes the amount of data held and time invested by the user if they only have to enter a single piece of information (their email address) before filling in the rest of the information you require.
Personally, I'd keep it standard so users don't get confused. The amount of work is the same - get a username/password/email address - wait for users to click the link before they can login to your site.
So how many times would you allow to use link send in email?
If only once, user can't create an account if he close browser before selecting username.
If multiple times, a lot of people can create accounts using same link. Publishing this link and using password recovery feature can be nice phishing trick.
And if you check for this email in your database and allow it only once, user would not be able to create two legitimate accounts.
I could see this method being slightly simpler - when the user clicks the verify link in their email, you send them to a form with a hidden pre-generated id number inserted, and then assign a username and password to it afterwards. Blank accounts, with just and id and no other information, are easy to periodically filter out and you're not storing any details whatsoever until the account is successfully created.
However, there's probably a reason why most sites collect username and password before email - you're getting a user invested before you ask for a more personal bit of information. The account is created - now just verify your email. The other way around ask for an email address first and an account second - even though functionally it's the same, perceptually it's not. Also, the advantage of the standard "flow" is that users know what to expect - following conventions mean users feel like they know what's happening and don't get confused or lose interest.
I want to share some thoughts about second approach.
First of all, it is very similar to invite system, but IT IS NOT the same.
You have to allow to send more than one registration request for a single e-mail address. If you don't - potential user might get it accidentally deleted and there will be no way to repeat the procedure. If you do allow that some angry dudes might use this as spam tool (send as many mails as possible to one(maybe even more) e-mail address. Imagine how would you company/site look for a person who got 10k registration requests...
Standard way has one serious advantage: it allows user name reservation without confirming e-mail (user might want to register, but don't want or has no access to the e-mail server/account).
You MUST consider that your server might delay email sending for pretty long time. Possible reasons: out of memory, DoS attack, email server failure and etc. If you choose mail first approach and user don't receive that mail in 5 minutes (for ANY reason), 3 of 4 potential users will course you company/site and never complete registration.
There is a reason why it is called a standard way, as a lot of small details are considered.
Both approaches are OK - but if you're going defer creation of the account, then you're going to have to embed all the required details into the URL - expiry date, username, password and email address and then encrypt it all to prevent tampering - which makes it rather large.
Actually - you couldn't allow people to pick their own usernames - since you'd have no way of checking whether the username had already previously been requested and not verified. And if you're going to publish usernames, then you'd therefore be publishing email addresses.....not such a good idea?
Here would be my concerns with this approach.
Email delivery is not guaranteed and can be slow. If the user doesn't get the email right away, they may not complete the registration process. What if they mistype their email address or if the email gets marked as SPAM?
In my experience, it is always better to keep record of the users that try to register to a site.
The problem is that more then often the users do not get the confirmation e-mail.
When that happens they often forget the site and do not come back.
What I do is to retry sending the confirmation e-mail after a while, say one week. Often they receive the second e-mail and you end up recovering a registered user that otherwise would be lost.
As a matter of fact, I retry sending the confirmation e-mail once every week until the user confirms or it passed 30 days since the registration attempt.
Even if the user does not confirm after 30 days, I do not delete the account. Often the user comes back trying to register again. Then I just send him again the account confirmation once again and encourage the user to contact the site if he does not get it again.
All this is to maximize the chances of recovering a registered user that otherwise could be lost.
I would suggest the second option. Let the users verify themselves by clicking the link in their email. Then they can choose their preferred username and password. I hope the usernames are unique in the site.
It would be helpful in the situation where some users forget to verify the link in their emails for a long time and so their usernames are locked. Others cannot choose those usernames (until that record is deleted later). Also this can eradicate spammers from picking their own usernames and locking them for use by others.
Hence i would suggest to go with the second option. Let the user first verify his email and his existence before he picks a username and locks it for use by others.
There are actually some sites that do that.
You enter your mail
you get a
verification mail with an initial
password and verification link
once you click the link your account is
active you're directed to a form with
additional details (full name, etc.)
but you may skip them and fill them
any time in the future.
This minimal registration process will help you avoid the loss of potential customers who don't want to bother with filling to many forms and supplying data before they really need to.
What it comes down to is convenience for the user. If the only reason for them the check their email is to verify the account then it may seem like an inconvenience. Instead have the system generate a password for them, email it to them, and instruct them to check their email to get their password. You can allow them to change the password after they log in if they want. This method also help to make sure "strong" passwords are out there initially.
I've been tasked to build a system that allows someone in our company to send out an email with a link to a pdf file that will be kept on our webserver. The recipient can follow the link to view a newsletter we normally sell. The idea is we do this for three months, then see if they'd like to continue and pay for the full subscription.
I've got the registration portion built, but I'm trying to find the best solution for sending the email. Here's what I've thought of, but am interested if anyone else has something better..
1) When emailing, generate a generic code that gets appended to the URL. The use would follow the url, and it would check our DB for "ok" entries and pass/fail them access. This seems ok, but a link could be passed around or even loaded to a public site where anyone could access.
2) To extend the above, I thought maybe I'd have a "one time click" kind of thing where once I know the link was clicked, it could expire, so any subsequent clicks fail. The downside is if they click to view and close their window, they're done. Likewise, if they click and their computer crashes before download completes, they'd be locked out as well. I don't know if there's a way (in PHP for me) to confirm a file download has completed...
3) I could put the files in a directory like /trials/201009/r#nDomstr1n6.pdf where the file is uploaded and the name for the link is random so it would be hard to guess. Then I could use .htaccess to protect each month's folder with a different password. This could get tedious and would be annoying for users most likely.
We don't want to force them to manage their own passwords b/c having to login and remember yet another account may discourage participation.
Thanks for any ideas or pointers.
D.
I'd say do it with a random code for authentication per email address, and expire that after 5 days. If you limit access to the ip that first hit the url hash, that could work too but could iconvenience legitimate users/customers.
In any case make it easy for legitimate users to request a new authentication code if needed. That way even if any of your limitations inconvenience one of your potential customers, they will not be as ticked off about it.
Finally, consider that if they like the pdf and want to share it, they will probably just share the pdf itself right away and not bother with a link.
First off, realize that there is only so much you can do here on your end. You are allowing users to download a PDF, after which they can do with it what they please (legally or otherwise). So, preventing passing around the link is not necessarily going to prevent people from sharing or posting the PDF itself.
That said, if you do want to make it a little harder, you could do a variation of your suggestion #2 in which you institute a time delay of some kind before the link expires after it is clicked. You could also limit the number of times the link will serve the file. Because people have a variety of connection speeds, and because I do not know how large your PDFs are, I cannot say for sure what the time delay should be if you choose to use it.
Like I said, though, if someone is determined to share the file, they can easily do so.
Another possibility is that since you already know the persons email address, form a specific url for them in their email link.
So a user would click a link http://www.yourdomain.com/download_pdf.php?email=person#test.com
Keep a table with the following data for the email addresses.
id
email_addr
read_date
expire_date
When they click the link check to see if they've read it before and if they have check it hasn't expired. If it hasn't, serve the pdf to them, if it has give them a page that says "Sorry, your trial has expired../"
If its their first time clicking it then set the read_date and calculate the expiry date and set that.
Or optionally you could generate a hash or something and use the hash to id the user instead of their email address.
You could also set up a download column int he table and stop them from downloading it more than twenty times or something by incrementing the download column every time they click the link.
I've built out most of the functionality, now I'm getting stuck...
I am creating a private, web application that has an invite only registration system. An admin user sends an email invitation to a user, the user clicks the link, and takes them to a page where they can create an account that has been linked to their email address.
When the form is submitted and does not have any validation errors, the data is inserted into the database for the first time. The email column of the invitations table is unique, so this is the token that the user needs in order to verify that they have permission to create an account.
The situation that I am confused about is when the admin user tries sending an invitation to the same email address. The email address column is unique so there is an SQL error. I don't know if I should do a check for that email address before inserting that record in the database, or what I should do.
I want to create a re-send invitation feature for emails that get lost, or accidentally deleted. Which is why I didn't want the admin user to be able to send a duplicate email to the same person, rather, they should use the re-send feature.
I hope this is all making sense. Any insights would be appreciated.
I use paper and pen to visualaize what I realy want. If the flow is clear I think you can make it ;)
I would definitely add a check to see if that address is already in the database before you attempt the insert. You could trap for the exception, but I would prefer to explicitly test for the presence of the email address.
An idea for you... When the email address already exists, you could make the system resend the invite. If you did that, you may be able to reduce some code repeat by not having to write an additional 'resend invite' function. Just call the same 'send invite' function on the initial invite request, or a 'resend invite' link described by others.
I also like the idea that others have already mentioned of the "Resend invite", especially philipnorton42's implementation.
I would use a validator inside your form, so the emailaddress is checked against your allready stored emails. So there should be no duplicate entry. Also i would implement an action that lists all your entered accounts and the creation- and activationtime in a nice table. Of course the action and view will support a pagination, so you can easy navigate through your data. If an entry has not yet been activated there should be a link, maybe an icon too, to a resend-the-email action for this special entry. And another action which resend the email to all not yet activated entries would be handy. Last but not least i would implement a reporting action so i can easily figure out whats going on.
I would say that Valter is correct, you perhaps need to draw out what you want to accomplish.
However, you appear (from what I can tell) to have all of the information in place for a "Resend invitation" button that the admin can click on to resend the invitation. I would create some reports in the backend that would allow me to view invitations that have been sent, that converted into users and that haven't been answered yet. Adding a button to the haven't answered yet report that resends individual invitations shouldn't be too hard.
Hum, i would create an view where all "Activations" are visible, with an button to just resend the invitation ? Without changing the record inside the database.