Issue Pulling Back Ratings - beatsmusic

I am trying to pull back ratings from a user but am getting 401 unauthorized:
Request:
GET https://partner.api.beatsmusic.com/v1/api/users/<VALID USER ID RETREIVED USING ME ENDPOINT>/ratings?&offset=0&limit=20&access_token=<VALID ACCESS TOKEN USED TO GET USER ID> HTTP/1.1
Host: partner.api.beatsmusic.com
Connection: Keep-Alive
Response:
HTTP/1.1 401 Unauthorized
Content-Type: text/xml
Date: Mon, 14 Jul 2014 01:29:54 GMT
Server: Mashery Proxy
WWW-Authenticate: Bearer realm="partner.api.beatsmusic.com", error="invalid_token"
X-Mashery-Error-Code: ERR_403_NOT_AUTHORIZED
X-Mashery-Responder: prod-j-worker-us-west-1b-19.mashery.com
Content-Length: 23
Connection: keep-alive
<h1>Not Authorized</h1>
The access token is viable since I am able to use it to get other resources.

We were able to replace values in your URL and receive ratings. This is also a standard format: https://partner.api.beatsmusic.com/v1/api/users/[USERID]/ratings?access_token=[TOKEN]

Related

IBM Cloud Private 3.1 - unable to login to URL: Unexpected response code 401 from request

I have successfully installed IBM Cloud Private 3.1.
All was working well. I could login to the ICP URL, but after rebooting, nothing works.
Now the URL says:
Unexpected response code 401 from request: GET
https://icp-management-ingress:8443/idmgmt/identity/api/v1/users/admin/getTeamResources?resourceType=namespace
HTTP/1.1 Accept: application/json Authorization: bearer *** HTTP/1.1
401 Server: openresty/1.11.2.4 Date: Wed, 07 Nov 2018 21:47:55 GMT
Content-Type: application/json; charset=utf-8 Transfer-Encoding:
chunked Connection: close Vary: Origin, Accept-Encoding
Access-Control-Allow-Credentials: true X-Xss-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN Strict-Transport-Security:
max-age=15552000; includeSubDomains X-Download-Options: noopen
X-Content-Type-Options: nosniff X-Dns-Prefetch-Control: off
{"error":{"statusCode":401,"name":"Error","message":"An error occurred
while accessing the kube services rest api"}}
When I try to login with cloudctl, I get this:
Cloudctl login
API endpoint: https://172.31.16.153:8443
Username> admin
Password>
Authenticating...
OK
Select an account:
1. Mycluster Account (id-mycluster-account)
Enter a number> 1
Targeted account mycluster Account (id-mycluster-account)
FAILED
Error response from server. Status code: 401; message: {"error":{"statusCode":401,"name":"Error","message":"An error occurred while accessing the kube services rest api"}}
And kubectl says there is no service for the common ones:
Kubectl get pods
Error: The server doesn't have a resource type "pods"
Kubectl get nodes
Error: The server doesn't have a resource type "nodes"
Kubectl get services
Error: The server doesn't have a resource type "services"
Kubectl get deployment
Error: The server doesn't have a resource type "deployment"
Any suggestions?

ServiceAccout has empty calendarList after sharing a calendar has been shaired with it

On creating a new service account via Google Console, when then sharing a calendar with the service account, the calendar doesn't appear in the calendarList response for the authenticated service account.
This was working okay for some time but appears to have started failing more recently.
Oddly, if I delete the shared account entry on the calendar and then add it back in, it usually works. It doesn't appear to be a time delay as have waited hours initially and always zero results in the calendar list, until removing the shared account on the calendar and resharing.
The following are steps I've used to reproduce:
In Google Console web UI, create a new service account with 'Furnish a new private key' selected to download the JSON key.
In the Google Calendar web UI, go to calendar settings and 'Share this calendar', then share the calendar with the service account email, then save the changes.
In REST calls, authenticate with the JSON key with POST call to oauth2/v3/token
Send GET request for calendar/v3/users/me/calendarList
then optionally to show it working...
Delete the service account share from the calendar and save.
Add the service account email to the calendar share and save.
Repeat steps 2 and 3. This time it will probably work.
This is partially a manual process for our end users to create a service account and share calendars via Google web UI. Note I've been using additional calendars on my own Google account to share with the service account (this reflects our end user use case), rather than just the default calendar.
Client code is REST based. To provide an example I have shown the REST requests and responses below. There are simply two requests, one to authenticate and one to fetch the calendarList. These occur after the manual steps in the UI to create a service account and then share a calendar with that account.
---
Request:
POST https://www.googleapis.com/oauth2/v3/token HTTP/1.1
Accept: application/json, application/xml, text/json, text/x-json, text/javascript, text/xml
User-Agent: RestSharp/105.2.3.0
Content-Type: application/x-www-form-urlencoded
Host: www.googleapis.com
Content-Length: 758
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=[ASSERTION_JWT_HERE]
Response:
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Date: Tue, 14 Mar 2017 20:17:18 GMT
Vary: Origin
Vary: X-Origin
Content-Type: application/json; charset=UTF-8
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE
Alt-Svc: quic=":443"; ma=2592000; v="36,35,34"
Content-Length: 197
{
"access_token": "ya29.ElkOBAzSOzE_J2VOGFeWnTAGXdtoadW2FbnGga99SrMeamL7j6KetKomvT4aoy4jsRCcXpK-N6sxRBLFUaj_kPWFin4m6xvg_CtaTtkG5tVc_IxS7IezJDf32g",
"token_type": "Bearer",
"expires_in": 3600
}
---
---
Request
GET https://www.googleapis.com/calendar/v3/users/me/calendarList?minAccessRole=reader HTTP/1.1
Authorization: Bearer ya29.ElkOBAzSOzE_J2VOGFeWnTAGXdtoadW2FbnGga99SrMeamL7j6KetKomvT4aoy4jsRCcXpK-N6sxRBLFUaj_kPWFin4m6xvg_CtaTtkG5tVc_IxS7IezJDf32g
Accept: application/json, application/xml, text/json, text/x-json, text/javascript, text/xml
User-Agent: RestSharp/105.2.3.0
Host: www.googleapis.com
Accept-Encoding: gzip, deflate
Response:
HTTP/1.1 200 OK
Expires: Tue, 14 Mar 2017 20:17:19 GMT
Date: Tue, 14 Mar 2017 20:17:19 GMT
Cache-Control: private, max-age=0, must-revalidate, no-transform
Vary: Origin
Vary: X-Origin
Content-Type: application/json; charset=UTF-8
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Content-Length: 202
Server: GSE
Alt-Svc: quic=":443"; ma=2592000; v="36,35,34"
{
"kind": "calendar#calendarList",
"etag": "\"p328bl14pt3bd40g\"",
"nextSyncToken": "CJC6hJno1tICEj10ZXN0MS05MjhAY2FsZW5kYXItY29ubmVjdG9yLS0tb25lbGFuLmlhbS5nc2VydmljZWFjY291bnQuY29t",
"items": []
}
---
Note, I haven't provided the actual JWT for the ouath request, but the authentication is working fine. Also note the calendar is shared as either read or modify with the service account. I can also query the calendar itself and fetch events using the service account, but it is querying the list of calendars associated with the account that fails.
Had also raised this as an issue here but posting this here also in case I'm missing something, although as said all this was working fine until more recently, and our existing unchanged client software has started failing with newly created service accounts.
When you share a calendar with someone VIA the google calendar website the code on the website automatically adds the calendar to the users calendar.list. All the calendarlist is the list on the bottom left of the google calendar website. A user can have access to a calendar without it being in their calendarlist.
When sharing a calendar wish a service account this does not always happen. None of the service accounts I have shared my calendars with have ever had anything in their calendarlist. If you need it to be in the calendarlist then you should have the service account insert it. Using CalendarList: insert just grab the calendar id in question off of the website.

Azure REST API : oAuth2 authentication granted but invalid token on request

I have a question about authenticating to azure mobile management API, to send push informations to the API.
I well manage to authentify and receive a token bearer matching to the provided data (tenant id, client id, client secret...), but when I try to create a campaign, I receive the following response :
[2016-10-25 11:45:51] (::1) fail to send send request https://management.azure.com/subscriptions/fb8226dc-194f-4562-9dc9-c72f56bd728a/resourcegroups/MobileEngagement/providers/Microsoft.MobileEngagement/appcollections/XX-Collection/apps/XX-TEST-android/campaigns/announcements?api-version=2014-12-01
with {"name":"The Evian Championship 20... - 25/10/2016
11:45:50","type":"only_notif","deliveryTime":"any","pushMode":"one-shot","notificationTickerIcon":true,"notificationIcon":true,"notificationCloseable":true,"notificationSound":true,"notificationVibrate":false,"notificationTitle":"Soci\u00e9t\u00e9
G\u00e9n\u00e9rale","notificationMessage":"The Evian Championship
2016","actionUrl":"://webviews/main/build/events.html","notificationType":"system"}
| "HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
x-ms-failure-cause: gateway
x-ms-request-id: 40e30675-2144-452a-9ab9-632a393d8783
x-ms-correlation-request-id: 40e30675-2144-452a-9ab9-632a393d8783
x-ms-routing-request-id: WESTEUROPE:20161025T094550Z:40e30675-2144-452a-9ab9-632a393d8783
Strict-Transport-Security: max-age=31536000; includeSubDomains
Date: Tue, 25 Oct 2016 09:45:49 GMT
Connection: close
Content-Length: 281
{"error":{"code":"InvalidAuthenticationToken","message":"The received access token is not valid: at least one of the claims 'puid'
or 'altsecid' or 'oid' should be present. If you are accessing as
application please make sure service principal is properly created in
the tenant."}}" was returned
Here's the request :
POST
/subscriptions/fb8226dc-194f-4562-9dc9-c72f56bd728a/resourcegroups/MobileEngagement/providers/Microsoft.MobileEngagement/appcollections/XX-Collection/apps/XX-TEST-android/campaigns/announcements?api-version=2014-12-01
HTTP/1.1 Host: management.azure.com Authorization: bearer
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ikk2b0J3NFZ6QkhPcWxlR3JWMkFKZEE1RW1YYyIsImtpZCI6Ikk2b0J3NFZ6QkhPcWxlR3JWMkFKZEE1RW1YYyJ9.eyJhdWQiOiJodHRwczovL21hbmFnZW1lbnQuYXp1cmUuY29tLyIsImlzcyI6Imh0dHBzOi8vc3RzLndpbmRvd3MubmV0LzRmNGFkYjA3LWU5OWQtNDg5NC04OGZjLTZkYzc4ODAzNDI3Zi8iLCJpYXQiOjE0NzczOTUxNzEsIm5iZiI6MTQ3NzM5NTE3MSwiZXhwIjoxNDc3Mzk5MDcxLCJhcHBpZCI6IjUzNzMyOTAwLTU2NGMtNGI2OS1hNGRhLTU0OTQ0ODVkYTFhNiIsImFwcGlkYWNyIjoiMSIsImlkcCI6Imh0dHBzOi8vc3RzLndpbmRvd3MubmV0LzRmNGFkYjA3LWU5OWQtNDg5NC04OGZjLTZkYzc4ODAzNDI3Zi8iLCJ0aWQiOiI0ZjRhZGIwNy1lOTlkLTQ4OTQtODhmYy02ZGM3ODgwMzQyN2YiLCJ2ZXIiOiIxLjAifQ.WvWXETt9IFy_eX2Q8LlguTec9KA2TLgILUs10QULNMYgf1sHUpXdnRhDBqq5Foo_gwF_u2zl1NNYRLmdN3Q0IR3LPspiutAhC_KXvGXmJH2TtxTi9U2bt1Zvf5BsafHkxDdlDG6vymu-3O4cK9HQMu7l0XtPqzcEHcQny94xAq66_TSNa3FhZclwEBnaTI81B5g9NzvET10C0j8ZW0OsRNzc0-czS8RqtXulp1rkIEQc7VhTTDx9feSPi3BJlyhiKxUzfnEn8xUkfqlUEQuqyerqUoRIlbFvhhOT7Gjo6_WJN21Wn-23gcEchaRETWzYh-nTJSeKFzwA-mROOdmUzw
User-Agent: Guzzle/5.3.1 curl/7.50.0 PHP/5.6.25 Content-Length: 455
(note : I changed some characters in this displayed bearer by security reasons)
The (real) bearer was obtained requesting https://login.microsoftonline.com/{TENANT_ID}/oauth2/token, using this body :
grant_type=client_credentials&client_id={CLIENT_ID}&client_secret={CLIENT_SECRET}&resource=https://management.azure.com/
Would you have an idea about the reason why the API returned this message ?
Thanks a lot !
The received access token is not valid: at least one of the claims 'puid' or 'altsecid' or 'oid' should be present. If you are accessing as application please make sure service principal is properly created in the tenant
It seems that your access token is not valid. I would suggest you follow with this article to get a new token then try again.

REST - How to use auth token in subsequent requests

I'm using a java application the provide a REST interface for mongodb database called "RESTHeart"
When I make a normal GET request.
http -a admin:temp http://172.18.18.122:8080/_logic/roles/admin
I get an auth token Auth-Token: 10dc2eeb-9624-47f2-a542-c97e0af82b23, how can I use it subsequent requests?
Here is the full response
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Location, ETag, Auth-Token, Auth-Token-Valid-Until, Auth-Token-Location, X-Powered-By
Auth-Token: 10dc2eeb-9624-47f2-a542-c97e0af82b23
Auth-Token-Location: /_authtokens/admin
Auth-Token-Valid-Until: 2016-04-25T14:37:22.290Z
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 109
Content-Type: application/hal+json
Date: Mon, 25 Apr 2016 14:22:22 GMT
X-Powered-By: restheart.org
{
"_links": {
"self": {
"href": "/_logic/roles/admin"
}
},
"authenticated": true,
"roles": [
"ADMIN"
]
}
I have tried the following:
http http://172.18.18.122:8080/_logic/roles/admin Auth-Token:'10dc2eeb-9624-47f2-a542-c97e0af82b23'
Response:
HTTP/1.1 403 Forbidden
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Location, ETag, Auth-Token, Auth-Token-Valid-Until, Auth-Token-Location, X-Powered-By
Connection: keep-alive
Content-Length: 0
Date: Mon, 25 Apr 2016 14:30:27 GMT
X-Powered-By: restheart.org
I'm not sure what I'm doing wrong here, any ideas?
with httpie you can simply do:
http -a <username>:<Auth-Token> GET http://172.18.18.122:8080/auth/users
I found the solution for this question, all what I needed was to pass authorization header along with 'username:password' encoded in base64 format
http GET http://172.18.18.122:8080/auth/users authorization:'Basic YWRtaW46dGVtcA=='
Clients authenticate passing credentials via the standard basic authentication, a standard method for an HTTP user agent to provide a username and password when making a request.
RESTHeart is stateless: there isn't any authentication session and credentials must be sent on every request.
Of course, it means you must secure your communications with HTTPS.
There's documentation on how the authentication process works in restheart at https://softinstigate.atlassian.net/wiki/x/JgDM

I'm trying to get intuit request token but get a 401 Unauthorized error (oauth_problem=token_rejected)

My authorization token is:
oauth_token=""
,oauth_nonce="<unique id>"
,oauth_consumer_key="<consumerKey>"
,oauth_signature_method="HMAC-SHA1"
,oauth_timestamp="<epoch timestamp>"
,oauth_version="1.0"
,oauth_signature="<generated signature>"
(one line, but it has been formatted for legibility)
to generate the signature I run the algorithm using the following message:
POST&https://oauth.intuit.com/oauth/v1/get_request_token&oauth_token="",oauth_nonce="<unique id>",oauth_consumer_key="<consumerKey>",oauth_signature_method="HMAC-SHA1",oauth_timestamp="<epoch timestamp>",oauth_version="1.0"
against my OAuth Consumer Secret and an empty string, like:
"<consumerSecretKey>&<empty>"
, empty because I'm still requesting the access tokens.
then I do a POST
URL:
https://oauth.intuit.com/oauth/v1/get_request_token?oauth_callback=<myCallbackURL>
Header:
Authorization :OAuth <authorizationToken>
Body:
<authorizationToken>
After this rather get the request tokens I get an 401 Unauthorized error (oauth_problem=token_rejected)
Can you please assist?
The get request token call is a GET call.
This is a sample raw request/response-
GET https://oauth.intuit.com/oauth/v1/get_request_token?oauth_callback=oob&oauth_nonce=34562646-ab97-46e1-9aa7-f814d83ef9d1&oauth_consumer_key=qyprd7I5WvVgWDFnPoiBh1ejZn&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1392306961&oauth_version=1.0&oauth_signature=0EtvSnzsuumeyib2fiEcnSyu8%3D HTTP/1.1
Host: oauth.intuit.com
HTTP/1.1 200 OK
Date: Thu, 13 Feb 2014 15:56:03 GMT
Server: Apache
Cache-Control: no-cache, no-store
Pragma: no-cache
Content-Length: 150
Connection: close
Content-Type: text/plain
oauth_token_secret=dXhHHMS1EfdrQ32UabOMscIRWt5bLJNX3ZKljjBc&oauth_callback_confirmed=true&oauth_token=qyprdbwXdWrAt0xM2NgkLlJ79yCp4I2SmDg7tahDBPjA6Wti