How does ASP.NET web Api interprets an empty/no accept header in the request?
will it by default take it as application/json, etc...?
Considering w3 specifications the web-servers can negotiate to each other based on these rules including allowing request method types(GET, POST, etc), content-type and etc. If you wana accept an additional header in your webserver you must define that variable in your webserver configurations, despite not defining this variable cause your webserver won't recieve requests containign that variable in the request header. Default content-type in http request is text/plain.
Hope this can help u bro. Regards.
Related
When Authorization header present in the inbound request, it's always a Cache Miss. My requirement is, I need ATS to treat the Authorization header like any other header (It should not cause cache miss and it should get forwarded to upstream service). How can I achieve this.
This may sound non-secure, but, I have a specific usecase for this. This cache is for internal use and it's access is controlled by other means.
I tried this
As per the official documentation
By default, Traffic Server does not cache objects with the following
request headers:
Authorization
Cache-Control: no-store
Cache-Control: no-cache
To configure Traffic Server to ignore this request header,
Edit proxy.config.http.cache.ignore_client_no_cache in records.config.
CONFIG proxy.config.http.cache.ignore_client_no_cache INT 1 Run the
command traffic_ctl config reload to apply the configuration changes.
but, no luck
If your origin returns a cache-control header with the 'public' directive (for instance, "Cache-Control: max-age=60,public") or including the s-maxage directive (for instance, "Cache-Control: s-maxage=60"), ATS should start caching the object. The relevant http RFC:
https://www.rfc-editor.org/rfc/rfc2616#section-14.8
When a shared cache (see section 13.7) receives a request
containing an Authorization field, it MUST NOT return the
corresponding response as a reply to any other request, unless one
of the following specific exceptions holds:
1. If the response includes the "s-maxage" cache-control
directive, the cache MAY use that response
...
3. If the response includes the "public" cache-control directive,
it MAY be returned in reply to any subsequent request.
Similarly, you could also use the header_rewrite plugin to remove the Authorization header from the request, or to add public/s-maxage.
Actually this https://docs.trafficserver.apache.org/en/latest/admin-guide/configuration/cache-basics.en.html#configuring-traffic-server-to-ignore-www-authenticate-headers did the trick for me.
The following instructions was applicable for Authorization header as well, besides WWW-Authenticate Header. They need to update the documentation.
Configuring Traffic Server to Ignore WWW-Authenticate Headers
By default, Traffic Server does not cache objects that contain WWW-Authenticate response headers. The WWW-Authenticate header contains authentication parameters the client uses when preparing the authentication challenge response to an origin server.
When you configure Traffic Server to ignore origin server WWW-Authenticate headers, all objects with WWW-Authenticate headers are stored in the cache for future requests. However, the default behavior of not caching objects with WWW-Authenticate headers is appropriate in most cases. Only configure Traffic Server to ignore server WWW-Authenticate headers if you are knowledgeable about HTTP 1.1.
To configure Traffic Server to ignore server WWW-Authenticate headers:
Edit proxy.config.http.cache.ignore_authentication in records.config.
CONFIG proxy.config.http.cache.ignore_authentication INT 1
Run the command traffic_ctl config reload to apply the configuration changes.
I've been working on a classic SPA where the front end app lives on app.example.com while the API lives on api.example.com, hence requiring the use of CORS requests. Have setup the server to return the CORS header, works fine.
Whenever an AJAX request is not simple, the browser makes an extra OPTIONS request to the server to determine if it can make the call with the payload. Find Simple Requests on MDN
The question is: What are the actual benefits of doing the OPTIONS request, especially in regards to security?
Some users of my app have significant geographical latency and since the preflight cache doesn't last long, the preflight requests cause latencies to be multiplied.
I'm hoping to make POST requests simple, but just embedding the Content-Type of application/json negates that. One potential solution is to "hack" it by using text/plain or encoding in the url. Hence, I hope to leave with a full understanding of what CORS preflight requests do for web security. Thanks.
As noted on the article you linked to:
These are the same kinds of cross-site requests that web content can
already issue, and no response data is released to the requester
unless the server sends an appropriate header. Therefore, sites that
prevent cross-site request forgery have nothing new to fear from HTTP
access control.
Basically it was done to make sure CORS does not introduce any extra means for cross-domain requests to be made that would otherwise be blocked without CORS.
For example, without CORS, the following form content types could only be done cross-domain via an actual <form> tag, and not by an AJAX request:
application/x-www-form-urlencoded
multipart/form-data
text/plain
Therefore any server receiving a request with one of the above content-types knows that there is a possibility of it coming from another domain and knows to take measures against attacks such as Cross Site Request Forgery. Other content types such as application/json could previously only be made from the same domain, therefore no extra protection was necessary.
Similarly requests with extra headers (e.g. X-Requested-With) would have previously been similarly protected as they could have only come from the same domain (a <form> tag cannot add extra headers, which was the only way previously to do a cross-domain POST). GET and POST are also the only methods supported by a form. HEAD is also listed here as it performs identically to GET, but without the message body being retrieved.
So, in a nutshell it will stop a "non simple" request from being made in the first place, without OPTIONS being invoked to ensure that both client and server are talking the CORS language. Remember that the Same Origin Policy only prevents reads from different origins, so the preflight mechanism is still needed to prevent writes from taking place - i.e. unsafe methods from being executed in a CSRF scenario.
You might be able to increase performance using the Access-Control-Max-Age header. Details here.
I'm loading my script on a domain and sending some data with POST and the use of Ext.Ajax.request() to that same domain.
Somehow the dev-tools show me, that there is a failed OPTIONS request.
Request URL : myurl-internal.com:8090/some/rest/api.php
Request Headers
Access-Control-Request-Headers : origin, x-requested-with, content-type
Access-Control-Request-Method : POST
Origin : http://myurl-internal.com:8090
It's both HTTP and not HTTPS. Same port, same host ... I don't know why it's doing this.
The server can't handle such stuff and so the request fails and the whole system stops working.
It's not really specific to Ext JS -- see these related threads across other frameworks. It's the server properly enforcing the CORS standard:
for HTTP request methods that can cause side-effects on user data (in
particular, for HTTP methods other than GET, or for POST usage with
certain MIME types), the specification mandates that browsers
“preflight” the request, soliciting supported methods from the server
with an HTTP OPTIONS request header, and then, upon “approval” from
the server, sending the actual request with the actual HTTP request
method.
If you're going to use CORS, you need to be able to either properly handle or ignore these requests on the server. Ext JS itself doesn't care about the OPTIONS requests -- you'll receive the responses as expected, but unless you do something with them they'll just be ignored (assuming the server actually allows whatever you're trying to do).
If you are NOT intending to use CORS (which sounds like you aren't purposefully going cross-domain) then you need to figure out why the server thinks the originating domain is different (I'm not sure about that). You could also bypass CORS altogether by using JsonP (via Ext's JsonP proxy).
Use relative url instead of absolute, then you will get expected result.
use before request
Ext.Ajax.useDefaultXhrHeader = false
Is it possible to know that a HTTP request is from Ajax?If yes, how?
Many frameworks add a header X-Requested-With set to XMLHttpRequest when sending an AJAX request. If you are using jQuery or Microsoft frameworks, this should work. If using another framework, you'll have to check the documentation. Since normal requests don't have the header, a check for the presence of the header should be sufficient.
If you are using your own "home-built" AJAX or the framework doesn't do this, but does allow you to set a header, you could simply follow this convention and add your own header when making the request.
Most frameworks set X-Requested-With header to state it. But standard AJAX requests doesn't.
I would assume that any request received by a server would appear to be the same (ie http post/get) and that you would need to look at the referer, but that may just give you the browser details?
My team is building a site that uses AJAX calls to WCF services for all state changes. Those services only accept a request if its method is POST and its Content-Type is 'application/json'. Assuming that our site has no XSS vulnerabilities, is this sufficient protection against CSRF for our WCF services? Is it possible for an attacker to create a cross-site POST with a custom Content-Type header?
[EDIT]
Obviously there are several ways for a malicious third party site to construct an HTTP POST request to my site. As far as I am aware, however, none of these methods allow for changing the Content-Type header. XHR and Flash both let you set headers, but have strict cross-site restrictions.
Probably, but why not go ahead and check the HTTP Referrer header? Then you will know for sure.