Karate: Facing OAuth token issues after upgrading from 1.2.0 to 1.3.0 - karate

My scenarios were working fine until version 1.2.0. Since I wanted to use #setup for data driven testing I bumped the version to 1.3.0. After that I started getting the following error while fetching OAuth token. Can someone please help.
Given url 'https://oauth2***'
# And retry until responseStatus == 200
And header Content-Type = 'application/x-www-form-urlencoded'
And form field grant_type = "client_credentials"
And form field client_id = clientId
And form field client_secret = clientSecret
When method POST
Then status 200
{"error_description":"Malformed client ID or secret in payload","error":"invalid_client"}

Related

Not getting authorization code from google auth api with ruby

Recently google authorization api breaks and because of that other things affects like events on Calender.
We are using google_client_api for rails app and we have checked with other Client Id and Client Secret but still this fails to provide to authorization code in response and because of this everything. Is there anyone who can help me out with this. I
client = Signet::OAuth2::Client.new(client_options)
Client_options = {
client_id: Rails.application.secrets.google_client_id,
client_secret: Rails.application.secrets.google_client_secret,
authorization_uri: 'https://accounts.google.com/o/oauth2/auth',
token_credential_uri: 'https://accounts.google.com/o/oauth2/token',
scope: 'https://www.googleapis.com/auth/calendar https://www.googleapis.com/auth/userinfo.email',
redirect_uri: callback_url
}
Not getting authorization code in response any solution.

Cowin api get beneficiary issue

I followed below step to get beneficiaries.
Generated OTP - from https://cdn-api.co-vin.in/api/v2/auth/public/generateOTP
Confirmed OTP - after converting to sha256 - https://cdn-api.co-vin.in/api/v2/auth/public/confirmOTP
#2 generated bearer token which i have used to find beneficiaries - https://cdn-api.co-vin.in/api/v2/appointment/beneficiaries
#3 gives unauth error - I think the bearer token which is generated from above is not correct.
I tried to fetch the token from cowin.gov.in website (after giving mobile no and confirm otp) and used that token generated from response of confirming otp, this time it worked.
Why generating bearer token is not correct from https://apisetu.gov.in/public/marketplace/api/cowin/cowin-public-v2?
also I checked the api in cowin website is validateMobileOTP vs the one mentioned in https://apisetu.gov.in/public/marketplace/api/cowin/cowin-public-v2#/ is confirmOTP which one we should use?
To get Bearer token
var authorizationToken = "Bearer " + sessionStorage.getItem("userToken").match(/"([^"]+)"/)[1];
after getting token, set it to
XMLHttpRequest xmlHttp.setRequestHeader("authorization", authorizationToken);

Qliksense REST Connector error: BAD_AUTH_CODE

I am trying QlikSense REST connector for connecting HubSpot's API. Following are the parameters I am using in REST connector as per HubSpot's documentation to generate access token:
method: POST
URL: https://api.hubapi.com/oauth/v1/token
authentication schema: Basic
skip server certificate validation: checked
:: query parameters ::
grant_type = authorization_code
client_id = xxxxxxxxxxxxxxxxxxxxxx
client_secret = xxxxxxxxxxxxxxxxxxxx
redirect_uri = https://www.example.com/
code = xxxxxxxxxxxxxxxxxxxxxxxx (this is the same code i got after authorizing the access to my app using this [https://app.hubspot.com/oauth/authorize?client_id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&scope=contacts%20automation&redirect_uri=https://www.example.com/] )
Content-Type = application/x-www-form-urlencoded;charset=utf-8
Now here's what the problem is :
When I use a totally refreshed code = xxxxxxxxxxxxxxxxxxxxxxxx for the first time and hit Test Connection on Qliksense REST window dialogue, I get connection successful but when I try to save that connection I get the following error
Now from this error, at first I thought maybe my auth_code has expired but when I do the same exercise again (getting a refresh AUTH_CODE), it (QlikSense) does the same thing i.e. at first tell me connection is successful and when I try to save it I again bump into the BAD_AUTH_CODE or error 400 (Bad Request).
F.Y.I. I have tested the API with the same parameters and setting in Postman, works like a charm but not here in QlikSense.
Any idea what's going on in here? I am sure it's not HubSpot it's something to do with the REST connector.
query parameters like "Content-Type" should be headers not query
Once you get the Access Token it should be passed to the API as a Header, not a parameter, as 'Authorization': 'Bearer {ACCESS_TOKEN}'

RestSharp Oauth2 authentication Cherwell restful api

I normally don't ask questions here because most of the times I can find answers. But at this moment I havenĀ“t find one, and I am really stuck. I have a problem trying to get access token for the Cherwell api: http://13.88.176.216/CherwellAPI/Swagger/ui/index#!/Service/Service_Token I used postman to generate this code:
This is relevant to Cherwell Service Management's V8+ REST API.
Code that throws server run time exception:
string user = "myUser";
string password = "myPassword";
var client1 = new RestClient("http://13.88.176.216/cherwellapi/token?auth_mode=Internal");
client.Authenticator = new HttpBasicAuthenticator(user, password);
var request1 = new RestRequest(Method.POST);
request1.AddHeader("content-type", "application/x-www-form-urlencoded");
request1.AddHeader("cache-control", "no-cache");
request1.AddParameter("application/x-www-form-urlencoded", "grant_type=password&client_id=my_client_id&client_secret=my_client_secret", ParameterType.RequestBody);
IRestResponse response = client1.Execute(request1);
The thing is when I execute the same method from the swagger ui (http://13.88.176.216/CherwellAPI/Swagger/ui/index#!/Service/Service_Token) I can get the token without getting any error.
Details of the request in CURL:
Curl
curl -X POST
--header "Content-Type: application/x-www-form-urlencoded"
--header "Accept: application/json" -d "grant_type=password&client_id=my_client_id&client_secret=my_client_secret&username=my_user_name&password=my_password" "http://13.88.176.216/CherwellAPI/token?auth_mode=Internal"
Request URL
http://13.88.176.216/CherwellAPI/token?auth_mode=Internal
This is the response body from the swagger ui test, not my code:
{
"access_token": "the_acces_token",
"token_type": "bearer",
"expires_in": 1199,
"refresh_token": "the_refresh_token",
"as:client_id": "client_key",
"username": "user",
".issued": "date",
".expires": "other_date"
}
Any help will be appreciated.
Try including the username/password as part of your form encoded data.
Drop the authenticator section, it shouldn't be necessary for this part.
So,
request1.AddParameter("application/x-www-form-urlencoded", "grant_type=password&client_id=my_client_id&client_secret=my_client_secret&username=(yourusernamehere)&password=(yourpasswordhere)", ParameterType.RequestBody);
I actually just recorded a video on this not too long ago (using a browser rest client, not C#, but you get the picture), that should post to our youtube channel soon at https://youtube.com/beyond20llc - I can send this video to you if you'd like to see it before it reaches youtube.
The data I sent when I was authenticating for a token essentially looked like the following:
grant_type=password&
client_id=1234567890&
username=CSDAdmin&
password=CSDAdmin
(Of course, CSDAdmin being the default username/password on a fresh installation of Cherwell - if you're CSDAdmin account still has these credentials, change immediately as this is a well-known default pass).
Have you tried using the swagger code generation tool as documented in the Cherwell documentation?
Once you have generated the client code, you will have wrapper data structures for all Cherwell REST API requests and responses.
Using Swagger Code Gen
You will need to install Maven and the Java Development kit.

Issue during migration from Google OAuth 1.0 to OAuth 2.0

I have to migrate from Google OAuth 1.0 to OAuth 2.0.
I just have wrote a small request in Chrome Rest Client:
POST: https://accounts.google.com/o/oauth2/token
Headers: Authorization: OAuth realm="", oauth_signature="PU3W5uRL0eAyEi", oauth_nonce="1396865138306881000", oauth_signature_method="HMAC-SHA1", oauth_consumer_key="XXXXX.apps.googleusercontent.com", oauth_token="YYYYY", oauth_timestamp="1396865138", Content-Type: application/x-www-form-urlencoded
Payload: grant_type=urn:ietf:params:oauth:grant-type:migration:oauth1&client_id=ZZZZZ.apps.googleusercontent.com&client_secret=SSSSS
For that I receive an error message:
Status: 400 Bad Request
"{
error: "invalid_request"
error_description: "Invalid authorization header."
}"
The problem could be that I try to migrate from one Project in Google Developers Console to another.
Could that really be a problem?
The reason that I moved to another project is because I cannot create OAuth 2.0 Client ID in the original Project. I receive the following error message:
"You can not create OAuth 2.0 client ID because this project already contains an Oauth 1.0 client ID."
Please suggest.
Thank you,
E
As pointed out in a similar post, when constructing the base string to sign your migration requests, please make sure that the string uses a POST method and that it contains all relevant migration parameters as per the migration documentation.
As per OAuth1 spec, a valid base string for a migration request should look like:
POST&https://accounts.google.com/o/oauth2/token&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&grant_type=urn:ietf:params:oauth:grant-type:migration:oauth1&oauth_consumer_key=YOUR_CONSUMER_KEY&oauth_nonce=NONCE&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1396414006&oauth_token=THE_TOKEN_TO_MIGRATE
Note that, for readability purpose, the above is the decoded version of the base string (check out the OAuth1 spec for more examples).
Hope that helps, Miguel.
When generating the base string you will need to ensure that each individual parameter is URL encoded before constructing the base string.
As per the oAuth documentation to sign OAuth 1.0 requests the base string is made up of 3 components
The HTTP request method
The base URL the request is being sent to
A normalized string of the parameters in the request
When constructing the base string you need to do the following
Ensure HTTP request method is POST
URL encode the base URL
Ensure the three POST body parameters [client_id, client_secret, grant_type] are included in the normalized request parameters
Ensure each parameter is individually URL encoded and then URL encode the complete normalized request parameters string. So in effect, some of the paramters are double URL encoded. This double URL encoding is mentioned in Using OAuth with the Google Data APIs#Signing Requests for the oauth_token
Only after doing all these steps did I get the migration request to work and I received a valid refresh_token
Below is a sample base string
POST&https%3A%2F%2Faccounts.google.com%2Fo%2Foauth2%2Ftoken&client_id%3Dxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxx.apps.googleusercontent.com%26client_secret%3Dxxxxxxxxxxxx%26grant_type%3Durn%253Aietf%253Aparams%253Aoauth%253Agrant-type%253Amigration%253Aoauth1%26oauth_consumer_key%3Dxxxxxxxxx%26oauth_nonce%3D4106001%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1400779530%26oauth_token%3D1%252FkklP1YPy_AULt7j_tttttt_tterwerkj_dfj45dflk