I'm attempting to fetch the bearer token for OroCommerce, via POSTMAN and am encountering a 405 error, for the following request:
URL: http://<OroCommerce DNS>/oauth2-token
Header: Content-Type: application/json
Body:
{
"grant_type": "client_credentials",
"client_id": "XXXX",
"client_secret": "XXXX"
}
I have generated the public and private keys and added them to the /var directory of the application. Per this issue, I have tried "Enabled Guest Access" checked and unchecked. Both result in the same 405 error w/ HTML in the response (see image below). The back-end is up, when attempting these requests. Any suggestions on where to look (configurations, etc), in order to successfully fetch the bearer token, via the REST API?
Response HTML
First of all, make sure an API is enabled: https://doc.oroinc.com/api/enabling-api-feature/.
Then, make sure you are using the POST HTTP method to submit the request.
If it wouldn't help, make sure the maintenance mode is fully disabled. It's step 13 in the upgrade guide: https://doc.oroinc.com/backend/setup/upgrade-to-new-version/#id1
Check the application log at var/logs/prod.log for errors. Usually, the error message explains what is wrong, or at least, you can use it to google the issue.
If nothing works, you can try to access the same endpoint using the dev environment. There should be a more explicit error message with the stack trace. Or enable an xdebug extension and check it step by step.
Related
When calling the /{realm}/logout-all endpoint, the request always results in a "500 - Internal Server Error" and "error": "unknown_error" in the body. All other endpoints work as they should.
I made sure to call the endpoint with a new token and the Authorization-key in the header of the request. All calls are made from postman for testing.
Did I miss something?
Edit 1:
Keycloak Version: 12.0.2
The call: (generated the token with the admin-cli client and the admin user, so pribvileges shoudln't be a problem (?))
The log:
For future reference and anyone who has the same problem with Keycloak:
In some of the requests (e.g. logout-all) you have to provide a Accept: application/json header, otherwise Keycloak defaults back to application/octet-stream, for which Keycloak is missing the necessary classes.
error :"405 not allowed Method" in post method type call in request command vue
i need call api function with content-type:application/json and post Method type with request command in vue ,but browser add preflight request with options method type and it causes this error :"405 not allowed Method"
var options = {
method: "POST",
url: "http://api.sample.com/login",
headers: {
"Access-Control-Request-Method":"POST",
"cache-control": "no-cache",
"content-type": "application/json",
},
body: '{ Username: "demo", Password: "demo", Domain: "test" }'
};
request(options, function(error, response, body) {
if (error) throw new Error(error);
body.data;
alert("ok");
});
The OPTIONS call is done whenever you do a cross-origin request. This means the domain your application is running on is different from the domain where the api is. A pre-flight request is mandatory for these requests, because the browser needs to figure out if you are allowed to do these requests. A 405 error means that the server thinks you are not allowed to make that request.
To solve this problem you can move your api to the same domain as your frontend. Please note that it cannot be on a subdomain.
A different way of solving this, is by sending back the correct headers. In your case you seem to at least miss the Access-Control-Allow-Methods response header. Make sure to send this header and either dynamically figure out which methods are allowed, or do something like the following. That would allow the most common methods to work.
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
In the comments you said that you do not have control over the api, and as such cannot change the response header. In that case your best bet is to contact whoever maintains the api and ask how to best use their api.
In the comments you said that this worked fine when you did the same thing in ASP.NET. ASP.NET is a server-side language, which means that requests in that context do not have a concept of "cross-origin". Cross-origin only comes into play in the browser, where the application runs on an actual domain.
Assuming you can set up a proxy on your application domain, you can also create a proxy that proxies all requests to the api you actually want to communicate with. You would deploy your domain on https://example.com and do your requests to https://example.com/api/endpoint. Your proxy will listen for requests that begin with https://example.com/api and proxy it to https://whatever.the.api.is/ with the appropriate endpoint and data.
Please keep in mind that while some api's might just be configured incorrectly, a lack of cross-origin response headers might just mean that the api is nog meant to be consumed through the browser. Part of this could be that the request contains a secret that should not be exposed to users that use your application, but should instead only be on the server. Using a proxy in that case would set you up for impersonation attacks, because you would expose the secret to your application, but defeat the cross-origin headers by making it appear to the application that the api is on the same domain.
Today I have a problem with the resumable upload feature of OneDrive via the Microsoft Graph API, as described here. I have integration tests which previously worked, which now fail.
I successfully call createUploadSession and get an uploadUrl to use. I've replaced actual tokens with "XXX" here.
POST https://graph.microsoft.com/V1.0/groups/273c2c33-8533-445d-ae65-4b63be296995/drive/root:/c2fa1a83-74f3-444b-9263-c9539ee3eae2.txt:/createUploadSession HTTP/1.1
Authorization: Bearer XXX
{
"item": {
"#microsoft.graph.conflictBehaviour": "replace"
}
}
Response:
{
"#odata.context": "https://graph.microsoft.com/V1.0/$metadata#microsoft.graph.uploadSession",
"expirationDateTime": "2017-04-27T11:07:50.5650598Z",
"nextExpectedRanges": ["0-"],
"uploadUrl": "https://sageglodbizp.sharepoint.com/sites/SharePointTests/_api/v2.0/drive/items/01LQXPMG56Y2GOVW7725BZO354PWSELRRZ/uploadSession?guid='9d14ed72-e532-442e-94e8-70952b365527'&path='~tmp0B_c2fa1a83-74f3-444b-9263-c9539ee3eae2.txt'&overwrite=True&rename=False&access_token=XXX"
}
So the uploadUrl is there. Then, I try to PUT a chunk to this url but get a 401 Unauthorized in response:
PUT https://sageglodbizp.sharepoint.com/sites/SharePointTests/_api/v2.0/drive/items/01LQXPMG56Y2GOVW7725BZO354PWSELRRZ/uploadSession?guid='9d14ed72-e532-442e-94e8-70952b365527'&path='~tmp0B_c2fa1a83-74f3-444b-9263-c9539ee3eae2.txt'&overwrite=True&rename=False&access_token=XXX HTTP/1.1
Authorization: Bearer XXX
Response
HTTP/1.1 401 Unauthorized
As I'm using the URL provided by the Graph API, I believe this to be a bug. I'm passing the same bearer token to the second call as the first (I've also tried it with no access token, given that one is in the URL).
I have tried this with two different Office 365 tenants, both with the same result.
This has previously worked. Any thoughts on why this has stopped working? Is it correct that the uploadUrl points to my SharePoint endpoint rather than the Graph API?
I should also add, a non-resumable upload directly to the Graph API works fine.
Any suggestions most welcome.
EDIT:
This seems to be affected by the length of the filename to which you upload:
myfile-123100000000000000000000000.txt works successfully
myfile-1231000000000000000000000000.txt fails
This was confirmed as a bug by Microsoft and fixed on Saturday 29 / Sunday 30 April 2017.
Per the documentation:
Including the Authorization header when issuing the PUT call may result in a HTTP 401 Unauthoized response. The Authoization header and bearer token should only be sent when issueing the POST during the first step. It should be not be included when issueing the PUT.
If you remove the Authorization: Bearer XXX header from your PUT call should resolve this issue.
I was using github API in Meteor but could not solved this issue:
This code tries to get the total number of traffic for a certain repo.
HTTP.call( 'GET', 'https://api.github.com/repos/hackmdio/hackmd/traffic/views',
{
headers:
{
'Content-Type':'application/json',
"Accept":"application/vnd.github.v3+json",
"User-Agent": "whales"
},
},
function( error, response ) {
if ( error ) {
console.log('---------------------------error occurred-----------------------------------')
console.log('---------------------------error occurred-----------------------------------')
console.log( error );
} else {
console.log('--------------------------data got it!!-------------------------------------')
console.log('--------------------------data got it!!-------------------------------------')
console.log(response);
}
});
Error:
{
"message": "If you would like to help us test the Repo Traffic API during its preview period, you must specify a custom media type in the 'Accept' header. Please see the docs for full details.",
"documentation_url": "https://developer.github.com/v3"
}
I searched for similar issues and added "Content-Type" and "Accept" but it's still not working.
I then tried doing this in Postman and also in terminal with the same headers but this error kept happening.
Thanks a lot.
You will need to add an Accept: application/vnd.github.spiderman-preview header to your request in order to access the Repo Traffic API whilst it is in preview form. From the API docs:
APIs for repository traffic are currently available for developers to preview. During the preview period, the APIs may change without advance notice. Please see the blog post for full details.
To access the API you must provide a custom media type in the Accept header:
application/vnd.github.spiderman-preview
The Commit Search API is currently available for developers to preview. During the preview period, the APIs may change without advance notice.
To access the API you must provide a custom media type in the Accept header:
Accept: application/vnd.github.cloak-preview
☝️This header is required.
check docs
To anyone who ends up on this page after googling why GitLab API has started throwing 415 when sending POST requests:
Make sure you pass the Content-Type: application/x-www-form-urlencoded header if you're sending stuff via post-data fields. Their docs never mention this b/c apparently many clients (like curl) do this automatically.
There is no authentication on server side so authentication should not be issue.
URL format: PUT
https://localhost/api/v1/protections?integrationKey=111&userKey=1111&group=111&category=foo
Payload:
{"action":"BLOCK"}
This is working fine in Postman.
In SOAP UI , I am giving input as under:
EndPoint: https://localhost
Resource: /api/v1/protections
Parameters:?integrationKey=111&userKey=1111&group=111&category=foo
in Media type, I am selecting "application/json"
and entering {"action": "BLOCK"} but getting "Wed Jan 20 16:25:27 PST 2016:DEBUG:Receiving response: HTTP/1.1 403 Forbidden
"
Is there any suggestion to get the output in SOAP UI.
Depending on the server where the rest is exposed service generates an HTTP 403, you should verify that server is and thus find the fastest response.
Also try making a GET request from the browser to see if you can answer correctly because problem lock your machine to the server.
As is https, it may be that you lack some certificate set SOAPUI. possibly Postman you use already has configured. Try to check this setting.
In my case, I missed the Header "User-Agent" and "accept". I put in Soap UI and Works.
In Postman, this headers it put automatically.