I started to receive the following error a couple of weeks ago while creating or updating contacts, using Google Contacts API, authenticating using ClientLogin, coding using Delphi with Indy HTTP stack. The application used to work perfectly before that. Note that the application is fully using HTTPS following Google recent changes in that space (it actually worked for a few weeks after such changes got enforced). Reading contacts is still working.
HTTP Content-Type is set to 'application/atom+xml'.
Google Contacts URL being used is 'https://www.google.com/m8/feeds/contacts/default/full'.
<?xml version="1.0" encoding="UTF-8"?>
<errors xmlns="http://schemas.google.com/g/2005">
<error>
<domain>GData</domain>
<code>parseError</code>
<internalReason>Parse Error</internalReason>
</error>
</errors>
I don't know which kind of "parsing error" got introduced.
Did something recently changed in that space?
Understood that ClientLogin is deprecated, but is OAuth 2.0 now mandatory to actually update contacts?
Are you including the Unicode BOM in the content payload? This can sometimes cause a parseError.
Related
I have a static website on an Azure web server/portal that holds our company's documentation. Recently, I've been making changes to our code that sets our cookies to ensure that they comply with the browser SameSite requirement as explained here:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite
I've been able to fix all my scripts that create my cookies, but while testing them today, I see that there's this cookie message that still appears in my FireFox console:
Cookie “ARRAffinity” will be soon rejected because it has the
“sameSite” attribute set to “none” or an invalid value, without the
“secure” attribute. To know more about the “sameSite“ attribute, read
https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite
This message only appears when I clear the cache from the site and load the page. Once I reload the page a second time or load any other page after that, I no longer see the message.
I believe this ARRAffinity cookie technically comes from Azure's Application Insights (AI)--or something on the Azure web server. It doesn't appear in our javascript files at all. We use AI for our analytics. Here is the code snippet that we got from Azure about two years ago. It gets injected into the header of each .htm page on our site:
var appInsights=window.appInsights||function(a){
function b(a){c[a]=function(){var b=arguments;c.queue.push(function(){c[a].apply(c,b)})}}var c={config:a},d=document,e=window;setTimeout(function(){var b=d.createElement("script");b.src=a.url||"https://az416426.vo.msecnd.net/scripts/a/ai.0.js",d.getElementsByTagName("script")[0].parentNode.appendChild(b)});try{c.cookie=d.cookie}catch(a){}c.queue=[];for(var f=["Event","Exception","Metric","PageView","Trace","Dependency"];f.length;)b("track"+f.pop());if(b("setAuthenticatedUserContext"),b("clearAuthenticatedUserContext"),b("startTrackEvent"),b("stopTrackEvent"),b("startTrackPage"),b("stopTrackPage"),b("flush"),!a.disableExceptionTracking){f="onerror",b("_"+f);var g=e[f];e[f]=function(a,b,d,e,h){var i=g&&g(a,b,d,e,h);return!0!==i&&c["_"+f](a,b,d,e,h),i}}return c
}({
instrumentationKey:"<The Key>"
});
window.appInsights=appInsights,appInsights.queue&&0===appInsights.queue.length&&appInsights.trackPageView();
(Note that <The Key> in the snippet above is actually a unique multi-character string that Azure gave us when we set up and configured the AI resource. I removed it here for privacy.)
I've since revisited the site where I got that code, but the snippet has changed to something newer:
https://learn.microsoft.com/en-us/azure/azure-monitor/app/javascript#snippet-based-setup
I'm not sure if I need to do anything to fix this.
Does ARRAffinity cookie come from some server-side script that Microsoft creates?
Do I need to do anything on my side to resolve this console message? If so, what?
ARRAffinity cookie is automatically created by Azure. You can turn it off by going to Configuration --> General Settings and then click on Off in the App Service as shown below.
As your's is a static website, i don't think this would be an issue. In fact, it is recommenced to turn ARR Affinity to Off for any Cloud Native applications.
When ARR Affinity is turned off, all the App Service instances (in a load balanced env) will be used effectively.
If ARR Affinity is turned on, all the requests for a given session will be sent to the same server irrespective of the load on it.
By default, the setting is on to to support legacy applications that needs Session stickiness.
Suddenly linkedin oauth2 stopped working! As per instructions found here:
https://developer.linkedin.com/docs/oauth2
When invoking this:
https://www.linkedin.com/oauth/v2/authorization?response_type=code&client_id=75jdo0an3ktnbx&redirect_uri=https://app.myapp.com/account/linkedin_login&state=fregfdgfasd&scope=r_basicprofile%20r_emailaddress
Instead of a valid response I get a 400 error:
LinkedIn
Invalid HTTP Request
Could not process this client request HTTP method request for URL. Please double-check the URL (address) you used, or contact us if you feel you have reached this page in error.
I am experiencing the same problem using Chrome, but not with Edge or Firefox. Contacted LI, reply was we are working on it, no estimate of when we will solve it. The new profile update seems to be botched in Chrome, OK with Edge and still not updated to the new look if using Firefox.
Linkedin has problems far deeper than poor coding, they forgot the meaning of being social in networking, the site is becoming a pile of stale resumes, non-existent debates and bad quality networking.
I am not OAuth fluent enough to tell you why, but they have 2 different systems: oAuth and oAuth legacy.
I personaly couldn't find a way to retrieve a valid token from OAuth but yes from OAuth legacy. The main difference is the URL and the authorization window.
You are actually using : https://www.linkedin.com/oauth/v2 for you api calls.
OAuth legacy is using https://www.linkedin.com/uas/oauth2.
The whole process is the same so you won't have to change your code, just the URL.
see OAuth legacy doc: linkedin.com/docs/oauth2-legacy
The bad side is the authorization window, the user has to literaly login (email + password) before clicking on the 'Authorized' button and being redirected to your callback URL.
I am agree, this website has something buggy. When visited from France (browser language set to FR-fr and an IP geolocalised in France), their whole interface is written in Dutch ...
Anyway, i hope it helps
I work for a large educational institution and we used the YouTube api v2 for uploading YouTube videos to our corporate channel. We now have to implement v3 alongside other changes. I have a few questions:
Question 1: Oauth2
With api v2 we were able to upload directly to our YouTube channel with the credentials stored in the web.config file. But from what I understand this will no longer be possible with the use of oauth2. A popup form will ask the user to enter the credentials. Is this correct? If so, is there another method we might use, as many department will have the ability to upload videos, and for security purposes we would like to keep the channel login secret.
Question 2: Google.Apis.YouTube.v3 nuget package Sample Code & Port number
I downloaded the sample project at: https://github.com/youtube/api-samples/tree/master/dotnet , and using VS2013, is able to compile the project, but a browser windows opens (suspect it is the oath2 permissions window) complaining about a Error: redirect_uri_mismatch . From other Google searches I determined that it is because the port number changes every time I run the project and thus does not match the redirect uri set in the Google developers console. How would I go about getting the sample code to run?
Question 3 - Proxy
I haven't gotten so far that this might actually be a problem, but just in case it will be, I am adding this to the question list. We have a proxy server with proxy authentication. Will this be an issue (if I do finally get the sample code to run)?
Thank you
Found the answers after hours of scouring websites and documentation.
Question 1:
Yes there is a method. IE Get an offline refresh token and use that to gain access. See:
OAuth 2.0 Playground
Generating a refresh token for YouTube API calls using the OAuth playground
Question 2:
I was using the wrong credentials, use installed.
Question 3:
Yes it was an issue, solved it by adding this to the web.config file:
<system.net>
<defaultProxy useDefaultCredentials="false" enabled="true">
<proxy usesystemdefault="False" autoDetect="False" proxyaddress="yourproxy" />
</defaultProxy>
I've searched the site but can't find anything that exactly matches this situation.
Cliff's Notes:
Trying to implement Federated login on GAE, using the sample python code at https://developers.google.com/appengine/docs/python/users/, with a custom OpenID Provider. GAE returns either at HTTP 500 or HTTP 204 depending on the server setup. There are no entries in the application logs on the admin console. Most likely it is a problem to do with the XRDS file and the discovery process. I'd appreciate any suggestions as to a cause or possible debugging methods. Thanks in advance.
Problem Details:
The code works fine when using the following providers in the 'federated_identity' parameter of the users.create_login_url() function:
https://www.google.com/accounts/o8/id
yahoo.com
aol.com
myopenid.com
The issues start when trying to use our own custom OpenID Provider. We have set up the OpenID plugin on a couple of Wordpress installs on different hosts for testing purposes. The plugin makes use of XRDS-Simple to publish the XRDS document at domain.com/?xrds. Example document contents:
<?xml version="1.0" encoding="UTF-8" ?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)" xmlns:simple="http://xrds-simple.net/core/1.0" xmlns:openid="http://openid.net/xmlns/1.0">
<XRD xml:id="main" version="2.0">
<Type>xri://$xrds*simple</Type>
<!-- OpenID Consumer Service -->
<Service priority="10">
<Type>http://specs.openid.net/auth/2.0/return_to</Type>
<URI>https://goff.wpengine.com/index.php/openid/consumer</URI>
</Service>
<!-- OpenID Provider Service (0) -->
<Service priority="0">
<Type>http://specs.openid.net/auth/2.0/server</Type>
<URI>https://goff.wpengine.com/index.php/openid/server</URI>
<LocalID>http://specs.openid.net/auth/2.0/identifier_select</LocalID>
</Service>
<!-- AtomPub Service -->
<Service priority="10">
<Type>http://www.w3.org/2007/app</Type>
<MediaType>application/atomsvc+xml</MediaType>
<URI>https://goff.wpengine.com/wp-app.php/service</URI>
</Service>
</XRD>
I have verified that the OpenID provider works by using it to log in to other OpenID enabled sites, including other Wordpress installs with the OpenID plugin and Stackoverflow.
When using the login link http://api.lighthouseuk.net/_ah/login_redir?claimid=https://goff.wpengine.com/?xrds&continue=http://api.lighthouseuk.net/ GAE returns a HTTP 500 error after several seconds. We haven't found any reason for this - there are no log entries in the admin console - but I suspect it may have something to do with the configuration on wpengine.com not returning the XRDS file or caching an incorrect one.
We have semi-confirmed this by running an identical setup on our dev server which has no caching enabled. Now when we visit the login link GAE returns a HTTP 302 response followed by a HTTP 204 response: http://www.google.com/gen_204?reason=EmptyURL.
As far as I can tell, after requesting the XRDS file GAE makes no further requests to our server. This leads me to believe that there might be a problem with the XRDS file but I can't find any details in the documentation about required attributes.
Things tried:
Login on other systems
If you send an authentication request to the URI specified in the XRDS document the OpenID server responds correctly by prompting the user to log in. Again this suggests that GAE takes issues with the XRDS file because no authentication request is made to our server. I can't figure out how to debug it when there are no errors recorded in the logs.
e.g. https://goff.wpengine.com/openid/server?openid.ns=http://specs.openid.net/auth/2.0&openid.claimed_id=http://specs.openid.net/auth/2.0/identifier_select&openid.identity=http://specs.openid.net/auth/2.0/identifier_select
&openid.return_to=http://api.lighthouseuk.net/checkauth&openid.realm=http://api.lighthouseuk.net/&openid.mode=checkid_setup
SSL
Obviously for a production environment we would be using SSL on both Wordpress and GAE but currently this is just a proof of concept. cURL, by default I believe, attempts to check the validity of SSL certificates so we've tried various combinations of SSL setting, including having none at all. Seemingly no effect.
Wordpress permalinks
As the XRDS document, by default, points to /index.php/openid/server/ we attempted different combinations of permalink setting in Wordpress to see if it had any effect. It didn't.
URL encode
URL encoding the claimid seemed to have no effect - we still received the HTTP 204 response.
After giving up for a while I revisited this issue and managed to solve it. Answering here in case anyone else faces the same issues. Ultimately it was down to my use of secure URLs.
TL;DR
It should have been the first thing I checked but, make sure you have an SSL certificate on your server so that the OpenID server is accessible via a secure URL. You will get a HTTP 500 error from GAE if the URL is not secure or if the SSL certificate does not validate (Obvious in hindsight but, this caught me out on a different test site with a custom generated SSL certificate).
In addition, make sure that the XRDS document contains said secure address in the <URI> element.
Setup Details
Using OpenID plugin Version 3.3.4
Using XRDS-Simple plugin Version 1.1
Wordpress version 3.8
Hosted on WPEngine.com
Google App Engine instance running the gae-boilerplate code (federated identity enabled)
Modifications
I played around with fiddler2 to see if I could learn anything more about the requests made to and from GAE. I compared the access logs from my OpenID server on WPEngine with the data I could pull from fiddler2 about the stackexchange OpenID server (openid.stackexchange.com).
XRDS-Simple Plugin
I modified this plugin to include an additional filter for the Wordpress HTTP headers:
add_filter('wp_headers', 'xrds_add_xrds_location');
function xrds_add_xrds_location($headers) {
error_log('Adding XRDS header', 0);
$headers['X-XRDS-Location'] = get_bloginfo('url').'/?xrds';
return $headers;
}
After that I modified the xrds_write() function to simply return the following xml:
<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS
xmlns:xrds="xri://$xrds"
xmlns:openid="http://openid.net/xmlns/1.0"
xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service priority="10">
<Type>http://specs.openid.net/auth/2.0/server</Type>
<Type>http://openid.net/extensions/sreg/1.1</Type>
<Type>http://axschema.org/contact/email</Type>
<URI>http://goff.wpengine.com/index.php/openid/server</URI>
</Service>
</XRD>
</xrds:XRDS>
This got rid of the http://www.google.com/gen_204?reason=EmptyURL redirect and simply returned a HTTP 500 error.
Curious, I tried various different things to get any response out of GAE (remember GAE does not show error that occur in the /_ah/ handlers.
As a last resort I modified the <URI> element to be https instead of http. This did the trick! I was successfully redirected to goff.wpengine.com and was asked to verify that I wanted to login. Excited, I clicked verify. PHP Fatal error: Call to a member function needsSigning() on a non-object. Balls. At least now I could ascertain problems from the PHP error log.
OpenID Plugin
After some quick Googling I found a thread on Google Code for the OpenID plugin. People had had similar issues and the consensus was that it was due to a plugin conflict. Comment #55 from user infinite.alis mentioned that adding the Relying Party to the user's 'Trusted Sites' consistently solved the problem. Lo and behold, after adding the address to my trusted sites the entire authentication flow completed without error!
Conclusion
I have yet to do a post mortem to figure out which of the changes to XRDS-Simple made the difference. I suspect that simply changing the <URI> element in XRDS-Simple to https would solve the problem (My previous tests with SSL only focused on making sure the users.create_login_url() function was passed a secure address, not that the XRDS file described the OpenID server via a secure address). Possibly need to play around with the filters for get_bloginfo('url') in the xrds_write() function.
What this is NOT
a) a "sensor=true_or_false" issue
b) a key is wrong issue (unless the key I got has limitations)
c) too many requests (since I only make one request)
d) cross domain (since I load the url from the browser location bar)
What I did
Signed up http://code.google.com/apis/maps/signup.html
Tried the example on that page in the location bar (I know about cross domain from script)
works fine
Read the documentation
Pasted their example exchanging their key for mine
returns
{
"html_attributions" : [],
"results" : [],
"status" : "REQUEST_DENIED"
}
So far all entries failed due to wrong key or sensor=true_or_false
And for example the url in this one Google Places API jQuery.ajax() request fails with working URL
also gives me error when pasted into the browser.
What did I miss?
UPDATE
So I went to get some keys
Key for browser apps (with referers)
API key:
AIzaSyCStj9m5LNTu9mCf6cQGDVAFKZC7Y?????
Referers:
Any referer allowed
Activated on: Jan 30, 2012 1:03 PM
Activated by: me
and tried again. Still does not work.
This is actually (b): wrong key. Actually, you're using the wrong kind of key (from Sign Up for the Google Maps API which is only good for the JavaScript V2 API).
Please see Obtaining an API Key for how to get a new API key, of the new kind.
Edit: At the time this question arose, valid API keys that worked on Geocoding API did not work on Places API, but now seem to work fine. Looks like some issue on Google side.
I just got a REQUEST_DENIED response when making an autocomplete request in a Ruby app. It turned out that I had not specifically switched on the Places API in my google api console.
Go to: https://console.developers.google.com and login.
In the left menu go to "APIs & auth" -> "APIs"
Then find the "Places API" option and click on the status to the right to toggle it to "on"
This fixed the problem immediately for me.
Ohkay this worked for me and i know it will work as we are making the same mistake.
First go to API's and enable the google places api for web.
After that, go to credentials and in the credentials where your key is showing, click on it.
After clicking, in the restrictions tab, choose what will be the API will be doing.
Set that up, restart your script and voila... it will be done.
I faced the same issue. But was able to resolve it after enabling the Places API from Google console. I used the 'server' key to make a call from application. Hope this helps for others looking for solution.
This issue has been discussed on many threads here... but the bottom line is you should check your code to see if u are sending out too many requests at a time to the google API.
You are only allowed to send 1 request per 1 minute.
MKErrorDomain error 4 iPhone