I got a website where you can sign up for newsletters. Signing up does only take a click from the user to register it's email in the database. I figured that this might be a problem since there's no cooldown/time limit or what so ever, so i guess it would be possible to make some kinda script to spam my database with emails.
I've been thinking of implementing a Captcha or something, but I'd rather go with some kind of cooldown on signing up. Something like, you can only sign up 2 emails each 15 minutes, or something like that. What would be the best solution here?
The method you use is single opt-in. It's no only inefficient but also possible illegal.
For inefficiency, the reason is you may get lots of invalid emails and your system is busy to send emails to these invalid addresses. The reason may come from spam trying and users' errors.
For legal, in Europe you can only send emails to people who opted in your service. The only valid way to prove they are opted in is they have confirmed opt-in link in email. http://www.lsoft.com/resources/optinlaws.asp. Having their emails alone is not a valid reason because you can buy emails from others.
So, the correct strategy is to use double opt-in. When a user fill email and submit, he will get an email asking his confirmation of this action. Once confirmed, he would be a valid subscriber and start to get emails.
Also, with double opt-in, your concern of junk opt-ins will be minimum because it becomes harder to spammers to confirm email, also they don't have too much motivation to do that.
If you have a signup table, you can check the for the number of signups from a particular user in the last 15 minutes
Signup.where("user_id = ? and created_at >= ?", user_id, 15.minutes.ago).count
If the above count is greater than or equal to 2, then don't allow
Related
We are having a lot of transactions on the site, so for this reason we are re-cycling our booking confirmation numbers/ order id numbers on the confirmation screen which is set into our purchaseID . Since we are re-using our booking confirmation number, in order to make our purchaseID unique we are adding timestamp to our purchaseID variable using pipe delimeter. So formula looks like:
purchaseID = order_id + '|' + timestamp (current date).
My concern here is, let's say I make a booking today and my purchase id looks like -
purchaseID = 5747118 | 6-7-2019
Now I access my confirmation screen again tomorrow and after 2 days, 3 days and so on and I see adobe calls firing. Because I accessed my confirmation page on different dates my timestamp changed and thus my purchaseID is not unique anymore. Even though I am seeing my same booking confirmation page my purchaseID is not unique now. Does this mean, every time i view my confirmation screen on a different day my booking/revenue would be counted multiple times ? If yes, what's the best way to tackle this issue ?
So it sounds like someone can go to your site, make a purchase and see the confirmation page, and then later on, go back to the same confirmation page without actually making another purchase. Maybe they bookmarked the page and come back to it later for reference. Or maybe they refreshed the page, because reasons.
Does your site charge their credit card for accessing the page again? I sure hope not. Your site/coding should be structured in a way that does not keep charging the customer more money every time they view the page again.
And your code logic for outputting Adobe Analytics should be structured in the same way: your coding logic should be that you only output purchase event and variables (e.g. purchaseID) when a purchase actually occurs.
In practice, this sometimes isn't easy to do because of how the site is structured. So part of why purchaseIDexists is to de-duplicate purchases, so that if purchase event and data is re-popped, it will be de-duped. But it only works if you output the same purchaseID when the visitor refreshes the page or otherwise comes back to it later on (where they aren't actually making another purchase).
Which it sounds like you were doing with the original booking confirmation number you pushed to purchaseID. But things went south when you decided to throw a current datestamp into the mix because you started recycling booking confirmation numbers. Well you can't do that. You can use a dynamic value such as the current date/timestamp as part of the value, but you must remember it, and output it in the future.
Maybe this involves adding an extra column to your database with the date/timestamp of purchase (which I have to assume you surely already have), and then pull that value when you pull the booking confirmation number.
Or maybe the solution involves stepping back and rethinking the fact you are recycling booking confirmation numbers. This seems like a bad idea to me. It's definitely a bad idea for your Adobe Analytics implementation, as you have seen for yourself. But is this not a bad idea in general? What happens if a customer buys something today and has # 12345 as proof of transaction to reference, and then tomorrow, a week, a year or whatever from now, some other customer gets the same number?
It stands to reason that you will end up with a mess on your hands, trying to sort out which customer bought what. Transaction ids by their nature are supposed to be forever unique to the transaction. So my very first recommended solution to you would be to stop recycling your booking confirmation numbers. Move to a different format if you need to (e.g. UUID).
Failing that, my next recommendation would be what I said a couple paragraphs up, about storing the date/timestamp in a column at the actual time of purchase (which surely you already have), and then grab and use that value along with the booking confirmation # to use as delimited value, instead of generating the current date on the fly (which absolutely does not work).
Sent registration Gmail Email markUp (adding schemas to the templates of letters)
I sent a letter with a markup to
schema.whitelisting+sample#gmail.com
and passed the test
https://www.google.com/webmasters/markup-tester/u/0/?hl=ru
Foldings did not come, and more than a week there is no answer.
Tell me, what is the approximate length of the answer, should the pile come and should I write again?
As per my experience in requesting to whitelist a specific email address, usually, it takes about 2 weeks in total to complete the process. Just make sure that the following guidelines in this documentation was met to avoid rejection.
will everyone get a reply if application was rejected or approved?
I'm attempting to implement the lockable module in Devise. I want to set it up so that if an account is locked, it shows the locked message regardless of whether the password is correct or not. Importing lockable before database_authenticatable gives the desired behavior, as long as the number of attempts are higher than the max attempts, but there are other reasons why an account might be locked. I've overridden #unauthenticated_message so that it returns :locked when #access_locked? is true, but that didn't seem to do anything. Is there a way to make this happen?
It looks like Devise's standard behavior is not to reveal the locked status of an account unless the password is correct, as this thread argues: https://groups.google.com/forum/#!topic/plataformatec-devise/8BWkoYf-uy8 So to head off requests to make me justify my reasoning, this seems wrong to me. In my mind, the whole point of locking the account is to avoid password enumeration. I don't really care if someone knows a particular email is registered on my site (especially since enumerating on the user creation page is possible anyway), but why give someone limitless attempts to guess a password? I'm open to being convinced, but it seems totally backwards.
I'm facing the same issue. Only thing I could do is increase the number of attempts.
Eg: If I want to allow 3 login attempts, change
config.maximum_attempts = 3
to
config.maximum_attempts = 4
This way the account wont get locked if the user provides wrong password for 2 times and correct password at the third time. But this is not a good solution, although it solves my issue temporarily.
I have a bunch of customer data that is normalized into multiple tables. I want to decide the best criteria for make a best guess that a customer might be the same. There needs to be a balance between minimizing the number of duplicates but also minimizing the false positives and therefore interrupting users to ask about potential dupes.
I am looking at some combination of first/last name + phone number || email address.
The first question is, what is a good set of criteria for determining if a customer might be the same as another customer.
The second question is, for this specific application, I only want to detect duplicates for customers that have signed up within the last 2 months or so. Does this change the detection criteria at all?
How would you go about asking a customer if they are the owner of a duplicate accoount?
"Hey Sam Jones, there is another Sam Jones that has an ip in your local area, his email is sam.jones#abc.com and your latest registration had an email of sam.jones#apple.com, are you the same guy/girl?"
If the above is even close to your scenario, then you would be leaking private information. i.e. the other Sam Jone's email address.
Typically you don't allow a customer to signup with the same email address, and secondly you verify that the email address they do sign up with is valid. That way if they signup again with a mistype in the email, they can't validate it.
An important thing is to choose attributes that are unlikely to change. If you use something like telephone number or email address, you risk having duplicates any time someone changes ISPs or mobile phone providers.
If these customers are customers that have made purchases in the past, you can store a hash of their credit card number and a hash of their billing address. Whenever they make another purchase, hash their payment info and compare it to your database. (notice I said to store a
hash, NOT their actual payment info)
if this question is of still interest to you, please check this tool https://sourceforge.net/projects/deduper/
I wrote this tool mainly for the purpose that you have mentioned in this question
I have a blogging application. Once a blog-post is created by a user, it will be sent as an email to some of user's friends. I want a functionality where the friends will just reply to the email and the content of the email will go as comments for that particular blog-post.
One way to do this is to do something similar to what http://ohlife.com does. It basically creates a unique ID per user per day, has the reply-to attribute of the email set to post+{unique_id}#ohlife.com and probably parses this field to know which user is the email for, when it gets received. But it really has only 1 email address which is post#ohlife.com. The part after the "+" get's ignored by email servers. This also is applicable to gmail.
What I wanted to know, is whether this property is for particular email servers or is it universal? If it is not universal, is there is email server independent way of implementing this? I would not want this to be based on the email subject, as it's the trivial solution I know of.
it is depending on your mail server and how it is configured.. (although it is quite a standard) - for example in postfix:
recipient_delimiter = +
you could set it to anything you like .. i once configured it to be a dot so i can use it all over the web.. http://www.postfix.org/postconf.5.html#recipient_delimiter
but you could simply make it configurable in your application as well..
Besides using the email subject or address, one other easy way to accomplish this would be to just stick an identifier number at the bottom of the outgoing email's body. It would then come back to you in the quoted part of the response message. This is much less obtrusive than putting stuff in the subject or address, and if you're using HTML messages you can even make the code invisible.