When I try this RAML in the mocking service, I get a 200 success response back even when I don't include a client_id and client_secret. Is that normal? Shouldn't I get a 401 response if I leave the headers empty, as I've defined them to be required?
#%RAML 1.0
title: Test
description: testing cloudhub
traits:
client-id-required:
headers:
client_id:
type: string
required: true
client_secret:
type: string
required: true
responses:
401:
description: Unauthorized or invalid client application credentials
500:
description: Bad response from authorization server, or WSDL SOAP Fault error
/something:
is: [client-id-required]
get:
responses:
200:
body:
application/json:
example:
{
"hello" : "goodbye"
}
The Mocking Service should validate the missing headers. It is not clear why it is not. But I don't see any reason for it to respond with a 401. It is mocking a response, not trying to authenticate. It doesn't really implement the API after all. There is no reason for it to assume these headers are for authentication, just that they are required headers for your API.
Have you defined the headers but with an empty value? That may match the definition of required so they pass validation.
Related
To be precise, In order to make api requests to aws services over http, one must sign the requests using Sigv4 process(recommended by aws, described here https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html ). It has a sophisticated procedure in which the http request headers must be included in sign. I've added the essential headers for signing through Authorization header for createLogStream action of Cloudwatch logs service,
'Host': 'logs.<region>.amazonaws.com',
'Content-Type': 'application/x-amz-json-1.1',
'X-Amz-Date': <AMZ_DATE>,
'X-Amz-Target': Logs_20140328.CreateLogStream,
'X-Amz-Content-Sha256': <PAYLOAD_HASH>,
And making a Http request to https://logs.{region}.amazonaws.com/?Action=CreateLogStream&version={version} from the frontend application.
However, the following response error (400) occurs,
message: "The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details."
__type: "InvalidSignatureException"
I have checked the secret access key and the signed headers, they were fine;
If I remove Content-Type header, I get a successful 200 response, but the response results in
{Output: {__type: "com.amazon.coral.service#UnknownOperationException", message: null}, Version: "1.0"}
One of the solutions to fix this issue recommends to add the Content-Type header (com.amazon.coral.service#UnknownOperationException when triggering CodeBuild from API Gateway).
Should Content-Type header be included? Would be great if any help on what headers must be included and the specific api version for Cloudwatch logs to be set ?
Thanks in advance!!!
I need to auto login on my React App. To do this, I use NTLM authentication. Both , API (php coded) and React App are on an IIS server.
I use axios for API calls. When I do GET request, all is right, crendentials are successfully sent (but I must disable anonymous login on IIS).
When I use POST query, it fails with 401 error.
I tried several headers but nothing works. That's why I need help.
Image : Nothing weird in headers
When I do GET, I see cookie sent, not with my post query
axios.post(apiUrl+'deleteUserReportFolder.php', {
reportFolder: e.target.value,
id: user.login
},{
withCredentials: true,
credentials: 'include',
headers: {
'Content-Type': "application/json",
'Authorization': 'NTLM',
'WWW-Authenticate': 'NTLM'
}
})
The API Site is sending these HTTP Response Headers:
Image : IIS API
Thanks for your help. I've seen a lot of posts but nothing worked.
Edit :
I tried by setting my server (API PHP) with anonymous and Windows login, anonymous login cause no logon user, so I must set Windows enabled only.
I tried by removing all headers except "withCredentials" in axios query. I still have 401 error on CORS Pre Flight.
var_dump($_POST);
Check this code，May be it's helpful!
"error":"invalid_request","error_description":"AADSTS900144: The request body must contain the following parameter: 'grant_type'.
This is the error I am getting while exchanging my client side token to server-side token.
I gave all additional consent.
client_id: ****,
client_secret: ***,
grant_type: 'urn:ietf:params:oauth:grant-type:jwt-bearer',
assertion: clientSideToken,
requested_token_use: 'on_behalf_of',
scope: 'https://graph.microsoft.com/User.Read'
This is my request body for the consent
Based on your error message, I guess this should be caused by you not setting the request parameters correctly. You should put the request parameters in the request body.
I have two sets of servers:
apache serving up html/js/css pages in the angular flavor
SalesForce backend rest apis serving up Json
Salesforce has OAuth authentication, but it is not letting the javscript even perform an OPTIONS call in order to figure out if it can do the POST call it really wants to:
Is there any way to get around this without a proxy or jsonp?
is the Salesforce APEX Rest API configured wrong? the source domain is already whitelisted...
Update:
so some angular code to make the call:
var config = {
method: 'POST',
url: SalesforceRestApi,
headers: {
Authorization: "OAuth "+authToken,
"Content-Type": "application/pdf"
},
data : caseRequest,
};
var http = angular.element(document.body).injector().get('$http');
http(config).then(function(response){ console.log(response); });
this code here returns the good old Chrome error:
XMLHttpRequest cannot load https://xxx.salesforce.com/services/apexrest/xxx/v1/. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://sample.com' is therefore not allowed access. The response had HTTP status code 401.
I'm currently deploying a basic API to my live server and I'm running into (what I think is) a CORS problem but there is some behavior going on that I can't explain.
I'm communicating from an AngularJS front-end to a Laravel 5 (+ laravel-cors) back-end.
I started testing with a simple jQuery AJAX call (below) and when I make a request from my local Vagrant environment (http://dev.example.local/test.html) to http://api.example.com/v1/matches I get an error about Access-Control-Allow-Origin. The weird thing is that the request does come through because the information is stored in the database via the Laravel-based API correctly.
$.ajax({
method: 'POST',
url: 'http://api.example.com/v1/players',
data: {
"username": "username",
"first_name": "First",
"last_name": "Last",
"nickname": ""
}
}).always(function(r) {
console.log(r);
});
Error:
XMLHttpRequest cannot load http://api.example.com/v1/players. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://other.example.com' is therefore not allowed access.
The console.log(r) returns {readyState: 0, responseJSON: undefined, status: 0, statusText: "error"}
I developed the application locally using a Homestead VM (API) and a Vagrant environment (application) and it's working correctly within these environments...
Some observations:
Each of these requests shows up with Method: POST, Status: 200 OK, Type: xhr in my Chrome Developer Tools.
Tools like Postman and PhpStorm's RESTful service tester correctly execute the request and the data is added without errors.
Any ideas on how to further debug this problem are welcome... I've been trying to wrap my head around this for the entire day now and I just don't know what's causing it.
Your server must return an appropriate Access-Control-Allow-Origin header in the response. For example, if the request is being sent from http://stackoverflow.com, then your server must return this header: Access-Control-Allow-Origin: http://stackoverflow.com. You can determine, server-side, what the origin is by looking at the Origin header on the request. If your server does not return this header in the response, you will not have any access to the properties of the response browser-side (such as the status code, headers, or message body). The Same Origin Policy is at the center of this restriction.
The reason you are not seeing any similar issues when the request is sent by Postman or PhpStorm's RESTful service tester is due to the fact that these services do not send an Origin header with the request, as they are not subject to the Same Origin policy. By default, the browser will append this header to any cross-origin ajax requests, as browsers are subject to the Same Origin Policy. In my previous scenario, the request header would look like this: Origin: http://stackoverflow.com. Browsers that implement the CORS spec are required to add this request header so the server is able to determine if the origin of the request has been whitelisted for cross-origin ajax requests. If this is the case, the server will return the proper Access-Control-Allow-Origin header. If not, it can simply omit the header. Browsers that do not implement the CORS spec will simply refuse to send such an ajax request.
Regarding your bewilderment as to why the request is being sent in the first place, that comes down to a distinction between "simple" and "non-simple" CORS requests. For simple CORS requests, the request will always be sent to the server, but the client/JS will not be able to parse the response without proper acknowledgement from the server. Some CORS requests are not simple, so to speak. These are, for example, DELETE or PATCH requests, or POST/GET requests that contain non-standard headers (such as X-headers or a Content-Type of "application/json" as opposed to "multipart/form-data"). In other words, a request is not simple if it cannot be sent without JavaScript. For example, a <form> submit, or a GET request from a <script src="..."> will always send "simple" requests. For non-simple requests, the browser must "preflight" the request. This means that the browser sends an intermediate request, called a preflight, before the original request. This preflight request is an OPTIONS request. The server must than return headers in the response to this preflight that acknowledge any non-standard properties of the original request. If it does, then the browser will send the original request.
You can read more about preflighting and CORS in general on MDN.