Power BI REST authentication and permissions - api

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.

Related

Jmeter not showing up proper response instead giving details of server and connection details

I am using Jmeter 5.4.1 version, my API is of oauth1.0 type. When I ran my api through postman , it gave my proper json response for example an proper id, but the same api when ran through jmeter gives 200 response code but giving details of server and connection in response body and not the reponse that is expected(a proper id).
Below is the response :
HTTP/1.1 200 OK
Server: nginx/1.14.0 (Ubuntu)
Date: Wed, 12 May 2021 12:33:10 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Set-Cookie: PHPSESSID=eqvp0l22u2jo30moqn194meugp; expires=Wed, 12-May-2021 13:33:10 GMT; Max-Age=3600; path=/; domain=dev.moorup.no; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
X-Frame-Options: SAMEORIGIN
Cache-Control: no-store
enter image description here
You're looking at Response Headers tab of the View Results Tree listener therefore you're seeing the HTTP Response Headers
Just switch to Response Body tab and you will be able to see "raw" HTML Response and several options of rendering it:
Also be aware that it is possible to convert your Postman scripts to JMeter, for OAuth you will still have to do some correlation, but for the main logic record and replay should work more or less fine

here.com API oAuth credentials

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.

RestSharp Issue With 402 Response

I'm using RestSharp to interface with the Auth0 and Sisense APIs. Everything's working fine except when deleting a user in Auth0. I send the delete request as a DELETE and Auth0 successfully deletes the user.
Here is the response I'm getting from Auth0:
HTTP/1.1 204 No Content
Date: Wed, 19 Feb 2020 16:35:28 GMT
Content-Type: application/json; charset=utf-8
Connection: keep-alive
Server: nginx
ot-tracer-spanid: 21cd87957d9bac76
ot-tracer-traceid: 25a636cb6e5fd4ca
ot-tracer-sampled: true
x-ratelimit-limit: 50
x-ratelimit-remaining: 49
x-ratelimit-reset: 1582130129
vary: origin,accept-encoding
cache-control: no-cache
Strict-Transport-Security: max-age=15724800
X-Robots-Tag: noindex, nofollow, nosnippet, noarchive
And here's what I'm getting in the RestSharp response:
System.Runtime.Serialization.SerializationException: Invalid JSON string
at RestSharp.RestClientExtensions.ThrowIfError(IRestResponse response)
at RestSharp.RestClientExtensions.DeleteAsync[T](IRestClient client, IRestRequest request)
I'm making a call to a Sisense web service and RestSharp is handling the 402 just fine. Here's the Sisense response:
HTTP/1.1 204 No Content
Date: Wed, 19 Feb 2020 16:32:14 GMT
Connection: keep-alive
Set-Cookie: sisense-cookieCORS=***************************; Path=/; SameSite=None; Secure
Set-Cookie: sisense-cookie=***************************; Path=/
X-UA-Compatible: IE=Edge
x-xss-protection: 1; mode=block
x-frame-options: ALLOW-FROM https://****************************************************
content-security-policy: frame-ancestors ****************************************************
Cache-Control: private, no-cache, no-store, must-revalidate
Expires: -1
Pragma: no-cache
The main difference between the two is the Content-Type directive present in Auth0. Is that what's causing the problem? Is there a workaround?

Once you got the Authorization Code from Step 1 click the Exchange authorization code

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.

Creating a user using the SonarQube API returns a 401

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