Google Natural Language API has been working in my iOS app up until yesterday. The API started returning "permission denied" errors as of this morning. E.g:
{
"error": {
"code": 403,
"message": "The caller does not have permission",
"status": "PERMISSION_DENIED"
}
}
Example request:
POST /v1/documents:analyzeEntities?key=..... HTTP/1.1
Host: language.googleapis.com
Content-Type: application/json
Connection: keep-alive
X-Ios-Bundle-Identifier: .....
Accept: */*
Accept-Language: en-us
Content-Length: 291
Accept-Encoding: gzip, deflate
User-Agent: CardScanner/1 CFNetwork/808.2.16 Darwin/15.6.0
{"encodingType":"UTF8","document":{"type":"PLAIN_TEXT","content":"....."}}
Billing is enabled for the account (with a balance of $0). The account also has 36 days left on the trial period.
The key matches the value in the Google Cloud Platform API dashboard. I have also tried regenerating the key, and using the new key in the app.
I have also tried enabling key restrictions for iOS devices, and included the "X-Ios-Bundle-Identifier" header with the app bundle identifier.
The app also uses the Google Vision API which works without issues. Calls to the Vision API do respond to changes to the key restrictions.
Calls made from the demo page also show a permissions error message. Calls from the API explorer do work however.
Edit:
The error is also happening on the demo on the product web page. Tracing the error in Charles shows the same "permission denied" response being returned to the web page:
Edit:
Below is an example of the HTTP request and response captured from the demo page. The request and resulting error is almost identical to my app, except that the demo seems to be using http 2, whereas my app is using http 1.
HTTP request:
:method: POST
:authority: language.googleapis.com
:scheme: https
:path: /v1/documents:analyzeEntities?key=.....
content-length: 250
origin: https://cloud.google.com
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
content-type: text/plain;charset=UTF-8
accept: */*
referer: https://cloud.google.com/natural-language/
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.8
{"document":{"type":"PLAIN_TEXT","content":"Google, headquartered in Mountain View, unveiled the new Android phone at the Consumer Electronic Show. Sundar Pichai said in his keynote that users love their new Android phones."},"encodingType":"UTF16"}
HTTP response:
:status: 403
vary: Origin
vary: X-Origin
vary: Referer
content-type: application/json; charset=UTF-8
content-encoding: gzip
date: Sun, 26 Feb 2017 14:52:24 GMT
server: ESF
cache-control: private
content-length: 128
x-xss-protection: 1; mode=block
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
access-control-allow-origin: https://cloud.google.com
access-control-expose-headers: content-encoding,date,server,content-length
alt-svc: quic=":443"; ma=2592000; v="35,34"
{
"error": {
"code": 403,
"message": "The caller does not have permission",
"status": "PERMISSION_DENIED"
}
}
We are aware of this issue and should be fixed now. Let us know if you still see the same problem.
I have experienced the same behaviour and I believe it is an undocumented change at Google's end.
I can now only make the call work via OAuth, despite the documentation suggesting that an API key is sufficient. Up until very recently it was possible to make a call with an API key only and no restrictions configured on the key.
My "answer" for what it's worth is to provide feedback on the documentation page to complain that the documentation doesn't match the behaviour. I think the wording on the page may have changed recently, but it still suggests an API key should work for testing purposes.
"TRY NATURAL LANGUAGE API" button from Google Cloud Vision API demo page doesn't work either! Looks like some bug, hope they fix it soon...
Related
We are building a smart home app using actions on google for the google home. Our app requires signing into our system to be able to access the users devices so they can control them using their voice over google home. Our user backend is built using AWS Cognito. We are using API.AI as part of the Google Home app.
I have configured the Cognito OAUTH2 endpoint and the actions on google app to work with each other using the auth code flow and varying scope's but there is something I am missing. When I attempt to link the user account to the Google Home app i get redirected to our login page. After filling out the user details I'm returned to the Google Home 'Discover' tab but there is a message across the bottom that states: ‘Bad response from IdP in Auth Code Exchange’.
I also have tried it using Google's OAUTH2 playground. It seems that when using that I am able to get the code from our OATUH server, but when trying to exchange the code for a token i get the following error:
HTTP/1.1 400 Bad Request
Strict-transport-security: max-age=31536000 ; includeSubDomains
X-content-type-options: nosniff
X-application-context: application:prod:8443
Transfer-encoding: chunked
Set-cookie: XSRF-TOKEN=35f58337-76f4-4993-a0c9-93429134ea42; Path=/; Secure; HttpOnly
Expires: 0
Server: Server
Connection: keep-alive
X-amz-request-id: 284d862e-b021-4079-b5f5-3cbce675983c
X-xss-protection: 1; mode=block
Pragma: no-cache
Cache-control: no-cache, no-store, max-age=0, must-revalidate
Date: Wed, 23 Aug 2017 13:51:42 GMT
X-frame-options: DENY
Content-type: application/json;charset=UTF-8
{
"error": "invalid_client"
}
I have checked and rechecked the client ID and client secret etc and cannot find any errors.
Does anyone have any idea how I might fix this problem?
Thanks in advance
ok,may be i know the reason.....If you use aws cognito ...
According to this doc (http://docs.aws.amazon.com/cognito/latest/developerguide/token-endpoint.html)
Authorization
If the client was issued a secret, the client must pass its client_id and client_secret in the authorization header through Basic HTTP authorization. The secret is Basic Base64Encode(client_id:client_secret).
they need put client and client sectet in header ...
Then I use aws http proxy caught the request of google progress .
Method request headers: {X-Cloud-Trace-Context=d7b6b9b8239965baf69acab659e80a01/13879251242019662389, CloudFront-Viewer-Country=US, CloudFront-Forwarded-Proto=https, CloudFront-Is-Tablet-Viewer=false, CloudFront-Is-Mobile-Viewer=false, User-Agent=google-oauth-playground AppEngine-Google; (+http://code.google.com/appengine; appid: s~oauth2playground), X-Forwarded-Proto=https, CloudFront-Is-SmartTV-Viewer=false, Host=en75z5h2rb.execute-api.us-east-1.amazonaws.com, Accept-Encoding=gzip, deflate, X-Forwarded-Port=443, X-Amzn-Trace-Id=Root=1-5a0fcef2-09197cd86a625ad47d78f0b7, Via=1.1 d63a8908759a2f4775b3f672ebf823cc.cloudfront.net (CloudFront), X-Amz-Cf-Id=nFdLK97vAS5HvmpNYkPpbUMOB4bCaM6pScHWTAReAnonLg1gXF7hSg==, X-Forwarded-For=107.178.195.199, 54.182.238.53, content-type=application/x-www-form-urlencoded, CloudFront-Is-Desktop-Viewer=true}
There are no Authorization in request header. So the Cognito will return back
"error": "invalid_client"
According this OAUTH2.0 spec (https://www.rfc-editor.org/rfc/rfc6749#section-2.3.1)
I have already ask AWS support. They said:
Thanks for contacting AWS Support and providing us with detailed references. I would be happy to assist with your question regarding Cognito supporting client credentials in the request-body.
After reading through the OAUTH2.0 Standards RFC 6749 [0], It looks like including the client credentials in the request-body is not recommended. Here's an excerpt on the spec:
"Including the client credentials in the request-body using the two parameters is not recommended and should be limited to clients unable to directly utilize the HTTP Basic authentication scheme (or other password-based HTTP authentication schemes)."
HTTP digest authentication no longer works in our app since iOS 10 due to wrong nonce-count in Authorization: Digest header generated by NSURLSession.
The same code works in iOS 9, but fail to auth in iOS 10
Create a POST request with NSURLRequest
Fire it with NSURLSession
Handle NSURLAuthenticationMethodHTTPDigest in urlSession(_:didReceive:completionHandler:) delegate
The server responds with a 401 and qop="auth" string as expected
The app requests again with the Authorization: Digest header set.
According to RFC2617:
nonce-count
This MUST be specified if a qop directive is sent (see above), and
MUST NOT be specified if the server did not send a qop directive in
the WWW-Authenticate header field. The nc-value is the hexadecimal
count of the number of requests (including the current request)
that the client has sent with the nonce value in this request. For
example, in the first request sent in response to a given nonce
value, the client sends "nc=00000001". The purpose of this
directive is to allow the server to detect request replays by
maintaining its own copy of this count - if the same nc-value is
seen twice, then the request is a replay. See the description
below of the construction of the request-digest value.
However, the nonce-count start at "nc=00000002" even for the first request in iOS 10, which cause the server to reject it.
Expect server response 200 OK
iOS 9 & Before:
POST /Tunnel/Message.aspx HTTP/1.1
Host: 172.18.70.12:3454
Accept: */*
Content-Type: application/xml
User-Agent: iViewer/1 CFNetwork/758.5.3 Darwin/15.6.0
Connection: keep-alive
Cookie:
AuthType: digest
Accept-Language: zh-tw
Content-Length: 69
Accept-Encoding: gzip, deflate
Authorization: Digest username="admin", realm="ND8422P",
nonce="cc17a78cdd96d54e012eadefe7d13d82", uri="/Tunnel/Message.aspx",
response="51587db4bcf6eeece68c4ec21108f170",
cnonce="47b8df8a980f280038834b7817250e90", nc=00000001, qop="auth"
<?xml version="1.0" encoding="UTF-8"?><GetServerInfo></GetServerInfo>
HTTP/1.0 200 OK
Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
Content-Type: text/xml
Content-Length: 1127
iOS 10:
POST /Tunnel/Message.aspx HTTP/1.1
Host: 172.18.70.12:3454
Accept: */*
Content-Type: application/xml
User-Agent: iViewer/1 CFNetwork/808.0.2 Darwin/16.0.0
Connection: keep-alive
Cookie:
AuthType: digest
Accept-Language: en-us
Content-Length: 69
Accept-Encoding: gzip, deflate
Authorization: Digest username="admin", realm="ND8422P",
nonce="4b8bf8549da0c3010f031472e95f387d", uri="/Tunnel/Message.aspx",
response="91cf44bc0aadf2f743164d03b5c708c7",
cnonce="b5f9e6c69e19c1b396298d68f2aefe7e", nc=00000002, qop="auth"
<?xml version="1.0" encoding="UTF-8"?><GetServerInfo></GetServerInfo>
HTTP/1.0 401 Unauthorized
WWW-Authenticate: Digest qop="auth", realm="ND8422P", nonce="8e8b0538bb08876ac4d8203f1d14e9ac"
CSeq: 0
Is anyone facing the same issue?
The only related post I could find is:
Apple Developer Forums : Problem of the digest authentication, but no further information.
How do you fix it or get workaround on client app side without asking server side to ignore the wrong nonce-count?
Thanks.
Apple Developer Technical Support confirm that is a bug of iOS 10.
Hope it will be fixed soon.
Thank you for contacting Apple Developer Technical Support (DTS).
We believe this issue is a bug. Please file a bug report using the Bug Reporter tool https://developer.apple.com/bug-reporting/.
Update:
Apple fixed this issue in iOS 10.2 Beta 3
Chances are, the OS is sending a HEAD request first, and your server-side code isn't getting it. I would try running Charles Proxy to verify that this is what's happening.
That said, skipping a nonce count is not inherently an indication of any sort of attack. It could occur even in iOS 9 if a request got lost somehow (e.g. a network error). What's important is to ensure that the count doesn't go backwards. So I would argue that your server code is buggy and should not be rejecting that to begin with.
We have the same problem in our company as described here:
Cordova app can't connect with Dynamics NAV Web-Service (ODATA) after update to iOS 10
We can reproduce the issue both in our App and the Safari Browser with iOS 10 devices. There does not seem to be a simple client side workaround. We opened a Bug Report with Apple.
In our case the problem was solved with the 10.2 Beta release.
I was trying to integrate linkedIn oauth into my website, But I'm stuck on this error
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://www.linkedin.com/uas/oauth2/accessToken. (Reason: CORS header 'Access-Control-Allow-Origin' missing).
I'm getting this error when i was trying to get the accessToken using authorization code.
Request & response view from livehttpheaders are as follows
https://www.linkedin.com/uas/oauth2/accessToken
POST /uas/oauth2/accessToken HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Referer: https://www.clovedigital.com/oauth/oauth_lnk.pl?code=AQRLhiv3oDKfFdN2ccXtSCOaC3ujQncdJ1QeFYw_c6iQVvrvy_M4w13IYny3cIzpPWzBPmOaI8DMZFp8pjbBvJHeni4MhbF5ig27SLkmVUHHKQYwB2U&state=mbclqkji
Content-Length: 277
Origin: https://www.clovedigital.com
Connection: keep-alive
grant_type=authorization_code&code=AQRLhiv3oDKfFdN2ccXtSCOaC3ujQncdJ1QeFYw_c6iQVvrvy_M4w13IYny3cIzpPWzBPmOaI8DMZFp8pjbBvJHeni4MhbF5ig27SLkmVUHHKQYwB2U&redirect_uri=https%3A%2F%2Fwww.clovedigital.com%2Foauth%2Foauth_lnk.pl&client_id=xxxxxxxxxxxxx&client_secret=xxxxxxxxxxxxxx
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Content-Encoding: gzip
Content-Language: en-US
Content-Length: 220
Content-Type: application/json;charset=UTF-8
Even though the response code is 200, I haven't receive any accessToken as response. Instead I could see those Cross origin error message in console. Need help in resolving this issue
I know that this problem may be api specified but really need to try.
I have to requests. One made with ASIHTTP and the other one with AFNetworking. Server denies afnetworking with 401 code.
I have to adjust afnetworking to the working state, and have in mind that changes at the server side are impossible atm.
ASIHTTP (working one)
POST https://cant.post.address HTTP/1.1
Host: cant.post.address
Accept: application/json
User-Agent: My Application(iPhone; iPhone OS 6.1.3; pl_PL)
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Accept-Encoding: gzip
Connection: close
Proxy-Connection: close
Content-Length: 31
AFNETWORKING (getting denied with 401)
POST https://cant.post.address HTTP/1.1
Host: cant.post.address
Accept: application/json
Accept-Encoding: gzip, deflate
User-Agent: MyApp(iPhone; iOS 6.1.3; Scale/2.00)
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Accept-Language: pl;q=1, en;q=0.9, fr;q=0.8, de;q=0.7, ja;q=0.6, nl;q=0.5
Connection: keep-alive
Proxy-Connection: keep-alive
Content-Length: 31
There were some other headers but they were identical so I removed for simplicity. What could cause rejecting here? user-agent? Doubt that. What about Connection and Proxy-Connection? Can i change it to close in AFN?
401 is the HTTP status code "Unauthorized", which is sent back from the server when the provided credentials are invalid (incorrect username / password). Check that you're sending the correct information.
Also, JSON serialization is provided automatically when AFHTTPClient is configured correctly. See the example app in the AFNetworking repository to see how that is done.
I have task to provide my users with financial reports. My application is sharing profit with users for using special advertisement.
PayPal report page should actually be a PayPal site frame inserted into our site - which is the actual Paypal reporting system OF OUR PAYPAL ACCOUNT that shows the transfers for that specific user. Is it possible to do ? As I know PayPal is blocking frames or I'm wrong ?
If it is impossible I should provide some role to user when user sign up on my site ?
All PayPal URLs will break out of iframes. The X-FRAME header is set to SAMEORIGIN on all their sites. Do a search here and you'll see that:
HTTP Response Header
Name Value Delim
Status: HTTP/1.1 301 Moved Permanently
Date: Wed, 25 Jul 2012 13:16:27 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN
Set-Cookie: cwrClyrK4LoCV1fydGb [..]
Set-Cookie: cookie_check=yes; expires=Sat, 23-Jul-2022 [...]
Location: https://www.paypal.com/
Vary: Accept-Encoding
Content-Encoding: gzip
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html
You cannot (and should not try to) get around this.