This started happening over the last weekend that FB notification page is no longer embedding the [app_id] in the acceptance URL and throwing a 404 when clicked on the "request" link on this page:
(Sent Today)
http://apps.facebook.com/224695104250620/?request_ids=161817803905540&ref=notif
Notice that how it is different than what we used to get earlier (and the working version):
(Sent September 21)
http://apps.facebook.com/piratesapp/?request_ids=10150329048068535&ref=notif
I've gone back and re-checked Facebook documentation on "Requests Dialog":
http://developers.facebook.com/docs/reference/dialogs/requests/
and found that it clearly states the working version:
http://apps.facebook.com/[app_name]/?request_ids=[request_ids]
None of the app settings changed on our part and all on a sudden, the strange # started showing up in place of [app_name]. We've verified that it's not app_id as it doesn't match with any of our registered apps. The behavior appears to be the same across apps, apps across different Facebook developer accounts and so on.
Is this a bug? Should I file a bug with Facebook? I wanted to check with the experts here before logging a bug.
Appreciate a prompt response on this.
Ok looks like this is a bug:
https://developers.facebook.com/bugs/209695662429264
Related
Tried connecting to https://brandonchen1.github.io/ after github said your site is ready to be published. Tried opening website in different browsers and the repository is https://github.com/BrandonChen1/BrandonChen1.github.io.
Can anyone help me figure out why the webpage is still displaying a 404?
Stumbled upon this question when my pages weren't getting published. Posting what I did in case someone else runs into this too.
Check GH's status as suggested by this community question and make sure everything is green.
Then check your repo's Actions tab. Under Workflows, look for pages-build-deployment or something similar and check for any errors in the runs. The Actions page can be found at https://github.com/<username>/<repo name>/actions.
I've been researching all over trying to fix this issue to no avail. I followed the SwiftyDropBox tutorial thoroughly and had everything working. It's now not working and I'm not sure why. Based on this post and this link, the error is supposed to be related to not having the DropBox app installed. That's fine. In the tutorial it says:
If you wish to authenticate via the in-app webview, then set browserAuth to NO. Otherwise, authentication will be done via an external web browser.
I set that parameter to false and still get the same error.
Turns out the issue was that I already had a viewcontroller being presented. It looks like the dropbox authorization acts as a "presentation". It worked once I dismissed the viewcontroller. Those error messages still appear but according to this post it's normal behavior. I wish they'd have more descriptive messages.
This error message is displayed when native Dropbox app is not installed in the phone and can be ignored. See response from Dropbox forum
I'm receiving reports of several users running into issues with a django-registration sign up flow. I'm not able to reproduce it, and I believe it's just happening for certain browsers.
The problem happens when they follow the email activation link. Although the database shows they have successfully activated their email, they see the page that says that the link has expired. It's as if they visited the activation page already and then are seeing it for the second time. Initially I thought this was user error, but several users have reported it, which makes me think there is something else up.
One user has reported it working in Firefox, but not Safari, on a desktop - and not working on iPad or iPhone.
I have used django-registration a lot so I'm surprised by this bug and am drawing blanks about what it might be down to. Anyone have any ideas?
PS This is also happening with the same site, perhaps related: Django messages faulty, but only on one particular network
Our desktop application integrates with Facebook using the desktop app workflow and for approx. 18 months has been working without any problems. However, we are starting to get reports from some users that they cannot get past the login process.
When the login is successful Facebook should be attaching the access_token to the redirect_uri. Our application detects this and moves the user to the main part of our Facebook integration. What appears to be happening in some situations is that the access_token parameter is missing which causes our application to leave our embedded browser window open with the following message from Facebook:
"Success
SECURITY WARNING: Please treat the URL above as you would your password and do not share it with anyone."
What is strange is that this does not occur with all Facebook accounts and which Facebook accounts it occurs with seems to be changing. For example, we had a report of this approx. 1 week ago but could not duplicate it with my own Facebook account or with a colleague's Facebook account. Today, I still cannot duplicate it with my own Facebook account but my colleague now gets the problem.
The URL our code sends to Facebook is:
https://graph.facebook.com/oauth/authorize?client_id=xxxx&redirect_uri=http://www.facebook.com/connect/login_success.html&type=user_agent&display=popup&scope=read_friendlists,user_photos,friends_photos,user_photo_video_tags,friends_photo_video_tags,user_events,friends_events,user_groups,friends_groups
Reading the latest API documentation it looks like they recommend a different way to connect which we have also tried:
https://www.facebook.com/dialog/oauth?client_id=xxxx&redirect_uri=http://www.facebook.com/connect/login_success.html&scope=read_friendlists,user_photos,friends_photos,user_photo_video_tags,friends_photo_video_tags,user_events,friends_events,user_groups,friends_groups&response_type=token
To rule out our application as the cause we have tried these URLs directly within a web browser. What we find is that when using my Facebook account the browser re-directs to the success URL that includes the access_token parameter but when using my colleague's account the browser re-directs to the success URL that includes the access_token and then immediately re-directs again to the success URL without the access_token.
so... As far as we can tell this is either:
a) A change to the API which we cannot find documented anywhere
b) A bug in Facebook
c) Something that is now controlled by the user's Facebook security settings
Is there anybody who could explain why Facebook is acting differently with different accounts and how we can go about fixing this?
Thanks.
Kevin.
I have the same problem in my desktop applications.
And I just solve it with careful reading in ht*ps://developers.facebook.com/docs/howtos/login/login-for-desktop/. The solution is to change redirect_uri from ht*p://www.facebook.com/... into ht*ps://www.facebook.com/...
Hope this will help you just like it help me
NB:
change ht*p into http
sorry i have to change the http into ht*p so that i can post the answer.
We have a Facebook app that publishes URLs to a user's newsfeed via the Facebook iOS SDK. These URLs are for pages that have OpenGraph attributes defined and we've verified in the Facebook Linter that it's correctly defined.
However, periodically we are seeing that Facebook won't correctly parse the OpenGraph attributes and have less than a stellar post to Facebook:
We will most often get posts parsed correctly resulting in posts like these:
We'll periodically get posts like these:
However, you can see this later post works correctly in the FB Url Linter: https://developers.facebook.com/tools/debug/og/object?q=http%3A%2F%2Fchewsy.com%2Fr%2Fa%2F1bhLT.
However, sometimes the URL Linter will report a 503 but I see nothign in our logs. And even more odd, when the URL Linter reports the 503, it will shows that it can read the OpenGraph attributes defined. See this screenshot:
Since this is inconsistent, my first guess was this was a Facebook issue so I opened a bug. However, since I'm not seeing this issue rampant in the newsfeed with other apps, I'm starting to wonder if we aren't following the right steps to publishing FB content.
For example, are we supposed to post to the URL Linter first, then publish via the Graph API? This seems like a ridiculous extra step, but I'm grasping at straws here...
It's probably due to fact that in a time Facebook Linter visited your site it wasn't accessible, just couple of refreshes on a Linter Tool with URL you've provided resulted in Bad Response Code error, returning 503 status code:
http://chewsy.com/r/a/1bhLT"">
You should dig in logs of your application/site to discover the real reason why this happen and fix it.
Just a quick note that this should no longer be happening for CloudFlare users. We pushed a fix for the 503 debugger issue moments ago that appears to have fixed the problem. Please contact us if you see any other issues with the Facebook Debugger.