I want to know is there any property in Response object of ASP.NET that can tell me if response has already been flushed and no further actions can be performed on the response ?
I have a application where we add cookies to each outgoing response (through HTTP module), now if response is already flushed then cookie addition causes error.
can anyone help me out in this one.
For anyone who may need an answer to this and came here from google or else like me, here is a similar question for which a solution is given :
How can I tell when HTTP Headers have been sent in an ASP.NET application?
Related
I'm currently trying to replicate a https request with the following headers.
The authentication is based on a Session Cookie.
However, there is also a header field called :authority,
which I'm not able to replicate in Postman.
Also, couldn't I find any solution for that problem
or what exactly the :authority header means on the Internet.
This header seems to be required, as I'm getting a 400 error code back
as soon as I send my replicated request.
I've proxied the request sent from Postman and can confirm that the only difference at the first glance is the missing :authority header.
Thanks ^^
Alright, taking a closer look at the Raw Request, I noticed that the actual header is called Host and is mapped in the UI to :autority. Now its working. cheers
I've been stuck on this for a few hours with no luck, so I figured that I would ask here.
I have a service with a bunch of endpoints, most of which accept GET and POST http methods. In that case, my service simply specifies Access-Control-Allow-Origin to be * in the response headers, in the event that one of my apps is on a different domain/port and wants to use the service.
I have one endpoint that uses the DELETE http method, and I can't seem to get it to work. When I call this endpoint from my client app, I get this message in my console:
Response to preflight request doesn't pass access control check:
No 'Access-Control-Allow-Origin' header is present on the requested resource.
I've been reading up on CORS for the past couple hours and have tried a few different things, all of which have not worked. I (think I) at least understand that when I'm using http methods other than GET and POST, the browser sends a pre-flighted request with OPTIONS as the http method.
What is the best way to handle this? Is there a way to disable this pre-flighted request? I specify in my client app that the http method to call this endpoint is DELETE. Should I be putting something specifying headers in my AJAX function that calls this endpoint (I'm using straight JavaScript)?
If I can't figure out a way around this, I'm just going to change my endpoint to use a GET or POST method, but I wanted to find a way to handle this issue before I took the easy way out.
I (think I) at least understand that when I'm using http methods other than GET and POST, the browser sends a pre-flighted request with OPTIONS as the http method.
Yes
Is there a way to disable this pre-flighted request?
No there isn’t. It’s initiated by browsers automatically, with no way to disable it from your JS. As long as you’re sending that DELETE request cross-origin in your JS, browsers will do that preflight.
Should I be putting something specifying headers in my AJAX function that calls this endpoint?
Given the “No 'Access-Control-Allow-Origin' header is present on the requested resource” message you’re getting, no changes you make in your client code will make any difference.
The place where more headers need to be sent to deal with this is instead on the server side.
If I can't figure out a way around this, I'm just going to change my endpoint to use a GET or POST method
You might want to experiment with trying that first. It seems even if you make that change you’re still gonna get that “No 'Access-Control-Allow-Origin' header is present on the requested resource”.
The SO question "No 'Access-Control-Allow-Origin' header is present on the requested resource" is a good place to read up on this to get a better idea of what’s happening.
I'm creating a RESTful service to provide data to a web application. I have two related questions about this.
1. How to deal with unauthorized requests?
I'm intending to respond to requests with the following codes:
Is the resource open and found? 200 OK
Do you need to be authenticated to access the resources? 401 Unauthorized
Don't you have access to a category of resources? 403 Forbidden
Do you have access to a category of resources, but not to this specific resource? 404 Not Found to prevent people from getting to know the existance of a resource they do not have access to.
Doesn't the resource exist? 404 Not Found
Is this a recommended way for a RESTful service to behave?
2. What WWW-Authenticate header should 401 responses supply?
I read on Wikipedia (probably not the most accurate resource, but it works for me) that a 401 response must include a WWW-Authenticate header, however upon further searching I couldn't really find any resource that stated what this value means and what it should be.
I found several SO questions and forum topics about this header and they all seem to be about OAuth, suggest against using 401 status codes or say you can just make something up.
What is the correct value this header should contain?
To answer your questions:
How to deal with unauthorized requests?
The way you described it is pretty much the recommended way for a RESTful service. As far as I can see there is absolutely nothing wrong with that.
What WWW-Authenticate header should 401 responses supply?
In general the WWW-Authenticate header tells the client what kind of authentication the server will accept. If the client makes an unauthorized request, which means he is sending a request with a missing or invalid Authorization header, the server will use WWW-Authenticate to tell the client what authentication scheme he will accept (i.e. Basic, Digest or OAuth) and for what realm.
Imagine it like some kind of identification question or challenge on the part of the server, i.e. something like "Who are you?" or "Prove who you are by providing credentials in the following way!".
For Example: WWW-Authenticate: Basic realm="My App"
Here the server tells the client that he uses an authentication scheme named Basic. The realm is nothing more than some string that identifies a protected space on the server.
Based on my research (googling) i decided to send: Newauth realm="use login token".
The website http://greenbytes.de/tech/tc/httpauth/#unknown has test cases for different auth methods and i haven't found anything which describes 'get auth token' and therefore i think it is a 'Newauth'.
Also important for me: This doesn't create a login prompt on client side.
We recently ran an Appscan aganist an application and on a few pages the report shows:
The following changes were applied to the original request:
Set HTTP header to 'http://bogus.referer.ibm.com'
Reasoning:
The same request was sent twice in different sessions and the same response was received.
This shows that none of the parameters are dynamic (session identifiers are sent only in
cookies) and therefore that the application is vulnerable to this issue.
I'm a bit confused on how to handle this, should i just look at the Request.UrlReferrer and make sure it's the same host as what's in the URL or is there a better way to handle this?
Thanks.
The Referrer header can be spoofed quite easily. You need to use CSRF tokens (I recommend the Synchronizer Token Pattern) that will prove the origination of the request. There is an awesome resource at OWASP that you should definitely read. Good luck!
I have a question about REST. I´m creating a service, in which the client sends HTTP request with Basic authorization (Header Authorization: Basic user:password). I want the server to control user credentials, and if they are correct, it would send 200 OK, otherwise 401 Unauthorized. If the credentials are OK, I want to send back also user´s ID. My question is, what would be the best way to send that? My options are: headers, or json in the body of the response. Thanks you in advance.
Personally, I would send it back in the body. I don't think there are any standard headers suitable for that type of information, unless you are setting it in a cookie.