I run a website where you must create an account and verify via email to access many site features. Lately a bunch of the sent account confirmation emails are being marked as spam because someone or something is using real email addresses to sign up for fake accounts on my site. I know they are fake because almost all of the time the IPs are coming from Russia or have garbled usernames like 'VDLWYvAkZniTQS' and have no site activity. It's always a different IP though so just banning one at a time wouldn't help. They also sign up about 3 accounts/hr so rate limiting wouldn't really work. I'm starting to run out of ideas and my email service provider might deactivate my account because of the uptick in spam complaints. Any ideas on how to combat this?
I've tried installing both a honeypot and reCAPTCHA v2 into the sign up form but they haven't helped too much. If anything they started to use more convincing usernames now but the IPs are clearly still coming from Russia.
My site is using Google reCAPTCHA control but I am hearing its being block in
China, Is there anyway around this I see there is some people reporting that changing the API to https://www.recaptcha.net works in China?
Anyone try this because I see it still going out to google?
string apiUrl = "https://www.recaptcha.net/recaptcha/api/siteverify?secret={0}&response={1}";
As google says in his assistance page, you should use this domain "www.recaptcha.net" instead "www.google.com" on the api call.
First, replace src="https://www.google.com/recaptcha/api.js" with
src="https://www.recaptcha.net/recaptcha/api.js"
After that, apply the same to everywhere else that uses "www.google.com/recaptcha/" on your site.
Obtained from: https://developers.google.com/recaptcha/docs/faq#can-i-use-recaptcha-globally
Edit: to clarify on some of the comments, while if you try it outside of china yes you do get references to gstatic.com but if you try this in china, any references to gstatic.com are replaced with gstatic.cn (don't forget to add it to your SCP). So this solution is still valid.
IMHO, google things are not stable in China as it can be blocked anytime.
From Baidu threads, it also mentioned that sometime google recaptcha works, sometime it doesn't.
https://www.v2ex.com/t/492752 (Chinese)
In programming world ,unstable function means useless or more code for dealing with exception.
If you really need to use google recaptcha,
you would better test properly using VPN (IP in China) first.
Here are some options you can consider,
You can use alternative captcha
Google will tell you various captcha.
Build your own captcha
Open Source Invisible reCAPTCHA alternatives
Use proxy web server(nginx) to send and receive data to or from google recaptcha
I have shared the solution to this problem by using cURL.
https://stackoverflow.com/a/63568516/11910869
cURL acts as a middle man between the client and the server. So even if google.com/recaptcha can not be accessed by the client because it is blocked by the service provider, cURL can act as the proxy to send the HTTP requests and get the response.
I am looking to test different traffic patterns within Google Analytics (Direct traffic abnormally high). I was curious if anyone knows how to create an event that fires when source =wildcard To make this event more difficult, this would be set up within Google Tag Manager using Universal Analytics.
I see the 6 event tags but none of them sounds like it would perform my need?
Thanks
Google Tag Manager is not a tracking tool and knows nothing about the traffic source, so no preconfigured macro could be used in a rule to fire tags depending on source.
If you use "classic" asynchronous analytics you can set up a macro that reads the _utmz-cookie and checks in a rule if it contains a source string ("direct","cpc" etc.).
However Universal Analytics determines the traffic source on the server and does not store it clientside, so with UA this would not work.
A few traffic sources are easily recognizable on the respective landing page:
If no referrer is present it's a direct visit/bookmark
if there are campaign (utm) parameters in the url you can use those
if there is a gclid parameter in the url you know it google/cpc
if the referrer is a google domain with a country tld and the parameter "q" is present (will be empty with encrypted search but should still be there) it's an organic google search
if the referrer is a bing domain with the parameter q present it's an organic bing search (and similar for other search engines)
However this will only work on landing pages. You need to write you own cookie to store the source for subsequent pages.
You can refine this approach to give rather similar results to Google Analytics but it will never match perfectly.
One of the most common reasons for abnormal high direct traffic is that no campaign parameters are present in paid traffic, either because you forgot to enable autotagging in your adwords campaigns or because you have redirects that strip out campaign parameters (so paid traffic is lumped together with direct). The above approach would not help you to discover this so I suggest you check this manually first before you do anything else.
Would someone happen to know if Google Calendar has some problems subscribing to iCalendar feeds served on a secure https-address?
I'm developing a website running on an https-address that has an iCalendar feed that users can subscribe to. The feed works just fine in Outlook and iCal, but not in Google Calendar. When a user attempts to subscribe to the feed, they get the error message "Could not fetch the URL".
I suspected that there was something wrong with the feed or the generated iCalendar data, so I ran the .ics file produced through a number of validators, and they were fine. To rule out an error in the feed itself, I put the generated .ics file on the server, to see if a static file would work, and that failed in Google Calendar as well. Then I put the file on a completely different server behind a non-secure (http) url, and that worked!
So I'm beginning to suspect that httpS is the problem. The server's certificate is valid, so that shouldn't be causing any trouble. Besides, the validators could access the feed (and the static file) just fine.
This google groups discussion indicates that others are having similar suspicions: http://productforums.google.com/forum/#!topic/calendar/61-eUd-fyrg
Problem is, the site HAS to run on over https, so I can't just switch to http to make the feed work.
So, if anyone has any information confirming or contradicing my theory, or any ideas about what else might be causing these problems, I would greatly appreciate it.
I can confirm that (today) Google Calendar can successfully subscribe to an HTTPS iCal feed.
You can test this yourself by adding this URL: https://events.stanford.edu/byCategory/2/eventlist.ics
To be extra sure I also did another test of giving it an HTTPS url that didn't also work if you replace the https -> http. That was also fine, so in all cases, HTTPS should work.
What doesn't work in my tests is:
HTTP Authentication (https://myusername:mypw#example.com/) - I got "Could not fetch URL" - but that's not what this question is asking.
Any URL over 256 characters. However, using a link shortener (e.g., goo.gl) works around this issue.
Google has confirmed that it really is an issue with HTTPS, i.e. Google Calendar is unable to subscribe to iCalendar feeds from external encrypted (https) URLs.
My employer has an enterprise account with Google, and we filed a support request with google's enterprise support, with example feeds and our own assesment of the problem.
Today, we finally got a proper answer, confirming our initial analysis and informing us that the correct techincal team has been notified and an internal feature request (for supporting feed from https-urls) has been opened.
We were not given any timeframe for the fix, but I requested that they get back to us when the issue has been resolved. I will add that information to this answer once I receive it.
The issue we've found in our case is that Google Calendar currently ignores the HTTPS indication in the URL and accesses via HTTP instead. If your HTTP requests redirect to HTTPS or just serve up the content over HTTP, then it will work. If you have a firewall blocking port 80, then things hang and its game over.
TL;DR: If your URL works with http in addtion to https, then it will work with Google Calendar when you enter it as https. (That assumes robots.txt does not restrict access.) Otherwise, it will fail.
As of January 2020 the problem appears to be resolved - Google Calendar does not appear to have problems subscribing to and updating valid RFC5545 calendars. The icalender.org validator works well and can test both a file and a link (subscription).
I've been working on creating my own iCal subscription system from scratch and wanted to share something I learned this week, ten years after the start of this discussion.
Like discussed above, importing via URL accepts https:// just fine.
But when creating an "Add to Calendar" URL for Google Calendar I discovered that they still won't accept https:// links.
The "Add to Calendar" URL formula is:
https://calendar.google.com/calendar/u/0/r?pli=1&cid=<iCal-URL-Here>
Some examples to make it clear:
// https will not work:
https://calendar.google.com/calendar/u/0/r?pli=1&cid=https://example.com/ical.ics
// http will work:
https://calendar.google.com/calendar/u/0/r?pli=1&cid=http://example.com/ical.ics
// You may also try using the webcal protocol:
https://calendar.google.com/calendar/u/0/r?pli=1&cid=webcal://example.com/ical.ics
Your mileage may vary depending on your host's handling of unsecured requests. I welcome anyone who runs into trouble to leave a comment.
Before I part, another friendly tip: You need to URI encode your iCal URL when using this import URL.
So, in reality, your link would be:
https://calendar.google.com/calendar/u/0/r?pli=1&cid=http%3A%2F%2Fexample.com%2Fical.ics
In JavaScript, use encodeURIComponent().
if the server has a robots.txt blocking google, this was a cause for failure with google calendar for me too. So, have you tried looking at the robots.txt of your https server?
This being said, is not a limitation of google calendar + https as google calendar provides https for its on "private address" for .ics files and thereof it can also accept https from google.com (though this is only one configuration over many other possible).
I have had a lot of difficulties with this:
It was frustrating because a downloaded file would open in Google Calendar or iCal, but it would not load as feed in either. I would get these errors in Google Calendar when I did add by URL: "Failed to import calendar from" (sitename) or "Could not fetch the URL."
Here's what I had to do:
Have duration or endtime for events, NOT BOTH.
I also had to remove this from the header:
content-disposition: attachment; filename=Schedule.ics;
Also, to check if it's valid, Google ical validator.
Is it possible to send a text message from a computer to a cell phone? I'd like to be able to do this with Ruby, not quite sure what it entails. After seeing GrandCentral and Google Voice, it seems like it's not that bad.
Is it possible? How do I get started!
Yes, it's fairly trivial.
Depends on whether you want to pay or not; some providers offer email addresses for each number that is with them, otherwise you can get an account with an SMS gateway (find one in your country, or try clickatell) and then just buy credits. They'll have various interfaces: Email, HTTP, more.
check smsroaming.com it provide services to send sms from website and also have desktop application for it. including iphone, blackberry and facebook application for it.
i hope they will help you to manage sms.
regards
Azy