[slightly offtopic] - methods used to verify a registration - by a confirmation email/web page

[George Gallen]

We are setting up a couple web pages that we want to “register” users.

I wanted to do a confirmation email – and have them click a link to confirm the registration.

 

Here’s the problem.

You can’t just give a URL that contains a token in a parameter (GET or POST) since a lot of email hosts, will hit the URL in order

To show in the preview page, or to download an image. So it looks like the user clicked on the link, but in many cases it’s just

The mail server that the user is using….

 

Yes, I can have the user click a web page, then physically click a submit button after entering the token into a text box, but

That’s a two step process.

 

Looking to make it a one step process.

 

Is there anyway to know whether it’s the user or a mail preview that’s hitting a URL?  I’ve tried check the agent string, but nothing really

Jumps out, and most times, the string is identical to a browser agent string (most likely being used by cURL or something).

 

Has anyone else come across this? Or just settled with the 2 step process?

 

Thanks

[Ian Harper]

Seems to me that it's got to be a 2 step process if you are seeing the the preview requests trigger the confirmation.

On a side note, there's a tweet that's going around that provides a good lesson on GET vs POST. The take away is that GET requests really need to be side-effect free: https://twitter.com/rombulow/status/990684453734203392

The author of the tweet had setup a link to open/close his garage door using an IoT device. The browser tab he was using was synced across all his devices (laptop, iPhone, etc) and every time he loaded a new tab Safari would execute an optimistic GET request on the link which would open or close his garage door. He discovered what was happening when he opened a new tab on his phone late at night.

[George Gallen]

funny. that's as good as driving through the neighborhood pushing your garage door opener - to see who has the same frequency as you!

I was thinking about this more.

I could still use the GET to prepopulate the fields (with the emailed token in the URL) - but still require a click to submit the form -

   using two webpages instead of one - but at least they wouldn't need to copy/paste and then submit.

George

---

From: mvd...@googlegroups.com <mvd...@googlegroups.com> on behalf of Ian Harper <ian.h...@bellcold.com>
Sent: Friday, May 4, 2018 12:32 PM
To: Pick and MultiValue Databases
Subject: [mvdbms] Re: [slightly offtopic] - methods used to verify a registration - by a confirmation email/web page

 

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Albert Kallal]

Gee, I would think providing some kind of "key" or "id" you generate in the link for the user to click on in their email?

At that point the on-load event of the web page can check for this parameter (and say the included email). At that point I don't see why the user would have to click submit?

Of course, I suppose what kind of web authentication you are using will be a issue. (that page can't be secured to only authenticated users based on web security model - it will have to be a non secured page). I assume that the web server is providing security here, and pages that are secured can't be hit by non secured users. 

This depends on the web security model you are using (in other words, you want the web server doing the security - not  code you write). In my case, I come from a asp.net background - so how you doing this may well not apply. So web pages are secured based on authenticated users being part of a group, or not. And then often further refinement as to what the user can view will be code that retrieves data based on the logged in user. But all such pages can't be viewed or used by non authenticated users.

Your "confirm" page will thus have to be a viewable page that is not subject to authenticated users. However I can't imagine someone getting some generated id key and the email correct to activate such users. Regardless, I don't see the need for a user to hit submit in this case - the page load can grab this "key" and any other parameters provided and then run code to activate that user - the page would simple display "thank you" or whatever.

If a user not logged in hits any page requiring authentication, then the web server will direct the user(s) to a logon page - you in general don't have to write much of any code for this to occur.

regards,

Albert D. Kallal

Edmonton, Alberta Canada

[George Gallen]

Here's an example. I have an external event trigger an email and a text message that includes a link like http://domain/page.php?event=12345 with the email saying click this link to stop any future notifications on this event.

Here's the problem the isp for the text message hits the URL to pull a page preview, and subsequently triggers the page.php to treat this as a user wanting to stop the event notification. So. If I switch that to a model that prefills a form and needs to user to click the submit button, which a general GET with parameters will not do, I am able to know it was an intended action.

As others have tried checking the agent string for a bot or spider referetence not all times do the URL preview utilities play nice and let you know often times they masquerade as a browser.

I can't think of any other method other than a forced submit that won't be confused with a plain get from a preview check by the email servers.

Btw. I found at the time baracuda email services wAs one big one so I started checking for IPs specific to them and had my web page ignore actions if the IP was a baracuda IP. But as time went on I couldn't continue monitoring for additional ips and other email packages started doing it also.

[Kevin Powick]

Your problem and a proposed solution is described exactly at the following link.  It even specifies the Barracuda email filters problem.

https://wordtothewise.com/2013/07/barracuda-filters-clicking-all-links/

I believe it was already mentioned by another poster that you'll need a two-step process.  Your link will need to take the user to a landing page, upon which they can find a button for them to confirm the request.

--

Kevin Powick

[George Gallen]

yup....seems I wasn't the only one.

I like the idea of the phantom link to identify - but then it would be a matter of integrating two single click pages and putting

   a delay in the primary URL that if the phantom URL didn't get clicked or was clicked within the same second to ignore.

George

---

From: mvd...@googlegroups.com <mvd...@googlegroups.com> on behalf of Kevin Powick <kpo...@gmail.com>
Sent: Monday, May 7, 2018 10:47 AM

To: Pick and MultiValue Databases

Subject: Re: [mvdbms] Re: [slightly offtopic] - methods used to verify a registration - by a confirmation email/web page

 

[John Stokka]

In one of my companies we used to do a lot of bulk emailing.  We had to write several special things regarding particularly unsubscribe requests because all of the bots being used by the isps.

We did two things that you might find particularly helpful.

We tracked Opens as users who had requested an image.  We tracked Clicks as users who followed the href links.

If we found a Click with no corresponding open, then we ignored it as it was a bot. (You would be surprised how much of this there is)

On the unsubscribe page we implemented a captcha requiring the user to acknowledge the action with more than just a click.  We also found the bots would follow the href links in the email AND follow the href clicks on the landing page as well.

Hope this helps.

Once we identified a "bot" ip address we would of course ignore all of it's traffic.

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

[Kevin Powick]

I think that "phantom" links and timed delays will lead to more problems and uncertainty than it's worth.  Just KISS. 

I also like what John Stokka says about using both the link click and the landing page click, possibly with a Captcha, to acquire the fewest false positives.

--
Kevin Powick

[George Gallen]

Depends on who the KISS is for. KISS for programming – yes, landing page best – but would take 2 clicks minimum

KISS for the client – then phantom link and timed delays – as it would allow 1 click .

 

But the uncertainty could still apply even with the delay – if the email scanning doesn’t scan all links in the email

Then the system could still think the client requested the action.

 

I think it would depend on the severity of the click – if it was just to pull/display data – doesn’t matter

But if it were say to opt out of something, or worse opt in – which could cause the client to receive future

Mailings, especially with GDPR looming around the corner….and CAN SPAM act in the US.

 

Given those two – 2 clicks might be a very small price to pay vs downstream $$ price in fines.

 

George

 

From: mvd...@googlegroups.com <mvd...@googlegroups.com> On Behalf Of Kevin Powick
Sent: Monday, May 7, 2018 4:47 PM
To: Pick and MultiValue Databases <mvd...@googlegroups.com>
Subject: Re: [mvdbms] Re: [slightly offtopic] - methods used to verify a registration - by a confirmation email/web page

 

 

I think that "phantom" links and timed delays will lead to more problems and uncertainty than it's worth.  Just KISS. 

--

[Albert Kallal]

I guess the quick question is:

Do you consider email clients having the ability to run JavaScript?

I was working on the assumption that the "vast" majority of email clients (desktop or web based) don't run JavaScript code.

However, such code will run if they click on the link and load the web page.

Of course if above is not a valid assumption - then so be it.

I thought few if any web clients permit JavaScript to run (they strip it out). However, clicking on the actual page allows such code to run. Hence this gives one the means to run some JavaScript which can set a session var, hidden control or even call some server side code.

Regards,

[George Gallen]

I see what your saying…hmm.  An Onload auto submit – I don’t think the email scanners execute javascript

    Or hopefully they shouldn’t.  That would be one distinction.

 

Thanks. Wasn’t  thinking that route.

 

George

 

From: mvd...@googlegroups.com <mvd...@googlegroups.com> On Behalf Of Albert Kallal
Sent: Monday, May 7, 2018 7:58 PM
To: Pick and MultiValue Databases <mvd...@googlegroups.com>
Subject: Re: [mvdbms] Re: [slightly offtopic] - methods used to verify a registration - by a confirmation email/web page

 

I guess the quick question is:

--

[Albert Kallal]

Well, my bets are that "bots" do execute JavaScript, but not email clients. Even web based email clients strip out the JavaScript for preview.

However, the link they click on can pass + provide some key or token. As noted, you could even pass the email also.

The web page load this in the case of a "bot" or a user clicking would run JavaScript, but not the email preview.

With a few parameters passed, then this could be a workable route.

[John Stokka]

I forgot about the hidden links thing.  Yes we also implemented an href that was invisible and impossible for a human to click on.  This finds bots 100% of the time.

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

[Tony Gravagno]

That phantom/hidden link technique is called a Honey Pot.
With Captcha there are two current versions - one of them is invisible to the user and doesn't require a click. Check it out.
You can also add a JS mouse event, which only on the very first event will AJAX a post to your server. This won't be tripped by a bot.
HTH
T

On Tuesday, May 8, 2018 at 6:40:28 AM UTC-7, John R. Stokka wrote:

I forgot about the hidden links thing.  Yes we also implemented an href that was invisible and impossible for a human to click on.  This finds bots 100% of the time.