I'm trying to do an app request, but my requests do not apear in the notification (the globe icon) and I don't know what to do more.
Just to confirm that i've done everything ok, I have followed the JS SDK Request Dialog example:
http://developers.facebook.com/docs/reference/dialogs/requests/
At first time it seems to work ok, and I have a list of my request, but can't see none in facebook.
What I have done so far:
used the fb_graph gem ( https://github.com/nov/fb_graph )
u = FbGraph::User.me(User.find(2).fb_access_token)
u.app_request!(:message => 'punk message')
After that if I do u.app_requests, I can see a list of requests.
As this seems not to work I after tried the Facebook JS SDK, and the result is the same.
My Question is: What am I doing wrong, or missing something?
Thank you
The more I'm around it, the more I'm favoring the Javascript SDK over server side code. Is there a reason for your app to require to do anything serverside, or can you accomplish the same thing client side? Can you give us an example of the Javascript code you tried that failed?
Related
I found the source of my problem for SuperAgent (http://visionmedia.github.com/superagent/) on Firefox. Not sure if SuperAgent is doing it in its AJAX call or if FireFox is triggering it.
Essentially, every time I make an AJAX call an OPTIONS method is being fired on the URL before the actual AJAX call. Quite annoying since the server currently doesn't support OPTIONS. How can I make a call without it going to crap and re-coding the server?
Thanks
Ok found out some more details. Thankfully testing on Safari gave me more insight into what was actually happening and I applied my knowledge here.
It seems to be the standard that browsers are calling an OPTIONS method before making an actual AJAX call. Seems a bit overbearing.
So to get around it I simply added a catch-all in my reverse proxy server to handle each OPTIONS call. You can see the question below for the code:
Play! 2.0 easy fix to OPTIONS response for router catch-all?
And if you want to read up more on why browsers are doing this, see here:
Why am I getting an OPTIONS request instead of a GET request?
OPTIONS is from the CORS standard.
Disabling web-secuty in phantomjs also helped to resolve this problem (--web-security=no). Because I didn't have access to API server to make changes for OPTION method.
I have a web application that crashes on ajax requests with google chrome (it works with every other web browser it was tested it). After debugging I found that the error is caused by response.responseText being undefined. The xhr object looks like this:
argument: undefined
isAbort: false
isTimeout: undefined
status: 0
statusText: "communication failure"
tId: 3
In debugger in the 'network' tab I get "(failed)", however all the headers are there and I can even copy into clipboard the response body (which is a valid JSON).
My question is - how can I debug this problem? Where to find additional information, what causes this request to fail?
I finally found the solution to my problem : AdBlocks, when it blocks an ajax request, it just says "communication failure".
The first thing I would double-check is that the data coming back from the response is valid JSON. Just pass it through a JSON validator like this online JSONLint: http://jsonlint.com/
I assume that you are using something like jQuery to make your AJAX requests. If so, then make sure that you are using the development version of that library. Now that you are using the development version (uncompressed) of the script, find the particular function that you are using (eg. $.ajax) and then, within the Chrome inspector, insert a breakpoint in the code where the AJAX response is first handled (eg. https://github.com/jquery/jquery/blob/master/src/ajax.js#L579). Then proceed to step through the code, inspecting various return-values to see exactly what is going wrong.
If you are not using something like jQuery to make AJAX calls, then I'd recommend using a framework to avoid possible cross-browser compatibility issues like you might be experiencing right now.
I'm using Sinatra 1.2.6 in Ruby 1.8.7 and I have something like a Twitter client that I'm writing. I am using the Twitter gem version 1.7.2 written by John Nunemaker. For database ORM I'm using Sequel 3.29.0.
Overall, things are working great. I've got a good Oauth sequence working and any user who goes through the Oauth process can post Tweets to my application.
I cannot however for the life of me get media upload working using update_with_media. I'm trying to upload a multi-part octet-stream image file, keep it in memory and then give it to Twitter.
post '/file_upload' do
user_name = params[:user]
if params[:action] == "FILE-UPLOAD"
unless params[:name].match(/\.jpg|png|jpeg/).nil?
#Assume these 3 lines work, and properly authorize to Twitter
current_user = User[:user_name => user_name, :current_account => "1"]
client = current_user.authorize_to_twitter #Handles the Oauth keys/process
client.update("Text status updates work properly")
#Something incorrect is happening in the next two lines.
#I'm either handling the file upload wrong, or posting wrong to Twitter
datafile = params[:file]
client.update_with_media("File upload from Skype: ", datafile)
return "File uploaded ok"
end
end
end
Yet, when I try this, I'm getting:
Twitter::Unauthorized - POST https://upload.twitter.com/1/statuses/update_with_media.json: 401: Could not authenticate with OAuth.
Its saying the line causing this error is the client.update_with_media line.
I am trying to use Rack::RawUpload, but I don't know if I'm using it incorrectly. If I don't need to use it I won't, but I'm just currently stuck. The only thing outside of this code snippet that's using it is this at the top of my code:
require 'rack/raw_upload'
use Rack::RawUpload
Any help on this would be massively appreciated. I've tried messing around with Tempfile.new() as well, but that didn't seem to help much, and I was either getting 401 or 403 errors. I'm fairly new to Ruby, so being as explicit as possible about changes needed would be really helpful.
I should note that I'd like to avoid putting the file on the filesystem if possible. I'm really just passing along the upload here, and I never need access in my scenario to the file on-disk afterward. Keeping the files in-memory is much preferred.
You need to check how your library HTTP headers are setup and logically connected to the POST method you have written here. The thing is that for upload_with_media, twitter api in this gem version requires you to use http://upload.twitter.com upload endpoint instead of the default api endpoint.
The gem may be forcing the api site so while the OAuth based status update works fine, it crashes when you try it with an image. You will need to check the gem documentation to figure out how to force the upload twitter site into the HTTP headers for this method.
Alternatively, consider updating to the latest twitter gem. This is what I got from http://rdoc.info/gems/twitter
The Twitter::API#update_with_media method no longer uses the custom upload.twitter.com endpoint, so media_endpoint configuration has been removed. Likewise, the Twitter::API#search method no longer uses the custom search.twitter.com endpoint, so search_endpoint configuration has also been removed.
My FBML based app suddenly stopped working since Nov.18.2011. It was working fine before that. And nothing has changed from our side. Could that be some of the new changes Facebookk put in on Nov.18 ( http://developers.facebook.com/blog/post/600/ ). Does anyone else has the similar problem? Any ideas on how to fix it?
Thanks a lot!
My FBML app stopped working around this day too. The problem is that they switched to the new auth system, where instead of sending the fb_sig HTTP parameters to identify the user and verify that the request came from Facebook, they now send one single parameter called signed_request. Which language/library are you using to interface with Facebook? See https://developers.facebook.com/docs/authentication/signed_request/ for more details on this new signed_request parameter.
There are several topics about the problem with cross-domain AJAX. I've been looking at these and the conclusion seems to be this:
Apart from using somthing like JSONP, or a proxy sollution, you should not be able to do a basic jquery $.post() to another domain
My test code looks something like this (running on "http://myTestdomain.tld/path/file.html")
var myData = {datum1 : "datum", datum2: "datum"}
$.post("http://External-Ip:port", myData,function(return){alert(return);});
When I tried this (the reason I started looking), chrome-console told me:
XMLHttpRequest cannot load
http://External-IP:port/page.php. Origin
http://myTestdomain.tld is not allowed
by Access-Control-Allow-Origin.
Now this is, as far as I can tell, expected. I should not be able to do this. The problem is that the POST actually DOES come trough. I've got a simple script running that saves the $_POST to a file, and it is clear the post gets trough. Any real data I return is not delivered to my calling script, which again seems expected because of the Access-control issue. But the fact that the post actually arrived at the server got me confused.
Is it correct that I assume that above code running on "myTestdomain" should not be able to do a simple $.post() to the other domain (External-IP)?
Is it expected that the request would actually arrive at the external-ip's script, even though output is not received? or is this a bug. (I'm using Chrome 11.0.696.60 )
I posted a ticket about this on the WebKit bugtracker earlier, since I thought it was weird behaviour and possibly a security risk.
Since security-related tickets aren't publicly viewable, I'll quote the reply from Justin Schuh here:
This is implemented exactly as required by the spec. For simple cross-origin requests http://www.w3.org/TR/cors/#simple-method> there is no pre-flight check; the request is made and the response cannot be read if the appropriate headers do not authorize the requesting origin. Functionally, this is no different than creating a form and using script to make an off-origin POST (which has always been possible).
So: you're allowed to do the POST since you could have done that anyway by embedding a form and triggering the submit button with javascript, but you can't see the result. Because you wouldn't be able to do that in the form scenario.
A solution would be to add a header to the script running on the target server, e.g.
<?php
header("Access-Control-Allow-Origin: http://your_source_domain");
....
?>
Haven't tested that, but according to the spec, that should work.
Firefox 3.6 seems to handle it differently, by first doing an OPTIONS to see whether or not it can do the actual POST. Firefox 4 does the same thing Chrome does, or at least it did in my quick experiment. More about that is on https://developer.mozilla.org/en/http_access_control
The important thing to note about the JavaScript same-origin policy restriction is that it is something built into modern browsers for security - it is not a limitation of the technology or something enforced by servers.
To answer your question, neither of these are bugs.
Requests are not stopped from reaching the server - this gives the server the option to allow these cross-domain requests by setting the appropriate headers1.
The response is also received back by the browser. Before the use of the access control headers 1, responses to cross-domain requests would be stopped dead in their tracks by a security conscious browser - the browser would receive the response but it would not hand it off to the script. With the access control headers, the server has the option of setting the appropriate headers indicating to a compliant browser that it would like to allow certain origin URLs to make cross domain requests.
The exact behaviour on response might differ between browsers - I can't recall for sure now but I think Chrome calls the success callback function when using jQuery's ajax() but the response is empty. IIRC, Firefox will not invoke the success function.
I get the same thing happening for me. You are able to post across domains but are not able to receive a response. This is what I expected to be able to do and happens for me in Firefox, Chrome, and IE.
One way to kind of get around this caveat is having a local php file with will call the data via curl and respond the response to your javascript. (Kind of restated what you said you knew already.)
Yes, it's correct and you won't be able to do that unless you use any proxy.
No, request won't go to the external IP as soon as there is such limitation.