Facebook api adding # _ = _ to my return uri

Question

I use facebook php library to authenticate users in my application, it works fine, but for some reason facebook adds #_=_ characters to the end of my uri return. I read that they did it if the redirect_uri parameter was not set, but I installed it, in fact I was redirected to this URL successfully after logging in to facebook.

This is how I get the login url:

 $fbLoginUrl = $fb->getLoginUrl(array( 'scope' => 'email,publish_stream,user_birthday,user_photos,friends_photos', 'redirect_uri' => 'http://myapp.net/auth' )); 

Everything works fine, it's just a cosmetic thing, I think. Can anybody help me?

Thanks in advance!

Answer 1

The Facebook developer blog said that if you explicitly set the redirect_uri parameter, you will not get #_=_ added to the callback url. But this is not so. You still get these characters even when setting the redirect_url field. But this will not affect your flow.

Note this: Redirect Behavior Session - setting redirect_uri explicitly

Answer 2

You can only get rid of this client side.

You might think that you can solve this server side by redirecting the URL without binding:

• facebook redirects to http://MyFacebookRedirectUrl...#_=_
• Then we are redirected to some new URL without binding

.... But #_=_ reappears in magic in the address bar of the browser - how?

See James Pierce answer at http://developers.facebook.com/bugs/318390728250352 :

"Some browsers will add a hash fragment from the URL at the end of the new URL to which they were redirected (if this new URL does not have a hash fragment).

as well as this:

http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx

Firefox, Chrome, and Opera [and now IE10] reattach the Fragment URL after HTTP / 3xx redirection, although this fragment is not in the URL indicated by the location of the redirect response header

So, if you just do server side redirects from your Facebook redirect page, you will have to remove this client side.

Another alternative is to redirect the server side to a URL that contains a different named anchor, but this does not actually solve the problem, and not all browsers will do the same.