I'm testing the Authorization Code Grant protocol on the instance of KeyRock GE at FIWARE-Lab using DHC web client.
So far I have succeeded on implementing the Authorization Request, and I obtain the code to be used on the Access Token Request. The URL for the Authorization Request is the following (although not executed on DHC, but on a regular browser so I can introduce my user and password):
https://account.lab.fiware.org/oauth2/authorize/?response_type=code&client_id=2122&redirect_uri=http%3A%2F%2Flocalhost%2FCallback
I have checked that the client_id and the redirect_uri are both correct against the values related with my application at my account at FIWARE-Lab.
Executing the following request (can't post images, so I'll describe)
POST
https:// account.lab.fiware.org/oauth2/token?grant_type=authorization_code&code=<code>&redirect_uri=http%3A%2F%2Flocalhost%2FCallback -- <code> is the code obtained on the Auth. Request
Authorization: Basic <XXXX> --- <XXXX> is the result of base64(client_id+":"+client_secret)
Content-Type: application/x-www-form-urlencoded
...I get the following error message:
{
"error":{
"message": "create_access_token() takes exactly 3 arguments (2 given)",
"code": 400,
"title": "Bad Request"
}
}
I've checked the authorization is correct (Basic using the OAuth credentials from my application), and I'm using the same redirect_uri used at the previous Authorization Request, and the code obtained from it.
¿What is wrong?
P.S.: If I remove any or all of the query parameters, I still get the same error
Don't pass the parameters in the url. Instead, add them to request's body as query string:
POST /oauth2/token HTTP/1.1
Host: account.lab.fiware.org
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <XXXX> --- <XXXX>
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=1234&redirect_uri=http%3A%2F%2Flocalhost%3A9000%2Fcodecallback.html
I suggest to follow the steps in the presentation:
Adding Identity Management and Access Control to your Application
It gives you details about what are the different requests that you have to follow and also what are the expected response of them.
Related
I'm sending two post requests using the REST API: http://localhost:8111/app/rest/buildQueue but my second request fails with
403 Forbidden: Responding with 403 status code due to failed CSRF check: no "Origin" header is present and no authentication provided with the request, consider adding "Origin: http://localhost:8111" header.
I'm wondering why is this happening since if I run the build in the UI and change the params ex. build1 has %version=2% and build2 has %version=3% it will run parallel with each other running on different available agents.
Here's my json request:
REST API endpoint: http://localhost:8111/app/rest/buildQueue
JSON body:
{
"branchName": "master",
"buildType": {
"id": "DockerBuild",
"projectId": "Test"
},
"properties": {
"property": [
{
"name": "DOCKER_IMAGE_NAME",
"value": "test-3"
},
{
"name": "SNAPSHOT_DEPENDENCY_VERSION",
"value": "0.6"
}
]
}
}
Am I missing a parameter to be able to run builds in parallel with each other?
When you face problems regarding CSRF protection in TeamCity (for example, you get the "Responding with 403 status code due to failed CSRF check" response from the server), you can follow these steps:
If you use a reverse proxy, make sure you correctly configure Host/Origin headers, as described above. In the meantime, you may want to add the public URL of your server to CORS-enabled origins.
You can temporary disable CSRF protection at all by setting the teamcity.csrf.origin.check.enabled=logOnly internal property.
Information about failed CSRF attempts are logged into TeamCity/logs/teamcity-auth.log files. For more detailed diagnostics of the requests, enable debug-auth logging preset.
Try pass in the request header -H 'Origin: http://localhost:8111'
Maybe this can be useful for someone, I got the same error with a single POST using Postman:
403 Forbidden: Responding with 403 status code due to failed CSRF check: no "Origin" header is present and no authentication provided with the request, consider adding "Origin: http://teamcity:20011" header.
So I followed the recommendation of the error message, and in Header I added "Origin" with the value "http://teamcity:20011" and that fixed the issue. BTW, in Authorization I selected "Bearer Token" and I pasted the token generated previously through TeamCity. This is the call:
http://teamcity:20011/app/rest/buildQueue
I was just testing how to trigger a build using the API and it worked successfully. Now the following step is to implement this call using JavaScript.
Request a CSRF header with the appropriate request:
https://teamcity/authenticationTest.html?csrf
and set it in the "X-TC-CSRF-TOKEN" header of your POST request
If you specify an Access Token to the request header like Authorization: Bearer ..., you don't need to specify a CSRF token, and what you should actually check is if you're not sending Cookies.
This is from the developer in JetBrains:
If you're using a token-based authentication, there should be no need to provide CSRF token header and obtain it with authenticationTest.html call.
In this scenario, it is expected that there are no session Cookies in the HTTP request (otherwise, TeamCity will try to find a token).
I.e. basically, you should be able to do the HTTP call in no-session way by providing the Authorization: Bearer {{token}} header only.
https://youtrack.jetbrains.com/issue/TW-69566/Flaky-builds-with-CSRF-Header-X-TC-CSRF-Token-does-not-match-CSRF-session-value#focus=Comments-27-4644138.0-0
Well, the error and the documentation don't seem to explain this, though...
I am working on implementing custom authentication using cookie Auth. So, I was playing around the sync gateway REST API to create user and session. I could successfully create the user but unable to create session via /_session API.
Following are the steps I followed.
1. Create user
POST /cookbook/_user/ HTTP/1.1
Host: localhost:4985
Content-Type: application/json
{
"name": "chef123",
"password": "1234"
}
2. Get Users
GET /cookbook/_user/ HTTP/1.1
Host: localhost:4985
Content-Type: application/json
Respone :["chef123"]
3. Create Session
POST /cookbook/_session HTTP/1.1
Host: localhost:59840
Content-Type: application/json
{
"name": "chef123",
"ttl": 1800
}
Expected:
{
"cookie_name": "SyncGatewaySession",
"expires": "2014-11-07T16:42:11.675519255-08:00",
"session_id": "c2425fa7d734bc8c3f6c507854166bef56a5fbc6"
}
Instead received:
{"authentication_handlers":["default","cookie"],"ok":true,"userCtx":{"channels":{},"name":null}}
Can Anyone please explain why is the API giving the following response.
{"authentication_handlers":["default","cookie"],"ok":true,"userCtx":{"channels":{},"name":null}}
authentication_handlers is the method you used to create the session (it could be the built-in facebook or persona login features as well). userCtx has useful information on the data access for this user like:
channels: The channels the user was given access to via the Sync Function
admin_channels: The channels the user was given access to in the config file
roles: The roles of this user
See the session docs for details: http://developer.couchbase.com/documentation/mobile/1.2/develop/references/sync-gateway/admin-rest-api/session-admin/get-db-session-sessionid/index.html
To set up authentication with Sync Gateway you can check those blogs:
Adding user Sign Up to your Android app with Node.js and Couchbase Mobile
Adding Google Sign-In with Node.js to a Couchbase Mobile application
As mentioned in the comments by krishnan, the solution to this problem is removing the trailing slash from the URI. I had the same issue.
So, instead of: POST /cookbook/_session/
Use: POST /cookbook/_session
I'm attempting to use the add_run API method to create new test runs on my testrail server. I am using RESTClient to test the command.
The request is POST index.php?/api/v2/add_run/1
(I have a project with id 1)
As request headers I am using Content-Type: application/json and Authorization: Basic USERNAME:PASSWORD_BASE64
request body is:
{
"name":"name",
"suite_id":1
}
Upon sending the request, I receive a "400 Bad Request" Response with the error message:
{"error":"Content-Type header invalid (use Content-Type: application\/json)"}
Since I am in fact using Content-Type: application/json as a request header I have no idea why I am getting this error or what it means. Anyone have any ideas?
one of the TestRail developers here. It's very likely that you didn't submit the Content-Type header correctly, could you please share the source snippet you used to send this request?
I've seen others with the same issue ... I get the following json error message back whenever I attempt to disable a user or update their title. Has anyone had luck with this?
I have no problems with the POST method to add an email_alias, or with the PUT method to move a users folder from one owner to another. I've tried it in perl and in curl (see below example session) So I'm relatively confident that :
I have a valid, OAuth2 bearer token
I have properly formed content and URLs
So, I'm trying to post to:
PUT /2.0/users/XXXXXXXXXX HTTP/1.1
Authorization: Bearer TOKEN
Response:
HTTP/1.1 400 Bad Request
{"type":"error","status":400,"code":"invalid_request_parameters","help_url":"http:\/\/developers.box.com\/docs\/#errors","message":"Invalid input parameters in request","request_id":"1682580609514902d69b5fd"}
Update: below is a trace from curl showing the request body:
0000: PUT /2.0/users/USERID HTTP/1.1
00a2: Authorization: Bearer TOKEN
011f:
=> Send data, 23 bytes (0x17)
0000: {"status" : "inactive"}
<= Recv header, 26 bytes (0x1a)
0000: HTTP/1.1 400 Bad Request
<= Recv data, 207 bytes (0xcf)
0000: {"type":"error","status":400,"code":"invalid_request_parameters"
0040: ,"help_url":"http:\/\/developers.box.com\/docs\/#errors","messag
0080: e":"Invalid input parameters in request","request_id":"718513715
00c0: 514916f1109c2"}
Found the answer to the 4xx errors on PUTs : the OAuth2 settings for the application in box needed to have "Manage Enterprise" checked ... my app has been around since the pre-OAuth2 days, wasnt aware of this flag.
After checking it, i get 200 response ... some PUT operations still dont effectively change the attribute, but they return a 2xx response, so, one hurdle cleared.
I am having a native application in facebook. I tried to post to a user wall using the following header format
https://graph.facebook.com/100002944254185/feed?message=today
Authorization: OAuth oauth_version=1.0,oauth_nonce=5887e5b11904194f7d217e9b7f795d62, oauth_timestamp=1317623602,
oauth_consumer_key=129042607197622,
oauth_token=AAAB1XRLDTbYBAIfcTKw3mowkwjld89A4K7JVQHZAOM60Tmb8za6wjNq8sPTuHhiAVojKyXm9r1SB3OWlSkKWI2sn9lSAwQGE0giA0UTgCfgXcd0ZCe, oauth_signature_method=HMAC-SHA1,
oauth_signature=GKl%2Bvf3Vaq25XY7dTnb%2FJg3fip8%3D
Content-Type: application/X-WWW-form-urlencoded
when executing getting an error as
HTTP/1.1 400 Bad Request
WWW-Authenticate: OAuth "Facebook Platform" "invalid_request" "Expected 1 '.' in the input between the postcard and the payload"
Can anyone say what does this mean?
Instead of https://graph.facebook.com/100002944254185/feed?message=today and then the messy Authorization tags below it, just append the access_token onto the querystring of the https call so it looks like https://graph.facebook.com/100002944254185/feed?message=today&access_token=xxxx and HTTP Post that.