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.
Related
So I'm running a Laravel backend for my app, and for the last year Postman has been working like a charm, suddenly a couple of days ago it just stopped working.
I updated the app and nothing changed. It's the standalone app, not the Chrome browser extension. I turned off the SSL verification in the settings pane, but still no changes.
Any API request through Postman only doesn't return anything, works fine in the actual website in Chrome.
Any suggestions would be greatly appreciated!
Thanks
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/.
I published a web site: "https://www.mynotefy.com". Some users were not able to see the recaptcha screen on createaccount pageon chrome browsers.
Any reason why this is happening. No errors are being logged.
"if we use https in chrome, recaptcha not showing. If we use just http, recaptcha is showing".
How do we fix this issue ?
Thanks,
Here are the warnings I get in the Console of Chrome Developer Tools:
[blocked] The page at https://www.mynotefy.com/Account/CreateAccount ran insecure content from http://fonts.googleapis.com/css?family=Istok+Web:400,700,400italic,700italic|Rokkitt:400,700.
[blocked] The page at https://www.mynotefy.com/Account/CreateAccount ran insecure content from http://www.google.com/recaptcha/api/challenge?k=6Lci-doSAAAAAHuBYSQjNhr-qgvdqkXuVqn7OtS3.
My guess is that your page is an HTTPS and these links are HTTP, so that's why they are being blocked.
SCENARIO:
I have a java web app running in the latest Tomcat 6. I also have a single servlet filter that provides authentication. I support BASIC auth and it appears to work fine - most of the time.
The first time a browser [pick any one - IE, FireFox, Opera, Safari, Chrome] hits one of our protected URL(s), it displays the standard browser-specific login prompt. IFF you enter the proper username/password - everything is fine, a new session is created, and everything operates normally.
IF, however, you entered invalid credentials in the initial BASIC auth dialog, my authentication filter logic handles this by returning another 401 response.
PROBLEM:
Unfortunately, at this point, Chrome is the only browser that will display another BASIC auth dialog. All other browsers listed automatically send the cached "Authorization: Basic.." header - instead of clearing it and prompting the user again.
If anyone has seen this or may know why this is happening, I would greatly appreciate any suggestions!
Thanks and Best Regards,
Bob
problem solved:
After looking over my code again, I found a point where a 401 was being returned without also setting the WWW-Authenticate HEADER.
-bob
When I am calling a REST service through AJAX, its working fine. I am calling it with the URL staring with HTTP e.g.: http://www.myserver.com/customers. Its works really great.
But when I am calling a same URL but with HTTPs e.g.: https://www.myserver.com/customers,
I am not getting any response from server.
Its not working for GET or POST both.
Its not working in Mac firefox, actually I am developing an application for iPhone using phonegap framework.
Its also not working in iPhone simulator's mobile safari.
Can anyone here know what problem is this? And how to solve this?
The requesting domain must match the requested domain down to the protocol, according to the Same Origin Policy
It could probably be because of same origin policy. read
http://en.wikipedia.org/wiki/Same_origin_policy