I have html code containing FB profile pictures/clicable and etc/.
Using
fb:profile-pic and FB.XFBML.parse
I receive image url with HTTP. To have HTTPS I'm using:
https://graph.facebook.com/user_id/picture?return_ssl_resources=1
but have to generate code to make image clickable and add other attributes existing in fb-profile-pic.
I wrote this code 4 months ago.
Now I'm seeing fb:profile-pic is returning HTTPS link to image. Nothing is mentioned in FB documentation about change in behaviour/HTTP or HTTPS/.
Does anybody know about current state FB.XFBML.parse - secure or non secure links?
By default the protocol of the returned profile picture URL is the same as the protocol used to request the image.
So https://graph.facebook.com/zuck/picture will return the SSL version of Mark’s profile picture, while http://graph.facebook.com/zuck/picture will return an HTTP URL.
return_ssl_resources can be used with both, with value 0 for an HTTP and 1 for an HTTPS URL.
Does anybody know about current state FB.XFBML.parse - secure or non secure links?
I think the JS SDK should be able to decide this automatically, based upon the protocol the embedding page was requested with.
Related
I created a responsive app and a native app: the native app is basically just a UIWebView containing the responsive app.
How can i check on server side (php, etc..) where the request comes from?
Is there any possibility to modifiy requests sent from UIWebView or something else?
I see two possible approaches:
URL parameter
You could have a parameter in your URL to indicate the source of the request.
For instance, if the URL if your web app is
http://myserver.com/mypath
you could use the following URL in your native app's UIWebView:
http://myserver.com/mypath?src=native
On server side, you can retrieve this paramerer, e.g in PHP:
$src = $_GET['src'];
if ($src == 'native') {
// Request from native app
}
If your app has multiple pages, then you should modify the way your links are created to propagate this parameter when navigating from one page to another one.
Cookie
In the native app, you could manually set a custom cookie which would be sent along your requests and which you would retrieve on server side.
The following post may help you for that: Is it possible to set a cookie manually using sharedHTTPCookieStorage for a UIWebView?
There are many other question related to this, but they didn't help me fix my problem.
I'm using the Facebook server-side login for a website, which I want to test locally. The path that initiates the login action is [http://localhost:8080/fblogin] (this redirects to the Facebook login dialogue, and goes from there).
I can successfully get the code, but when I try to exchange that for an access token, I get the following error:
{"error":{"message":"Missing redirect_uri parameter.","type":"OAuthException","code":191}}
I am providing the redirect_uri, url encoded and it is the same as the one I use to get the first code. Here is the url I'm using to request the access token (with the all-caps query string parameters replaced with their actual values, of course):
https://graph.facebook.com/oauth/access_token?client_id=CLIENT_ID&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Ffblogin&client_secret=CLIENT_SECRET&code=CODE_FROM_FB
I suspect this might have to do with how my app is set up on Facebook. Here are the values I have set:
Display Name: (an actual display name here)
App Domains: localhost
Contact email: (an actual email here)
Site URL: [http://localhost:8080/fblogin]
What do I need to tweak in the settings to get this to work? Or does this look correct?
By the way, if it makes any difference, I am using the Play! framework, version 2.0.1
After digging around a little more, I found that it was necessary for me to use POST when sending the request from my server to get the access token.
Interesting that using POST worked for you as this didn't for me.
In any case, did you add the query parameters using setQueryParameter()? (see How to make multiple http requests in play 2?)
I'm trying to pass some variables to my facebook app from the url, i.e. using GET variable app_data like facebook wants.
At some point I've stopped getting the ['signed_request'] part of the $_REQUEST. When I print_r($_REQUEST) I'm getting: ['doc'], ['user'], ['__utmz'], ['__utma'] and ['session'] values, but not signed request :(
Any ideas of why this might be happening?
Check the tab/canvas url is EXACTLY the same as required. If there is a redirect to another page, then signed request and other values will not be sent. You can check using a browser sniffer, if a call to the page responds with a 300 (301/302 etc) redirect, then you need to change to what it redirects to.
Examples:
https://example.com/ may need to be https://www.example.com/ (add www., or remove www. depending on how server is set up)
www.example.com/ may need to be www.example.com/index.php (add index.php, or the right page).
Check you are using http:// and https:// correctly in the URLs, and that https:// returns a valid page.
I've only been able to get the signed request in https://, i get no request at all in http.
Currently have a bug on FB, but no word on fixing it yet; http://developers.facebook.com/bugs/264505123580318?browse=search_4eb3ef23eb18d6649415729
EDIT:
http://SITE.com was redirecting to http://www.SITE.com, so I was loosing the request variables.
Had a similar issue, for me it was as simple as a mismatch of the app id and app secret! However in facebook developers backend I have noticed that the URLs all need to have that trailing slash!
Some browsers do redirect your request to https automatically if you have been on this particular site on https so if you are in http mode on facebook there is situation:
facebook requests http version of your app, browser redirect this request of facebook to https and POST data and thus signer_request are gone in this process...
i see this problem in chrome 23, if you delete browsin data (particulary Deauthorize content licenses) app should run back on http
Is there a way to go to a url without redirecting to it? Basically I want to call a url from within my application in the background so it can logout a reliant party.
Appreciate the help.
What you are trying to do does not compete us to answer as it's directly related to your own Authentication implementation.
A normal ASP.NET Authentication based in Forms Authentication you will need always to lunch the url from a browser as it is there that relies the Authentication given.
You can give yourself a try by opening your website and log in into it, after that, open other browser brand (not browser window) into your application url... you will see that you also need to login again as the Authentication is hook up into the first browser.
It's Up to you as Application Architect to make this by implementing another way of authentication, normally in this kind'a cases, this happend when consuming web services where you need a authentication code first (given by calling a Login method) and that code is always needed to be appended to the body or header of any call to the system.
This way you can easily remove the authentication code and all procedure calls will fail.
As said, this is not up to us, it's up to you to create the correct Authentication Layer.
from your comment
it's as simple as using WebClient object
WebClient client = new WebClient ();
string reply = client.DownloadString (address);
If you wish to transfer to a new url request you can still use
Server.TransferRequest()
The problem with this is that by not using a redirect the browsers address bar will not reflect the fact that you have moved their request to another URL.
To have the client visit a given URL in the background you should either make an AJAX call to it or possibly have an image with an src of your logout url (though you'd have to make sure that you return a FileResult of your image too). This is how most analytics packages call to their relevant urls in the background.
The problem here though is that neither is 100% reliable, turn off javascript or images on your browser and these results fail.
From what you've said I think what you're after is for a user to continue to any of a variety of pages rather than a specific logout page. If this is indeed the case your best solution is in fact a double redirect.
Have your application redirect to your logout url but before hand put the url of the page you want them to go to into tempdata. Then in the actionresult for the logout page you can do your logging out as required and return a redirect to the url from tempdata.
I am wondering if there is a way to get facebook user profile image's real url in https.
Like I use https://graph.facebook.com/20926460/picture to get a the profile image,
It will redirect to http://profile.ak.fbcdn.net/hprofile-ak-snc4/41539_20926460_5421452_q.jpg.
Is there a way to get the "https" version of the second url? or is the url existing?
This might have changed in the docs since you last looked, I know everyone got excited about https after that snooping tool came out.
"If you need a picture to be returned over a secure connection, you can set the return_ssl_resources argument to 1: https://graph.facebook.com/xx_userid_xx/picture?return_ssl_resources=1."
Hopefully that won't redirect you.
Update 10 sept 2012
https://graph.facebook.com/20926460/picture now redirects to https urls.
You can just replace http by https in the target url but keep in mind that it is only temporary and may time out.
there is also no valid ssl certificate, but if you ignore that, the file will be served.
if you need a valid certified https url for pictures you need to set up a proxy script on your server that passes through the file.
edit:
as for your comment here is an example of what i meant by "proxy script".
you can put it on your server and request it with whatever protocl/scheme you like.
just like it was a local picture. you should probably validate the mime type. do some error handling and prevent injections etc. but just to give you ap icture:
<?
header("Content-Type: image/jpeg");
echo file_get_contents('https://graph.facebook.com/'.intval($_GET["id"]).'/picture');
fyi i put the int cast there to prevent injection hacking.
script is untested but should work as file_get_contents will follow redirects.