1 Star2 Stars3 Stars4 Stars5 Stars
Loading ... Loading ...

By Knorrium
TL;DR: the Instagram Foursquare integration has a bug which allows users to checkin remotely and still get points, badges and mayorships when posting pictures.
Long version:
Roughly over one year ago at CAST 2011, I presented a lightning talk entitled “Bug or Feature: The importance of being context driven”, which explored some common bug or feature scenarios we often see here in Brazil.
My intention was to raise the awareness of our fellow testing colleagues that even though we have the power to file bug reports, we should consider the context we find ourselves (and the bugs!) in before doing so.
So, last week, I decided to post some pictures from my trip to the Yahoo! Headquarters in Sunnyvale on Instagram, adding them to my photo map and to their related Foursquare venues.
My use case was simple:

As a Instagram user
I want to be able to upload my pictures to a Foursquare venue
So that other Foursquare users can see them when they explore the venue.

Everything was cool until I received a push notification from Foursquare about a comment left by GC on my checkin at the Y! Design Studio. He was complaining that I had stolen his mayorship and wasn’t even at the Yahoo! HQ (it was Sunday and I was at the San Jose airport).
But hold on a second, I was just uploading pictures! I didn’t want to check into the venue on Foursquare.
I said it was probably a Foursquare bug because we shouldn’t be able to receive points, badges or even mayorships when uploading pictures on Instagram.
Elias jumped into my conversation with GC and brought up the “Bug or feature?” question, saying I should open a feature request.
GC said it was a bug since I was able to take the Y! Design Studio mayorship from him.
Considering that “a bug is something that bugs someone who matters”, GC and I were in sync and I decided to investigate this odd behavior.
Before we jump into conclusions, let’s dive into the Foursquare and Instagram APIs.
Instagram upload endpoint
This is a private endpoint, so I had to sniff the SSL traffic to understand how it works.
In order to reproduce the scenario, I added some pictures to the Yahoo! Brazil office.
Here is the request body (after removing my private access tokens and formatting it to improve readability):
“fb_access_token”: “FACEBOOK_TOKEN”,
“foursquare_access_token”: “FOURSQUARE_TOKEN”,
“flickr_access_token_key”: “FLICKR_TOKEN”,
“location”: “{“name”:”Yahoo!”,”lng”:-46.684924849648894,”lat”:-23.595049881369359,”foursquare_v2_id”:”4b1e479af964a520591824e3″,”address”:”R. Fidêncio Ramos 195″,”external_source”:”foursquare”}”,
“caption”: “A whole new level of @bigodines keyboards”,
“geotag_enabled”: true,
“filter_type”: 0,
“share_to_flickr”: true,
“source_type”: 0,
“media_id”: “330338251555385834_1222987”,
“flickr_access_token_secret”: “FLICKR_SECRET”,
“media_latitude”: -23.594667434692383,
“media_longitude”: -46.68516540527344,
“share_to_facebook”: true,
“fb_has_publish_actions”: true,
“share_to_foursquare”: true,
“device_timestamp”: 1353599409
The response contains a Location object:
“location”: {
“external_source”: “foursquare”,
“name”: “Yahoo!”,
“foursquare_v2_id”: “4b1e479af964a520591824e3”,
“address”: “”,
“lat”: -23.595049881,
“pk”: 333588,
“lng”: -46.68492485,
“external_id”: 391328
The coordinates on this object differ from the ones in the EXIF data (media_latitude and media_longitude) parameters, so let’s take a look at the Foursquare venue API:
Hitting the Venue endpoint returns this object, along with a lot of information:
venue: {
id: “4b1e479af964a520591824e3”
name: “Yahoo!”
contact: { }
location: {
address: “R. Fidêncio Ramos 195”
crossStreet: “12

Você também pode querer ler

Comments are off for this post.