I'm using the Facebook connect login API for desktop apps presented here:
http://wiki.developers.facebook.com/index.php/Authorization_and_Authentication_for_Desktop_Applications
I'm finding that the parameters I pass arent working correctly. Here's an example of the URL I use for the site:
http://www.facebook.com/login.php?api_key=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&connect_display=popup&v=1.0&next=http://www.facebook.com/connect/login_success.html&cancel_url=http://www.facebook.com&fbconnect=true&return_session=true&req_perms=publish_stream
If the user logs in correctly, they are redirected to
http://www.facebook.com/
instead of the value in the next parameter. This is particularly frustrating since the url of the site they were redirected to is supposed to contain login information.
Amazingly, the cancel_ url parameter works fine and sends the user to the correct target (I tried multiple cancel_url values inside of the facebook.com domain and they worked). Anybody dealt with this?
Is the API Key valid? Is your callback url set correctly in the application ? the next parameter is seeming to be ignored on non Internet Explorer Browsers.
Actually the next parameter was messing up the code in IE, so i removed the next parameter. What I did is storing the redirect back url in session and used a file to handle all facebook logins in all my domains.
http://digitalpbk.blogspot.com/2009/08/facebook-auth-next-parameter-ie.html
Related
I have a tracking issue due to GCLID gets stripped when users get redirected from our desktop site to our mobile site. Let me know how we can get this fixed.
Here's a sample:
When a user is detected as using a mobile device, they are redirected automatically. For example, if they were going to sitename.com/, they would instead end up on sitename.com/?___store=mobile2
The problem we are encountering is that we need certain query parameters from the original URL to be preserved when the redirect happens in order for tracking to work correctly.
If someone clicks a Google ad, they'll be taken to a URL with a gclid parameter appended by Google, for example: sitename.com/?gclid=ABC_123-abc
However, if the user is on a mobile device, they'll be redirected to sitename.com/?___store=mobile2. As you can see, the gclid parameter is no longer present.
Let me know if you guys have any solution to this. Thanks a lot.
The code that performs the redirection needs to preserve query parameters on the original request. In your case, it should also append an "&" and the ___store=mobile2 parameter.
I'm using the Facebook login dialogue for login to my website (with the PHP SDK), but it always fails the first time a new user authorises the app and succeeds the second time they try.
I'm finding that the state parameter isn't being passed back to me in the redirect url after a user authorises my app, which causes the CSRF check to fail in my app (in getCode() in the SDK). For what it's worth, the code parameter is included.
However, if they follow the dialogue link a second time, it works as expected - no further authorisation click is required, and the redirect url is correct, with both state and code parameters.
So my question is:
How can I find out what is causing the state to be missing from the redirect after authorisation?
For reference, my dialogue link looks like this:
https://www.facebook.com/dialog/oauth?client_id=MY_CLIENT_ID&redirect_uri=http%3A%2F%2Fwww.mysite.com%2Fconnect&state=4f246904818d682a742c59cbbced829c&scope=email%2Cuser_likes
As Igy said, it was a bug on Facebook's side, fixed now: https://developers.facebook.com/bugs/587975411230466
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Play Framework appending #= to redirect after Facebook auth via OAuth2?
Has anyone else seen this happen?
I am building a Facebook canvas app using the Facebook PHP SDK, and some Javascript.
Now when I take the user through the OAuth authentication flow, I have noticed that the URL in the browser automatically gets appended with this "#_=_" , so my URL starts looking like this:
http://apps.facebook.com/xxxxxxxxxxxx/#_=_
and when I redirect to the app profile page the URL is this:
http://www.facebook.com/apps/application.php?id=xxxxxxxxxxxx#_=_
I am redirecting using
echo "<script type='text/javascript'>top.location.href='$appcanvasurl';</script>"
to the canvas URL, and
echo "<script type='text/javascript'>top.location.href='$appprofurl';</script>"
for app profile page.
So why is this #_=_ getting appended?
Update:
According to this bug on the tracker, this is by design, and giving a value for the redirect_uri does not change this.
And according to the official facebook reply on that page (have to be logged in to Facebook to view the post):
This has been marked as 'by design' because it prevents a potential security vulnerability.
Some browsers will append the hash fragment from a URL to the end of a new URL to which they have been redirected (if that new URL does not itself have a hash fragment).
For example if example1.com returns a redirect to example2.com, then a browser going to example1.com#abc will go to example2.com#abc, and the hash fragment content from example1.com would be accessible to a script on example2.com.
Since it is possible to have one auth flow redirect to another, it would be possible to have sensitive auth data from one app accessible to another.
This is mitigated by appending a new hash fragment to the redirect URL to prevent this browser behavior.
If the aesthetics, or client-side behavior, of the resulting URL are of concern, it would be possible to use window.location.hash (or even a server-side redirect of your own) to remove the offending characters.
See This:
https://developers.facebook.com/blog/post/552/
Change in Session Redirect Behavior
This week, we started adding a fragment #_=_ to the redirect_uri
when this field is left blank. Please ensure that your app can handle
this behavior.
As per the Authentication Documentation, I'm directing my user's to the following URL to initiate the authentication flow:
https://www.facebook.com/dialog/oauth?client_id=251747341532139&redirect_uri=https://www.facebook.com/connect/login_success.html
However, instead of the login page looking like:
... (i.e. like it does in the documentation and in other Apps I've created and used), it looks like this...
Does anyone know why?
I've tracked the redirects that the page makes, and it's as follows:
https://www.facebook.com/dialog/oauth?client_id=251747341532139&redirect_uri=https://www.facebook.com/connect/login_success.html
https://www.facebook.com/connect/uiserver.php?app_id=251747341532139&method=permissions.request&display=page&next=https://www.facebook.com/connect/login_success.html&response_type=code&fbconnect=1
https://www.facebook.com/login.php?api_key=251747341532139&skip_api_login=1&display=page&cancel_url=https://www.facebook.com/connect/login_success.html?error_reason=user_denied&error=access_denied&error_description=The+user+denied+your+request.&fbconnect=1&next=https://www.facebook.com/connect/uiserver.php?method=permissions.request&app_id=251747341532139&display=page&redirect_uri=https%253A%252F%252Fwww.facebook.com%252Fconnect%252Flogin_success.html&response_type=code&fbconnect=1&from_login=1&rcount=1
Application type is set to Native/Desktop, and I've set the App Integration to "Website".
If the language I'm using makes any difference, I'm using C#, and setting the Url of System.Windows.Form.WebBrowser.
As per the above comments, you can use the display parameter in the URL to control which kind of dialog to show, as you would normally do with the JS SDK.
Your URL becomes:
https://www.facebook.com/dialog/oauth?client_id=xx&redirect_uri=yy&display=popup
A customer site that I cannot change has the line document.domain = "example.com" while the site is at www.example.com.
The effect is that FaceBook Connect window login gets stuck after submitting username+password.
Firebug shows its in infinite loop inside dispatchmessage function, which gives perpetual exception:
Error: Permission denied for <http://www.example.com> to get property Window.FB from <http://example.com>
Any idea how to work around this? I prefer not to ask the customer to remove the document.domain='example.com'
It seems like a really bad idea to tell the visitor's browser that the website is being served from a particular domain, when it in fact is not. The best solution would be to change that line. I take it you don't want to change it because they have some client-side code that depends on this?
One workaround would be to change the Facebook application's Connect URL to http://example.com, since Facebook's JavaScript will think that is where it is being executed.