I am testing the here.com location REST API. I have setup REST oAuth credentials in the developer portal and have successfully requested an oAuth token via Postman. When I try to use the token in the fuel prices API, I receive the error:
"These credentials do not authorize access"
oAuth POST request:
Authorization: OAuth oauth_consumer_key="wD7h-u8jE03c0jRu2m4XBQ",oauth_signature_method="HMAC-SHA256",oauth_timestamp="1600812281",oauth_nonce="npygZT9FJ9f",oauth_version="1.0",oauth_signature="fM6AsYnp9jKHlY6ESyKwUwqIHQik4ad6spUeiWAh2ag%3D"
User-Agent: PostmanRuntime/7.26.5
Accept: */*
Cache-Control: no-cache
Postman-Token: 169bc9d1-5ef6-46e6-aab8-d0d11d048d15
Host: account.api.here.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 29
Request Body
Response Headers
Date: Tue, 22 Sep 2020 22:04:42 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 911
Connection: keep-alive
Pragma: no-cache
X-Request-ID: REQ-b62ce9c9-eddd-4c03-8e67-186a56c031b1
Cache-Control: no-store
X-Frame-Options: DENY
X-Response-Time: 53
X-Correlation-ID: e0c4b375-8fed-4b70-be56-2d78c6f37e18
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self'
X-Permitted-Cross-Domain-Policies: master-only
Response Body
{"access_token":"eyJhbGciOiJSUzUxMiIsImN0eSI6IkpXVCIsImlzcyI6IkhFUkUiLCJhaWQiOiJaVjhwbGFFWDdRekd2VUNXbUdGbiIsImlhdCI6MTYwMDgxMjI4MiwiZXhwIjoxNjAwODk4NjgyLCJraWQiOiJqMSJ9.ZXlKaGJHY2lPaUprYVhJaUxDSmxibU1pT2lKQk1qVTJRMEpETFVoVE5URXlJbjAuLk8tRDdJQm9Mdzk5b1dxejJ1Vmx0Y1EuSmlYUmMwV0N6cVFUbVFicmhNaDNONkFENVJ6YWVMenFfdWpOWVZlekgyQ2dvbERLcFFEcUNrODFlMWFoMmlZZXZXZzFHNVhDZUtsZEc0WXhwX0pSU2lPaUkxUUNMRWZhakFscEFHQjdta0JLdjktbXllXzlqeDFGbzM2T0tUaDRuNXdxWEZVbnhtMkRYOHRQYjVZZUZBLl9qUlE0NU9PTmd3ZHpwY1c4cUxJck5hRmhYcTVLM1hzMHZzYl85MTFtVVU.R62C1fZVxt29r0VPA9jYVdWRbqO5lFH0yNtomCSxAnpTaHf4ed215u7o21RnwEjy-Dl2vgCAP8Oc4xNN4uoi2ImzwRtdtDU8y3wqOYHakRXyuP5PdvKejjpB1MAmw8TYVQkTfrfsgG972wo2g_0jx3VzmcOXJSl8wHU5y3rdEgNG-vDvV1wlJwQDX6ZKc2FLSzk1yEv9NSsAYur21PrnBfMImaenvGzEh1J747HmUfrHOPr-wRPvTQE4GNiOf4hWKXJrnPwpg85S_S8EZgGqlRVfNQ4V2g_7LfH1ZjFxiZrd8oZFPbnAI1ihDSBqaTy04HXotXsyp92YzDhVHwDavw","token_type":"bearer","expires_in":86399}
Get request to fuel REST API
GET https://fuel-v2.cc.ls.api.here.com/fuel/stations.json?prox=36.0029435,%20-78.9059841&fueltype=1
Request Headers
Authorization: Bearer eyJhbGciOiJSUzUxMiIsImN0eSI6IkpXVCIsImlzcyI6IkhFUkUiLCJhaWQiOiJaVjhwbGFFWDdRekd2VUNXbUdGbiIsImlhdCI6MTYwMDgxMjI4MiwiZXhwIjoxNjAwODk4NjgyLCJraWQiOiJqMSJ9.ZXlKaGJHY2lPaUprYVhJaUxDSmxibU1pT2lKQk1qVTJRMEpETFVoVE5URXlJbjAuLk8tRDdJQm9Mdzk5b1dxejJ1Vmx0Y1EuSmlYUmMwV0N6cVFUbVFicmhNaDNONkFENVJ6YWVMenFfdWpOWVZlekgyQ2dvbERLcFFEcUNrODFlMWFoMmlZZXZXZzFHNVhDZUtsZEc0WXhwX0pSU2lPaUkxUUNMRWZhakFscEFHQjdta0JLdjktbXllXzlqeDFGbzM2T0tUaDRuNXdxWEZVbnhtMkRYOHRQYjVZZUZBLl9qUlE0NU9PTmd3ZHpwY1c4cUxJck5hRmhYcTVLM1hzMHZzYl85MTFtVVU.R62C1fZVxt29r0VPA9jYVdWRbqO5lFH0yNtomCSxAnpTaHf4ed215u7o21RnwEjy-Dl2vgCAP8Oc4xNN4uoi2ImzwRtdtDU8y3wqOYHakRXyuP5PdvKejjpB1MAmw8TYVQkTfrfsgG972wo2g_0jx3VzmcOXJSl8wHU5y3rdEgNG-vDvV1wlJwQDX6ZKc2FLSzk1yEv9NSsAYur21PrnBfMImaenvGzEh1J747HmUfrHOPr-wRPvTQE4GNiOf4hWKXJrnPwpg85S_S8EZgGqlRVfNQ4V2g_7LfH1ZjFxiZrd8oZFPbnAI1ihDSBqaTy04HXotXsyp92YzDhVHwDavw
User-Agent: PostmanRuntime/7.26.5
Accept: */*
Cache-Control: no-cache
Postman-Token: d5d3944f-4c5c-44ef-8eb4-0202a4d669c0
Host: fuel-v2.cc.ls.api.here.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Response Headers
Content-Encoding: gzip
Content-Type: application/json
Date: Tue, 22 Sep 2020 22:11:15 GMT
Server: nginx-clojure
Vary: Accept-Encoding,Origin
X-HERE-RESPONSE-TIME: 0
Content-Length: 99
Connection: keep-alive
Response Body
{"Type":"Forbidden","Message":["These credentials do not authorize access"]}
Unfortunately, currently the Freemium plan doesn't have an access to Connected vehicle services https://developer.here.com/documentation#cvs
On https://developer.here.com/documentation/fuel-prices/dev_guide/topics/credentials.html you can see:
There are two kinds of credentials:
Development credentials - these credentials are for evaluation and
development. To obtain your development credentials, contact your
customer/sales representative and sign the appropriate evaluation
agreements.
Production credentials - these credentials are for commercial
deployment. To obtain your commercial credentials, sign the
appropriate commercial agreements. You must have completed all
testing, be ready for deployment and have signed a commercial
agreement before you apply for production credentials.
You can also read this Knowledge Base What other HERE Location Services limits apply to my Freemium or Pro plan? - there the information about Connected vehicle services will be added later.
Related
I am not sure why i am getting this error message. i have inserted the ids
POST /oauth2/v4/token HTTP/1.1
Host: www.googleapis.com
Content-length: 322
content-type: application/x-www-form-urlencoded
user-agent: google-oauth-playground
HTTP/1.1 400 Bad Request
Content-length: 68
X-xss-protection: 1; mode=block
X-content-type-options: nosniff
Transfer-encoding: chunked
Vary: Origin, X-Origin, Referer
Server: ESF
-content-encoding: gzip
Cache-control: private
Date: Sun, 11 Nov 2018 23:59:34 GMT
X-frame-options: SAMEORIGIN
Alt-svc: quic=":443"; ma=2592000; v="44,43,39,35"
Content-type: application/json; charset=utf-8
{
"error_description": "Bad Request",
"error": "invalid_grant"
}
Bad Request error occurs when the request syntax are wrong (i.e. when a parameter or a header you are supposed to send is missing or contains an incorrect/invalid value). Best option is to check OAuth Specification are figure out what you have done wrong in the token request. Google might have a slightly different implementation from the actual specification, but I think it won't be difficult to find the issue after checking the documentation.
Access token request specification for authorization code grant can be found here.
I'm trying to create a user using the SaonarQube API (version 6.2 or up).
I have setup a SoapUI project that contains a few test scripts. One of them is login in and creating a user. this one returns a 401 whe the user creation call is done.
The login is used for other calls as well and proves to work. Except for the create user call. The account used to login to SoarQube is member of the System Administror groups.
Below is the raw request.
POST http://localhost:9000/api/users/create HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 47
Host: localhost:9000
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
Cookie: JWT-SESSION=eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJBV0ExaGFtX2hnNWdHUWtNNVRHSiIsInN1YiI6ImFkbWluIiwiaWF0IjoxNTEyNzI2NDQwLCJleHAiOjE1MTI5ODU2NDAsImxhc3RSZWZyZXNoVGltZSI6MTUxMjcyNjQ0MDM4MywieHNyZlRva2VuIjoicHRwcXRlYmtzYTR2MTlhaTk3anV0bnVlZW8ifQ.waHqOsMJ9P6FyIOUWuVODl5QcW-IJp10G6oUAvy1DWk; XSRF-TOKEN=ptpqtebksa4v19ai97jutnueeo
Cookie2: $Version=1
login=user01&name=name01&password=%21P%40ssw0rd
Below is the raw resoonse
HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Length: 0
Date: Fri, 08 Dec 2017 09:47:20 GMT
Any suggestions are welcome.
BTW: I can create the user using the same values using the UI so there is no issue with he user information, at least it seams so.
Update 1:
Added raw request with querystring parameters
POST http://localhost:9000/api/users/create?login=user01&name=name01&password=%21P%40ssw0rd HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
Host: localhost:9000
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
Cookie: JWT-SESSION=eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJBV0JHZkVGY0h3bW5UZ0V5QklJNyIsInN1YiI6ImFkbWluIiwiaWF0IjoxNTEzMDExMDM2LCJleHAiOjE1MTMyNzAyMzYsImxhc3RSZWZyZXNoVGltZSI6MTUxMzAxMTAzNjQyNCwieHNyZlRva2VuIjoibmIzdmlpcjAyZmZ1ODJnMzNtdW1hYWdkN3QifQ.ur8eZkW1CwNinx4tInFsbkGLQTHQ6yFjheRfup8Z4fQ; XSRF-TOKEN=nb3viir02ffu82g33mumaagd7t
Cookie2: $Version=1
It's not possible to use the generated cookie by a web request in a console request (it could be considered as an attack).
You need either to :
Specify a user token (recommended way)
Specify a login/password
I'm attempting to create a bridge between another service (as a data source) and Microsoft Power BI. However, I can't get the REST API to work properly.
So far I've succeeded in creating a web application in Azure AD, getting the Client ID and secret, receiving an access token for the API, but after this all I get is 403 Forbidden with no error message. However, if I try to access the API with an expired token, I get an error message telling me that the token is expired.
I've read some posts on the subject, but they all suggest that the REST API cannot be accessed without having a user log in and access Power BI first, which isn't possible in a service-to-service application.
How do I properly access the service without any user interaction?
Here are the requests and responses, censored a little bit.
Request 1:
POST /[our domain].com/oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Cookie: flight-uxoptin=true; stsservicecookie=ests; x-ms-gateway-slice=productiona; stsservicecookie=ests
Host: login.microsoftonline.com
Connection: close
User-Agent: Paw/2.3 (Macintosh; OS X/10.11.3) GCDHTTPRequest
Content-Length: 203
grant_type=client_credentials&client_id=[client id]&client_secret=[client secret]&resource=https%3A%2F%2Fanalysis.windows.net%2Fpowerbi%2Fapi
Response 1:
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.5
x-ms-request-id: 52d6713c-d50b-4073-b030-aa10e33fdf27
client-request-id: 3aef4765-d602-46a6-a8ce-4b7792f678e5
x-ms-gateway-service-instanceid: ESTSFE_IN_209
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000; includeSubDomains
P3P: CP="DSP CUR OTPi IND OTRi ONL FIN"
Set-Cookie: x-ms-gateway-slice=productiona; path=/; secure; HttpOnly
Set-Cookie: stsservicecookie=ests; path=/
X-Powered-By: ASP.NET
Date: Wed, 24 Feb 2016 08:24:29 GMT
Connection: close
Content-Length: 1243
{"token_type":"Bearer","expires_in":"3599","expires_on":"1456305870","not_before":"1456301970","resource":"https://analysis.windows.net/powerbi/api","access_token":"[access token]"}
Request 2:
GET /v1.0/myorg/datasets HTTP/1.1
Authorization: Bearer [access token]
Content-Length: 0
Host: api.powerbi.com
Connection: close
User-Agent: Paw/2.3 (Macintosh; OS X/10.11.3) GCDHTTPRequest
Response 2:
HTTP/1.1 403 Forbidden
Content-Length: 0
Server: Microsoft-HTTPAPI/2.0
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Frame-Options: deny
X-Content-Type-Options: nosniff
RequestId: 803cc0cb-c65d-4212-9ab8-aed4ffa9862a
Date: Wed, 24 Feb 2016 08:25:13 GMT
Connection: close
The APIs you're using require a user's access token. They access content in a user's account. So if you don't have the access token, you'll keep getting forbidden. So what you need to do is get the access token with the user the first time. Then store the refresh token. Then use the refresh token to get new access tokens as needed. If the refresh token expires, you need to ask the user to sign in again.
I've a DotnetOpenAuth authorization server which works great on my localhost. However after publishing it my refresh access token request is blocked.
The request for a accesstoken, with success
POST https://myurl/identity/oauth/token HTTP/1.1
Authorization: Basic dsjSDLFJKSKLJesww
Content-Type: application/x-www-form-urlencoded; charset=utf-8
User-Agent: DotNetOpenAuth.Core/4.2.1.13026
Host: myhost
Cache-Control: no-store,no-cache
Pragma: no-cache
Content-Length: 86
Expect: 100-continue
Connection: Keep-Alive
username=theusername&password=fancypassword&scope=somescope&grant_type=password
The refresh request:
POST https://myurl/identity/oauth/token HTTP/1.1
Authorization: Basic dsjSDLFJKSKLJesww
Content-Type: application/x-www-form-urlencoded; charset=utf-8
User-Agent: DotNetOpenAuth.Core/4.2.1.13026
Host: myhost
Cache-Control: no-store,no-cache
Pragma: no-cache
Content-Length: 272
Expect: 100-continue
refresh_token=_ttH%21IAAAAGiYhlufAaXURH5P2oDOnPYgJx7YhoR33isvZkPPvlyUgQAAAAHoBYyDMLhq1qwGHHH2uGrLoHZli77XHbCnSFJSKLFJ3kl2j3klj2kljKFSJKLSJKL#$k3ljfsklfjl2
And the response:
Technical Information (for support personnel)
Error Code: 403 Forbidden. The server denied the specified Uniform
Resource Locator (URL). Contact the server administrator. (12202)
Any help, guidelines, pointers in any direction, would be very much appriciated!
I changed the url/username/password/scope/base64/refreshtoken for this example.
Their seems to be a setting in the TMG Forefront - Authentication Delegation which blocked the request.
Method used by Forefront TMG to authenticate to the published Web
server:
No delegation, and the client cannot authenticate directly
No delegation, but client may authenticate directly
It was set to option 1 after changing it to 2 the request is no longer blocked!
The following function works in IE but not in Chrome:
function doStuff() {
var request = new XMLHttpRequest();
request.open("POST", "http://twitter.com/statuses/update.json", true, "USERNAME-HERE", "PASSWORD-HERE");
request.send("status=STATUS UPDATE HERE");
}
Chrome generates the following request. Note the Authorization header is missing:
OPTIONS /statuses/update.json HTTP/1.1
Host: twitter.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.78 Safari/532.5
Access-Control-Request-Method: POST
Origin: file://
Access-Control-Request-Headers: Content-Type
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
I get the following response (http 401):
HTTP/1.1 401 Unauthorized
Date: Wed, 03 Feb 2010 00:39:33 GMT
Server: hi
Status: 401 Unauthorized
WWW-Authenticate: Basic realm="Twitter API"
X-Runtime: 0.00107
Content-Type: application/json; charset=utf-8
Cache-Control: no-cache, max-age=300
Set-Cookie: _twitter_sess=BAh7BzoHaWQiJTUxMTc2Nzk4N2U0YzMzZmU0ZTQyNzI4NjQyYjI3ODE2Igpm%250AbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAG%250AOgpAdXNlZHsA--bb61324c3ba12c3cd1794b3895a906a69c154edd; domain=.twitter.com; path=/
Expires: Wed, 03 Feb 2010 00:44:33 GMT
Vary: Accept-Encoding
Content-Length: 73
Connection: close
{"request":"/statuses/update.json","error":"Could not authenticate you."}
So, how am I supposed to pass a username and password to XHR? Webkit/Safari documentation says the open method should take these parameters, so I'm not sure why it is failing.
The solution was that I needed to add
request.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
The way I'm doing this is... special... so this may not be of much use to others going forward. But once I added this webkit started adding Authorization.
From the look of it, you're trying to do an X-Domain XMLHTTPRequest, which is why Chrome sends the OPTIONS pre-flight request. Because the Twitter server doesn't respond to the OPTIONS request indicating that X-Domain access is okay, you get a failure here.
Your code would only work in IE in the Local Computer zone, or if you turn off x-domain-checking (very dangerous)
Have you tried:
request.setRequestHeader('Authorization', 'yourvalue');