At the moment I am attempting to share a link on Facebook without the use of JavaScript or a Facebook app id.
Previously I could have a hyperlink to: https://www.facebook.com/sharer/sharer.php?u=urlhere and Facebook would scrape for og:tags and allow me to share a site.
At the moment I'm encountering a 500 error when I attempt to submit a link that has not previously been crawled by Facebook.
How to reproduce the bug
Find a new link that you're certain hasn't been crawled by FB. Good examples of this are tweets.
Attempt to visit https://www.facebook.com/sharer/sharer.php and paste in your link
Submit the form and see the post preview
Attempt to submit the post
If you've used a fresh URL there is a good chance you'll get a 500 error similar to: POST https://www.facebook.com/ajax/sharer/submit_page/ 500 (Internal Server Error)
If you refresh the page and attempt to submit the same URL again, it will post successfully.
Once the link has been crawled by Facebook, it works without problems
Anyone having similar problems with this method of sharing?
This is a valid Facebook bug, see https://developers.facebook.com/bugs/795945327148024/.
Related
I'm following the instructions given on this page:
https://stocktwits.com/developers/docs/authentication
I've managed to get the client id, client secret and the code without any problems (up to step 4). However, when trying to exchange these for an access token, I'm getting a blank page.
The instructions specify that the return is a json format response - maybe there are some browser settings that I need to check to allow this?
thanks in advance for any pointers.
Judging by the title of this post "returning a blank page" it sounds like you are trying to make this request through the browser. The page you referenced says that the request must be a POST request and browsers cannot make POST requests.
On the step you're stuck on (step 5) there is a link that says "View the token call" that links here https://stocktwits.com/developers/docs/api#oauth-token-docs which shows how to make this POST request using curl.
I am newbie Parse and I have a problem. I want to use parse classes for dynamic content such as blog posts. Everyting works as expected there is no problem ; but when I try to fetch as google in Google Webmaster Tools it says AJAX blocked. So google will not index this content anyway.
when I follow the link I saw this below.
this is what I see when follow class link
So google crawler try to get ajax content but it comes to it with a ConnectionFailed aka 100 error. (I tested it to show in a label on page what returns in parse query error callback. So I see what renders google)
Am I doing something wrong is this an expected behaviour ?
Anyone knows how to solve this ?
Btw: I am hosting this website on heroku with custom domain over https (with cloudflare dns redirected and free ssl)
I also deployed to Parse Cloud Hosting unfortunately the result is same :(
This is the full result of the Fetch as Google :
full page result of fetch as google
The page at https://api.parse.com/1/classes/GameScore is asking for authentication, and it's throwing a 401 Unauthorized status code for unauthorised requests. That's already a problem.
Besides that, the page at https://api.parse.com/robots.txt is currently showing
User-Agent: *
Disallow: /
Googlebot can't access that page because it's disallowed for crawling in the first place, but even if it could access it, it would run into an authentication gate which it wouldn't be able to pass.
If the content from that URL (https://api.parse.com/1/classes/GameScore) is essential for the page where its referenced/used, you would have to work with Parse to allow crawlers access those URLs.
If it's not essential, then you can safely ignore that warning.
I am trying using facebook from Scrapy.
I can log in successfully. However, I can't get the posts on facebook because the posts comes from ajax calls.
I tried using firebug and check the XHR. I got this:
I tried to check the response of all those request but none of them contains the actual data of the posts.
What is the ajax request that get the posts on facebook?
Thanks in advance
Don't use the AJAX calls from your browser. Those are encrypted since Facebook uses HTTPS connections. Focus on using their API to make the calls you need to get the data you want. That's the entire purpose of their Graph API.
I have an ASP.NET MVC4 sub web application added in to an existing ASP.NET WebForm web site. the whole website is using forms authentication.
In my MVC4 client side, I use Backbone.js for building the application, and the client application is most likely a SPA.
Everything works fine, but after session timeout my application does not redirect to log-in page.
I tried the error callback on Collection.fetch method, it was triggered (which is good) when trying to fetch after session time out.
However, the response status code is 200 (OK) with response content is the log-in page content.
So, my question is, in error handler how do I know whether the callback is triggered by session timeout or any other unexpected error?
If determined, how should I do to let Backbone redirect page to log-in page while referring current page?
Here is something what Phil Haack had blogged about
Exceprts from the post :
Possible Solutions
I’m going to cover a few possible solutions I’ve seen around the web and then present the one that I prefer. It’s not that these other solutions are wrong, but they are only correct in some cases.
Remove Forms Authentication
If you don’t need FormsAuth, one simple solution is to remove the forms authentication module as this post suggests. This is a great solution if you’re sole purpose is to use ASP.NET to host a Web API service and you don’t need forms authentication. But it’s not a great solution if your app is both a web application and a web service.
Register an HttpModule to convert Redirects to 401
This blog post suggests registering an HTTP Module that converts any 302 request to a 401. There are two problems with this approach. The first is that it breaks the case where the redirect is legitimate and not the result of FormsAuth. The second is that it requires manual configuration of an HttpModule.
Install-Package MembershipService.Mvc
My colleague, Steve Sanderson, has an even better approach with his MembershipService.Mvc and MembershipService.WebForms NuGet packages. These packages expose ASP.NET Membership as a service that you can call from multiple devices.
Some more info from comment of this blog
We had the same problem. But what we did, was to hook to AuthenticateRequest (just like you did) and we also checked the request to see if it's ajax or not (again, just like what you did). But at this point, we simply returned a JSON like {location: 'http://www.domain.com/path-to-login-page'} and we simply ended response in that method with HTTP code 200. This way, jQuery still gets a JSON result. But if the result has a "location" property, we simply do a client-side redirect to login page. That's our way and it works like a charm.
I've got a strange problem with my Analytics Windows Phone App. It's been 2 months now from the first release. My Google Oauth always worked... until several days ago.
It is impossible to authorize the app to access Analytics data anymore. And I've changed totally nothing!
The first URI I use is:
https://accounts.google.com/o/oauth2/auth?redirect_uri=http:// localhost
&response_type=code
&client_id=*myClientAppId*
&approval_prompt=force
&scope=https://www.googleapis.com/auth/analytics.readonly
&access_type=offline
It's the same as https://developers.google.com/oauthplayground/. The Web Explorer shows me the login form, and then the authorization form. When I tap "Authorize access", it redirects me to a 404 page.
I don't know why, it always worked before.
EDIT: OK, this works in Google Chrome. It gives me a 404 at the end but the code is in the browser URI.
EDIT 2: It works in Firefox too! But not in Internet Explorer. Google has modified something that doesn't fit IE! As it is IE in Windows Phone, I'm out of luck.
EDIT 3: This is the URL from Windows Phone IE during the process:
https://accounts.google.com/o/oauth2/auth?redirect_uri=http://localhost&response_type=code&client_id=*clientID*&approval_prompt=force&scope=https://www.googleapis.com/auth/analytics.readonly&access_type=offline
https://accounts.google.com/ServiceLogin?service=lso&passive=1209600&continue=https://accounts.google.com/o/oauth2/auth?scope=https://www.googleapis.com/auth/analytics.readonly&response_type=code&access_type=offline&redirect_uri=http://localhost&approval_prompt=force&client_id=*clientID*&hl=fr-FR&from_login=1&as=-f41460280d51b31<mpl=embedded&shdf=Cp8BCxIRdGhpcmRQYXJ0eUxvZ29VcmwaAAwLEhV0aGlyZFBhcnR5RGlzcGxheU5hbWUaGkFuYWx5dGljcyBmb3IgV2luZG93c1Bob25lDAsSBmRvbWFpbhoaQW5hbHl0aWNzIGZvciBXaW5kb3dzUGhvbmUMCxIVdGhpcmRQYXJ0eURpc3BsYXlUeXBlGhJOQVRJVkVfQVBQTElDQVRJT04MEgNsc28iFJZQrUSzSBUX1XVpZxx-K_xFjAA7KAEyFBX1s-5Zjlet_038EBgHpUrtzMWT&scc=1
https://accounts.google.com/ServiceLoginAuth
http://accounts.google.fr/accounts/SetSID?ssdc=1&sidt=ALWU2cvavauNt1Z0SXgI2DX+i+T5G1snNnu5C+aq/NBExAfG+WenK3WQRLVDLUWqsRcCCbj6c1b1qoZUOQminXYpKJMQzl6FWmuTgA8rVQYtaK5tatpCXffmlXh9CLec/zn8SUijYZILc7vwN9ByicxS1vSyFGvuoteb7wfDiemkcbvaPjfQZ4PrfmEWtl/Us+Gua+ePdTMc9tHFllBYj3TUZDiL7H1FmfPe1nE4jPyteAnGcF500lFyGSYAftGVpsMRQZiJ+4qVhGcgBrFrySpb92sVTq5FGTrQmqryhvhwQF6Sy6SJbq1CqgiavbsZbfwrvZIWVq31&continue=https://accounts.google.com/ServiceLogin?passive=true&go=true&continue=https%253A%252F%252Faccounts.google.com%252Fo%252Foauth2%252Fauth%253Fscope%253Dhttps%253A%252F%252Fwww.googleapis.com%252Fauth%252Fanalytics.readonly%2526response_type%253Dcode%2526access_type%253Doffline%2526redirect_uri%253Dhttp%253A%252F%252Flhttps://accounts.google.com/ServiceLogin?passive=true&go=true&continue=https://accounts.google.com/o/oauth2/auth?scope=https://www.googleapis.com/auth/analytics.readonly&response_type=code&access_type=offline&redirect_uri=http://localhost&approval_prompt=force&client_id=*clientID*&hl=fr-FR&from_login=1&as=-f41460280d51b31&shdf=Cp8BCxIRdGhpcmRQYXJ0eUxvZ29VcmwaAAwLEhV0aGlyZFBhcnR5RGlzcGxheU5hbWUaGkFuYWx5dGljcyBmb3IgV2luZG93c1Bob25lDAsSBmRvbWFpbhoaQW5hbHl0aWNzIGZvciBXaW5kb3dzUGhvbmUMCxIVdGhpcmRQYXJ0eURpc3BsYXlUeXBlGhJOQVRJVkVfQVBQTElDQVRJT04MEgNsc28iFJZQrUSzSBUX1XVpZxx-K_xFjAA7KAEyFBX1s-5Zjlet_038EBgHpUrtzMWT&service=lso<mpl=embedded&fss=1
https://accounts.google.com/o/oauth2/auth?scope=https://www.googleapis.com/auth/analytics.readonly&response_type=code&access_type=offline&redirect_uri=http://localhost&approval_prompt=force&client_id=*clientID*&hl=fr-FR&from_login=1&as=-f41460280d51b31&pli=1&auth=DQAAAIMAAAAw6WtQDD3JKEg_qAs6neUVzWA5ixsW0ido7pIOrK5KRLnHA-_QQhVd7RzSelpNhkhCVJxVGSEgQpZINeKa29lwivfu-Rbu-vuM1uR4U-JC3EJZEwDMIMuva19_KNsd83ihmeYcuGbnBvUR5iln1KhZZIvhUkbS9CjVwLRdwbMRG5nRHO-oJruBkuezuntX8Iw
https://accounts.google.com/o/oauth2/auth?scope=https://www.googleapis.com/auth/analytics.readonly&response_type=code&access_type=offline&redirect_uri=http://localhost&approval_prompt=force&client_id=*clientID*&hl=fr-FR&from_login=1&as=-f41460280d51b31&pli=1
https://accounts.google.com/o/oauth2/approval?as=-f41460280d51b31&hl=fr_FR&xsrfsign=APsBz4gAAAAAUHsS0dCApfLAWpZILWjeTNZSt6DUZzug
404 error -> https://accounts.google.com/o/oauth2/
On Chrome, same URIs, but when I click on "Authorize", I get localhost with the code for the token.
I believe in WP, embedded IE webview has javascript disabled by default. There's a simple webview API call to enable JS before starting the webview. At this point, we can only reproduce this bug in browsers that do not execute JS.
More specifically, see: http://msdn.microsoft.com/en-us/library/microsoft.phone.controls.webbrowser.isscriptenabled(v=vs.92).aspx on how to enable JS.
We've identified an issue with our server that we hope to fix soon for the way we report an error when JS is not enabled on the client.
Clients that do not have javascript enabled will not be able to submit the OAuth approval form going forward. The error you're seeing, with the 302 to the 404 is a redirect bug in our error page that explains this requirement.
In addition, we have tested windows phone 7 IE on our page and recreated your issue. At this point we assume is related to JS in the client. We're looking into this and hope to have a fix soon.