According to Travis API documentation, for getting Travis API token I need send POST HTTP request on special address:
POST /auth/github HTTP/1.1
User-Agent: MyClient/1.0.0
Accept: application/vnd.travis-ci.2+json
Host: api.travis-ci.org
Content-Type: application/json
Content-Length: 37
{"github_token":"YOUR GITHUB TOKEN"}
But when I do this I receive 403 error with Unexpected 'y' message.
Any ideas what I'm doing wrong? Or there is something specific with Travis API?
I made it work like this:
http post https://api.travis-ci.org/auth/github Content-Type:application/json User-Agent:TravisMyClient/1.0.0 Accept:application/vnd.travis-ci.2+json github_token=<enter_your_github_token>
im using HTTPie instead of curl.
Related
By following command snippet in https://docs.docker.com/registry/spec/auth/oauth/ as below and set access_type=offline, refresh_token is not present in returned response.
curl -iX POST https://auth.docker.io/token
-H "Content-Type: application/x-www-form-urlencoded"
-d "grant_type=password&username=${user}&password=${password}&service=hub.docker.io&client_id=dockerengine&access_type=offline"
Command succeeds with response below:
HTTP/1.1 200 OK
content-type: application/json
date: Tue, 04 Jan 2022 03:08:37 GMT
transfer-encoding: chunked
strict-transport-security: max-age=31536000
{
"access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlDK1RDQ0FwK2dBd0lCQWdJQkFEQUtCZ2dxaGtqT1BRUURBakJHTVVRd1FnWURWUVFERXp0U1RVbEdPbEZNUmpRNlEwZFFNenBSTWtWYU9sRklSRUk2VkVkRlZUcFZTRlZNT2taTVZqUTZSMGRXV2pwQk5WUkhPbFJMTkZNNlVVeElTVEFlRncweU1UQXhNalV5TXpFMU1EQmFGdzB5TWpBeE1qVXlNekUxTURCYU1FWXhSREJDQmdOVkJBTVRPMVZQU1ZJNlJFMUpWVHBZVlZKUk9rdFdRVXc2U2twTFZ6cExORkpGT2tWT1RFczZRMWRGVERwRVNrOUlPbEpYTjFjNlRrUktWRHBWV0U1WU1JSUJJakFOQmdrcWhraUc5dzBCQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBbnZBeVpFK09sZHgrY3hRS0RBWUtmTHJJYk5rK2hnaEg3Ti9mTFpMVDhEYXVPMXRoTWdoamxjcGhFVkNuYTFlMEZpOHVsUlZ4WG1HdWpZVDNXbnFsZ2ZpM2ZYTUQvQlBRTmlkWHZkeWprbDFZS3dPTkl3TkFWMnRXbExxaXFsdGhSWkFnTFdvWWZZMXZQMHFKTFZBbWt5bUkrOXRBcEMxNldNZ1ZFcHJGdE1rNnV0NDlMcDlUR1J0aDJQbHVWc3RSQ1hVUGp4bjI0d3NnYlUwVStjWTJSNEpyZmVJdzN0T1ZKbXNESkNaYW5SNmVheFYyVFZFUkxoZnNGVTlsSHAzcldCZ1RuNVRCSHlMRDNRdGVFLzJ3L3MvcUxZcmdIK1hCMmZBazJPd1NIRG5YWDg4WWVJd0EyVGJJMDdYNS8xQnVsaUwrUDduOWVBT1RmbDkxVlZwNER3SURBUUFCbzRHeU1JR3ZNQTRHQTFVZER3RUIvd1FFQXdJSGdEQVBCZ05WSFNVRUNEQUdCZ1JWSFNVQU1FUUdBMVVkRGdROUJEdFZUMGxTT2tSTlNWVTZXRlZTVVRwTFZrRk1Pa3BLUzFjNlN6UlNSVHBGVGt4TE9rTlhSVXc2UkVwUFNEcFNWemRYT2s1RVNsUTZWVmhPV0RCR0JnTlZIU01FUHpBOWdEdFNUVWxHT2xGTVJqUTZRMGRRTXpwUk1rVmFPbEZJUkVJNlZFZEZWVHBWU0ZWTU9rWk1WalE2UjBkV1dqcEJOVlJIT2xSTE5GTTZVVXhJU1RBS0JnZ3Foa2pPUFFRREFnTklBREJGQWlFQTBkN3l1azQrWElabmtQb3RJVkdCeHBRSndpMzQwdExSb3R3Qzl4NkJpdWNDSUhFSmIyWGg0QzhtYVZic1Exd3ZUSCthRGV0VXhBS21lYkdXa3F6Z1J1Z1QiXX0.eyJhY2Nlc3MiOltdLCJhdWQiOiJodWIuZG9ja2VyLmlvIiwiZXhwIjoxNjQxMjY2MDE3LCJpYXQiOjE2NDEyNjU3MTcsImlzcyI6ImF1dGguZG9ja2VyLmlvIiwianRpIjoiV1dUV090ZVhnVWUwM0tWNWUwbEgiLCJuYmYiOjE2NDEyNjU0MTcsInN1YiI6ImM3YWJkMmU3LTJmNDgtNGFmNS1hOTExLTk5ZGM2MWQ2MmQ4OSJ9.D6YL422MrrS6bPv6A_BqEZa-6DhOWlkOvI2y2kq1uaIubSG09G7zodw97EE2RH2_1Wl94l0nVmN4nxSWHQvXT-e7v69XzLuO1gRxlFMZzmupn4JMRQ42UlFPM3VIKWeV3Opx4zLbtLvY1y9fR_ZSa3jcbP3HLKhBWH4dqYyp_oaFd3nVEgngEksyivqZHYu0JYID-EGw-2mZFFlLT030U3DcsFqcTsZWa1jfeDZIsxjdhEkqsxKbfqOpSY6-6p4b6Y0-1FDw1EiX2q4Y6PzbMfNJg9v_lQAftSUuCzMqrhVtrvPn07Su0nN_BpAJ5fDum5jHS1gDmmX7pnGnB0gd0g",
"scope": "",
"expires_in": 300,
"issued_at": "2022-01-04T03:08:37.398945485Z"
}
Document explicitly said :
refresh_token
(Optional) Token which can be used to get additional access tokens for the same subject with different scopes. This token should be kept secure by the client and only sent to the authorization server which issues bearer tokens. This field will only be set when access_type=offline is provided in the request.
The same effect is observed when I tested deployment of a private docker registry:2.7 along with a docker_auth (https://github.com/cesanta/docker_auth, version 1.9) authentication server.
From Docker registry OAuth specification, it seems the feature is already in place but if it does not work on Docker auth server and the other project follows this specification, I can't help to wonder if this is a feature in future or just I missed somethings in my configuration.
I am using the authentication code mode of Huawei account kit to login users to my app. To check the app server to account server behavior, I use the cURL command shown bellow to obtain the access token from the authorization code. But the following command would return an error.
curl -v -H "Content-Type:application/x-www-form-urlencoded" -d #body.txt -X POST https://oauth-login.cloud.huawei.com/oauth2/v3/token
the "body.txt" file contains the required information for the request:
grant_type=authorization_code&
code=DQB6e3x9zFqHIfkHR2ctp7htDs5tG5p6jXTkTCeoAAULtuS69PntuuD9pwqHrdXyvrlezuRc/aq+zuDU7OnQdRpImnvZcEX+RIOijYMXYu1j+zxpQ+W/J50Z7pY1qhyxZtavqkELY+6o2jSifaiIxC/MJc7KgqKV3jGn9kUIEZovSnM&
client_id=my_id&
client_secret=my_secrete&
redirect_uri=hms://redirect_uri
The command returns:
> POST /oauth2/v3/token HTTP/1.1
> Host: oauth-login.cloud.huawei.com
> User-Agent: curl/7.64.0
> Accept: */*
> Content-Type:application/x-www-form-urlencoded
> Content-Length: 430
>
* upload completely sent off: 430 out of 430 bytes
< HTTP/1.1 400 Bad Request
< Date: Mon, 23 Nov 2020 03:38:21 GMT
< Content-Type: application/json
< Content-Length: 67
< Connection: keep-alive
< Cache-Control: no-store
< Pragma: no-cache
< Server: elb
<
* Connection #0 to host oauth-login.cloud.huawei.com left intact
{"sub_error":20152,"error_description":"invalid code","error":1101}
What should I do to get this API call working using cURL as expected?
Authentication code must be urlencoded before sent. The command in the question used that code without urlencoding non-letter characters. Please use the same command with encoded authorization code as parameter to "code" to perform the request to acquire access token
Encoding could be done inline by if doing so is desired
curl --data-urlencode "para1=value1"
Please refer to: Link or using online tool such as : Link
Using other tools to acquire access token is possible as long as the parameters are properly encoded with %2x format.
According to the error information {"sub_error":20152,"error_description":"invalid code","error":1101}, the problem is caused by incorrect code parameters.
It is recommended that you can check whether the value of code in the request is the same as the Authorization Code obtained by the mobile app.
FOR Details,see docs.
I used the Spring REST service implementation to learn Swagger.
Service on GET - http://localhost:8080/greeting?name=Betlista returns
{
"id":5,
"content":"Hello, Betlista!"
}
So I created YAML file for Swagger as:
swagger: "2.0"
info:
version: "0.0.1-SNAPSHOT"
title: "Spring REST"
host: "localhost:8080"
basePath: "/"
tags:
- name: "Greeting"
schemes:
- "http"
paths:
/greeting:
get:
operationId: "greeting"
produces:
- "application/json"
parameters:
- name: "name"
in: "query"
required: false
type: "string"
responses:
"200":
description: "successful operation"
schema:
$ref: "#/definitions/GreetingResponse"
definitions:
GreetingResponse:
type: "object"
properties:
id:
type: "integer"
content:
type: "string"
The problem is, when I tried to execute it using "Try it out" button.
It seems (from Chrome's Network tab in developer tools) like there is no response:
...while regular call in browser works fine
edit: as I mentioned in comments, I verified curl generated by swagger and it works as expected - curl -X GET "http://localhost:8080/greeting?name=Betlista" -H "accept: application/json"
At the moment I'm looking into CORS topic (which makes no sense to me as documentation and service are both on localhost), I see in Chrome console this:
This is in fact problem of the service, not of the Swagger Editor.
I'm still looking for a solution, which is described here:
CORS uses special HTTP headers to allow cross-domain requests. The "try it out" feature requires the following headers in API responses:
Access-Control-Allow-Origin: https://host.from.which.the.request.came
Vary: Origin
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: ResponseHeader1, ResponseHeader2, ...
I tried to use Spring REST sevice with CORS, which on curl -I http://localhost:8080/greeting?name=Betlista returns:
HTTP/1.1 200
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
Content-Type: application/json
Content-Length: 37
Date: Mon, 02 Nov 2020 13:42:15 GMT
but this is still not working...
As I said, it's not the Swagger Editor problem, but service problem.
CORS check can be turned off in Chrome starting it chrome.exe --disable-web-security --user-data-dir=/tmp as described here which is of course not recommended, so I consider this as a workaround only.
What I used at the end was this - https://stackoverflow.com/a/47022289/384674
edit: later I used - https://stackoverflow.com/a/40300363/384674
I am trying to test my API documentation using openapi: 3.0.1 format. When trying to execute the endpoints from Swagger Hub documentation, I get TypeError: Failed to fetch.
The curl command that is shown runs fine from terminal:
curl -X GET "http://localhost:3030/services" -H "accept: application/json; charset=UTF-8"
The issue is both for Safari as well as Chrome browsers.
I have also enabled CORS for my golang application as per the following snippet:
allowedOrigins := handlers.AllowedOrigins([]string{"*"})
allowedCredentials := handlers.AllowCredentials()
exposedHeaders := handlers.ExposedHeaders([]string{"Content-Length", "ETag", "Link", "X-RateLimit-Limit", "X-RateLimit-Remaining"})
log.Fatal(http.ListenAndServe(":3030", handlers.CORS(allowedOrigins, allowedCredentials, exposedHeaders)(router)))
"Failed to fetch" means CORS is misconfigured. Specifically,
allowedOrigins := handlers.AllowedOrigins([]string{"*"})
means that your server always returns
Access-Control-Allow-Origin: *
but according to the SwaggerHub documentation you should return
Access-Control-Allow-Origin: https://app.swaggerhub.com
Vary: Origin
Access-Control-Allow-Origin
The value of this header must be set as follows:
If the request contains a non-empty Origin header (as in case of requests sent from a browser, such as “try it out” requests), return this origin along with the Vary: Origin header:
Access-Control-Allow-Origin: https://host.from.which.the.request.came
Vary: Origin
If the request does not have Origin, return the * wildcard:
Access-Control-Allow-Origin: *
I am using EmberJS to communicate with an MVC Web API using Auth0 for authorization. When I have a valid bearer token I can communicate and retrieve data from the Web API just fine. When the token expires the Web API returns an an expected 401 the following message is displayed in the browser console:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:4200'
The ajaxError method of the RESTAdapter is called as expected, but the jqXHR.status field is 0.
export default
DS.RESTAdapter.extend({
namespace: 'api',
host: webApiUrl,
headers: function() {
return {
"Authorization": 'Bearer ' + localStorage.getItem('userToken'),
};
}.property().volatile(),
ajaxError: function(jqXHR) {
var error = this._super(jqXHR);
if (jqXHR && jqXHR.status === 401) {
Ember.Logger.info("Not Authorized");
}
Ember.Logger.info("Error " + jqXHR.status + " calling API redirecting to login.");
}
});
Here is a sample of the response returned from the API:
HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.0
X-AspNet-Version: 4.0.30319
X-SourceFiles: =?UTF-8?B?QzpcU291cmNlXFBheWNvckRldlxTb3VyY2VcSW50ZWdyYXRpb25cR2VuZXJhbFxNYWluXFBheWNvci5JbnRlZ3JhdGlvbi5PcGVyYXRpb25zXFBheWNvci5JbnRlZ3JhdGlvbi5PcGVyYXRpb25zLkFwaVxhcGlcbG9nZ2luZ0V2ZW50cw==?=
X-Powered-By: ASP.NET
Date: Fri, 30 Jan 2015 16:45:35 GMT
Content-Length: 927
I have tried XML and plan/text Content-types, but the result is the same.
I don't believe this is an actual CORS issue because this problem only occurs when the API returns an error; otherwise I'm downloading and displaying the data just fine.
Does anyone know what the issue might be?
Thanks in advance.
I was having the same issue and it was a CORS issue.
I'm not sure what backend your api server is but mine is a Rails API and the solution was to move the CORS middleware to the top of the middleware stack
config.middleware.insert_before 0, 'Rack::Cors' do
allow do
origins '*'
resource '*', :headers => :any, :methods => [:get, :post, :options]
end
end
The issue is a bit confusing because before fixing the problem if I made a request using cURL I receive the correct response with the right headers etc
$ curl -I -X GET -H 'Accept: application/json' http://api.example.dev/foo
HTTP/1.1 401 Unauthorized
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Pacu-Media-Type: v1
Content-Type: application/json; charset=utf-8
X-Rack-CORS: preflight-hit; no-origin
X-Request-Id: def30b49-895f-4581-82ec-87bcfb6c44e5
X-Runtime: 0.010945
Date: Sun, 22 Feb 2015 03:30:35 GMT
Connection: close
and the correct error message
$ curl -X GET -H 'Accept: application/json' http://api.example.dev/foo
{"errors":[{"id":"01ac93be-ea7a-4d8e-b86b-9ea1f4136b11","title":"unauthorized","detail":"The access token is invalid","status":"401"}
The problem is that cURL is not making a cross site request and therefore CORS isn't needed. When attempting to connect using jQuery the request would fail with the following error in the browser's dev console.
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:4200' is therefore not allowed access. The response had HTTP status code 401.
The response status was 401 but the response body was empty and the jqXHR.status was set to 0.
Again the reason was because my Rails backend CORS middleware needed to be at the top of the rack stack order. In Rails since I am using the Routes Engine as an exceptions app config.exceptions_app = self.routes I needed the CORS middleware to load before it in ActionDispatch::ShowExceptions