Google API blocked my app ip address and returns CAPTCHA - api

My app uses Google API and it worked well for a long time but recently Google blocked the IP address of my server for about an hour and every response to the API was as follows: Our systems have detected unusual traffic from your computer network. This page checks to see if it's really you sending the requests, and not a robot... - they attached CAPTCHA form field as html.
My app is also an API so CAPTCHA can not be done because it is in json format (HTML in json cannot be rendered).
Only app users sends requests so I have a little control over it. Of course, I limit the number of requests per user, but it was not the case. Limits at google console are also fine.
I wonder how can I prevent this happening in the future? Is there any way I can ask them directly? Have you experienced this?

Related

Browserless Authentication using the Web API

I am trying to authenticate a user inside a desktop application using the web api. I am not using a browser, I am using straight up GET and PUSH calls to the endpoints of the Spotify servers. Immediately I ran into some problems. It appears that upon the initial GET command to "accounts.spotify.com", the returned response includes HTML with a javascript function that runs and is responsible for dynamically generating HTML that you see on the initial login page. If you look at the Javascript function, it is clear that this is what is going on, however, you can also see this code is obfuscated and not meant to be used by us, the developers! (Link to Javascript code here for reference: Javascript function)
So my question is, while I can probably reverse engineer the code to get this working, would this be against the Spotify developer TOS?
Thanks!
Spotify's authentication happens through oauth, and a big part of user authentication as per the oauth rfc is where the user delegates permissions to your app to carry out API calls that affect their account, or return information about them. That's the web page you're seeing - it must be presented to your users so that they can delegate permissions so that Spotify can give your app an access token. It doesn't necessarily need to happen in a browser - it can happen in a web view inside your desktop application - but it does need to be loaded over https, and your application must not alter or reverse engineer the Spotify permissions delegations page.
As you correctly guessed, reverse engineering any Spotify APIs is against terms of service.
For more information on authorization on the Spotify platform, I'd recommend having a look at this guide.
Hope that helps! Please ping me if you have any more questions.
Hugh
Spotify Developer Support

What's new in SMAPI 5.5?

Sonos 5.5 beta seems to have changed SMAPI somehow. Spotify for example seems to know the local time of the client, as it changes its response to getMetadata("root") depending on it, but as both the Spotify uris are https I can't sniff them to see. Anyone know what has changed?
This can be done today by looking at the Client's IP address to determine their geographic location. By refreshing the catalog (via getLastUpdate) at a regular interval you are able to update the root browse as you see in Spotify, Google and Songza to provide time specific playlists or radio.

Communication between a Mac app & local website/server

I want to control a mac app via a local website. I think the best way is to create a webserver with my mac app and then to send (primarily) integer values from the website and vice versa.
I found already CocoaHTTPServer, but I'm not sure how to do it.
For start with I want to have a slider on the website, that updates a slider in my mac application (and vice versa)
You will initiate on a separate thread or operation the web server and always wait for incoming requests. Whenever you receive a request you will handle it accordingly.
Also, if you are using this: https://github.com/robbiehanson/CocoaHTTPServer/
then there are a few examples that show how to do it. Copy the code from there to begin with the web server handling requests. After that, think through what you want to send and what you want to do. Build a form or something for the web site and submit a request to the web server.
CocoaHTTPServer will let you embed the web server into your application, which is a fine solution for what you're trying to accomplish.
Some thoughts on how to engineer it:
You'll need to subclass HTTPConnection.
Model your solution on the PostHTTPServer example.
You could get the data you want to send into the URL. Something like POST http://localhost:12345/updateSlider/123. (You probably don't need an actual POST, but no reason it wouldn't work. Technically a PUT would be more correct.)
Start by handling that part – where the browser sends a value to your application. To generate POST/PUT requests for testing purposes, use curl, or else build a static page and open it in your browser.
When you get that working, then worry about presenting a web page to the user.

How to avoid delay when displaying Picasa photos using Picasa API?

I’m currently working with the Google Picasa API (C#) to display photos from public Picasa web album on my website.
The issue is that there is a delay (seconds to minutes) from the moment changes are done in web album to the moment it is reflected via API.
I need it to be reflected immediately: When new photo is uploaded to the album I need it to be displayed on the same time exactly in the web site.
It got even more interesting when I found out changes are displayed without delay when entering the URL (http://picasaweb.google.com/data/feed/api/user//albumid/) to IE9 or Chrome.
I have also tried to call the above URL via HttpWebRequest and set all no-cache headers, but it didnt solve the issue.
So, what is the difference between browsers request to the request done by the HttpWebRequest/API on this case?
Can anyone put me in the right direction?
Thanks
Just in case you haven't found out and might still be interested, I had the exact same problem (though in PHP) and it turns out that anonymous requests are delayed, while authorized requests are instant. Because your browser contained a cookie with your Google account, it counted as an authorized request and therefore was instantly updated. However, the request by the code was still anonymous.
The solution would be to make an HTTP POST to retrieve the feed, and authorize the request as described here.

App: Bypass authentication for Open Graph facebook requests

I have a Facebook app that can't be used before a user log in via Facebook (OAuth). Some pages (e.g. example.com/books/2) should be accessible for Open Graph requests (when they have been liked). Currently, Facebook isn't able to retrieve those pages since authentication is required (redirect). How can I determine if an incoming request is coming from Facebook or not? Or should I take another approch?
Thank you!
Just add an exception so that Facebook's crawler can reach the page, The user agent is currently facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)
(but the version number may increment someday)