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.
Related
TLDR: I have a site protected with Okta SAML authentication, but somehow during my redirect and authentication phase, the redirect, which is a parameter in the URL, gets lost. Looking for advice.
Background:
I have a Linux server with Apache using Mellon to connect to Okta for SAML authentication.
I have a url like this:
https://docs.example.com/current/readme
I have a redirect.php file at the root of example.com that redirects the user to something like
https://docs.example.com/docs/version/Default.php#cshid=readme
That is the generated output URL for context-sensitive help, which in turn redirects the user to something like:
https://docs.example.com/docs/version/content/readme.php
That all works if you are already authenticated with SAML. However, if you aren't already authenticated, you get sent to Okta.
https://success.example.com/login/login.htm?fromURI=%2Fapp%2Fssoexample_docsexamplecom_2%2Fexk4g2c3ofeuJWRSu4x6%2Fsso%2Fsaml%3FSAMLRequest%3DhZJfT8IwFMW%252FytJ3aBljaAMkAyTBqDHgn8QX0pSLNG7t7G0Rv73tFhVf8KnN7Tm553fSEYqqrHnh3V6v4N0DuulSA3Em%252BLmymiTL%252BZhsslk6HE6nxbTH8sHVIOvnLGWzxXSYXxbZBVuQ5pYanRCuzBiaa%252FD8k46eOgNOevxjL2QZB4YlBauce2dq5FTil5KQOweQIud6kpTUW2TUji%252BZa%252Bp7Jsd%252BOvkycxohJjhHK1sRVx6a8PZUVVdKqkcSRbGSmhKH5OdKBEi2n1oRx3gZ1J8lxWX%252BQrsGuxBSXhc3fyCxdynVBWUpdG0NuhWgHVMQCajGJo35dnJeeeInmpH7fe4C2jL%252Bb0J6T9j9kr8Qx4natvZNVLurNCoQgOBKez4mFkQLnA664HQSbvy7yecfAE%253D%26RelayState%3Dhttps%253A%252F%252Fdocs.example.com%252FDocs%252Fcurrent%252FTopNav%252FDefault.php#cshid=readme
So, at the end of that URL, the hash and parameter are retained: #cshid=readme
However, after I successfully log in, somehow the URL looses the #cshid=readme and just redirects me to:
https://docs.example.com/docs/version/Default.php
Any ideas how I can make it retain the hash and the content after the hash? I'm not the person who configured mellon or Okta, but I'd like to have a solution in mind before I contact them with my issue.
In case someone else comes across a similar issue, there are a couple of possible solutions to these scenarios.
Replacing the # with ?. In this context, https://docs.example.com/docs/version/Default.php?cshid=readme
Encoding the # as %23 (still not likely to work in most cases). https://docs.example.com/docs/version/Default.php%23cshid=readme
It is expected that everything after the # is dropped. Fragment parameters are used only on the client-side, but the server will ignore it, which is why Okta is ignoring that portion of the URL.
Using ? instead of # will usually solve most issues.
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?)
Looking through some legacy code I have in front of me using struts one, I see:
<global-forwards>
...
<forward name="accessDenied" path="/www/jsp/AccessDeniedForm.do" redirect="true" />
</global-forwards>
So it's just a global forward to send to a access denied page.
I am curious about the decision to redirect as opposed to forward. What are the advantages and disadvantages of using it?
What are the pro's and con's of using it?
Before discussing pro's and con's of using that forward element with redirect set to true, let's understand what is actually going on with that configuration. When redirect is set to true in the forward element, a redirect instruction should be issued to the user-agent so that a new request is issued for this forward's resource. This link will probably provide detail information that you need.
The default value for redirect is to false, essentially when the forward element is called, it forward to that path specified and that's it. If you are setting redirect to true, take for example, the browser will make another request. So I think with these said, you probably know or have an idea the pro and con if you really want to use it.
In redirect, the control can be directed to different servers or even another domain name.The redirect takes a round trip.When a redirect is issued , it is sent back to the client , and redirected URL information is in the header instructing the browser to move to the next URL. This will act as a new request and all the request and response data is lost.
In forward , the forwarding is done from server side , the client browser URL do not change.the data is also not lost.It is just like a browser page refresh. Whatever data posted in the first submit is resubmitted again.So use it with caution.
Both forward and redirect are used in different scenarios ,the global forward should be redirect because it is an error situation.
Redirect is slower as it needs a roundtrip.Forwards are faster.
If you specify
redirect="true", Struts uses a client-side redirect
[response.sendRedirect()]
. The JSP will be invoked by a new browser request, and any data stored in the old request will be lost.
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
I need to include some secure (BASIC authentication) application.
when I open the application URL in the browser, the browser asks me to enter your credentials ...
what I know is that:
The browser ask the server to get
some URL -- the url of the app
The server checks the request header
for the Authentication header and
didn't find it
The server sends 401 to the
browser back
The browser interpret this response
code into a message dialog that
shows to me asking me to enter the
username/password to send back to
the server in the Authentication
request header
So far... so good, I can write some page (in JSP) that send this required http request header to the request that is calling this page..
So I'll call this application through my page..
The problem here is, this application (in fact a GWT application) contains a reference to some Javascript and CSS files that is coming from the server that hosts this application. the application page that I import looks like:
<html>
<link href="http://application_host/cssfile.css" />
<link href="http://application_host/javascriptfile.js" />
.....
</html>
So, again I found the application asks me for the authentication crenditals for the css and js files!
I am thinking of many solutions but don't know the applicability of each
One solution is to ask the browser
(via Javascript) to send the request
header (Authentication) when he
asks the server for the js and css
files
please give me your opinions about that... and any other suggestions will be very welcomed.
Thanks.
I think you're running into some weirdness with how your server is configured. Authentication happens in context of a authentication realm. Your assets should either be in the same authentication realm as your page, or (more likely) should not require authentication at all. The browser should be caching credentials for the given realm, and not prompt for them again.
See the protocol example on http://en.wikipedia.org/wiki/Basic_access_authentication
Judging from your story, something tells me your problem is with the authentication method itsef. Not how to implement it. Why do you want to bother with the request header so much?
As far as i know, you can configure your container (ie Tomcat) to force http authentication for certain urls. Your container will make sure that authentication has taken place. No need to set http headers yourself whatsoever.
Perhaps you can explain a bit better what you are trying to achieve, instead of telling implementation details?
Why css & js files are kept in protected area of server? You need to place files into public area of your server. If you don't have public area, so you nead to prpvide for it. how to do it depends from serverside software architecture & configuration.