1

I've created a Web API project in ASP.Net, and am having some trouble getting the authentication working.

The API is expecting a token to be submitted in the Authorization header in each request. The code that checks to see if the header is set checks if the

HttpRequestMessage.Headers.Authorization

property is null. The first few times I tested this, I discovered that this property was always null, but the strange part is that if you checked the HttpRequestMessage.Headers enumerable, the Authorization header WAS set correctly (also if you did HttpRequestMessage.Headers.ToString(), it would appear there too).

Stranger still, I found that if I removed some of the attributes that are sent in the token, I could get it to work as expected. So it was as though the Authorization property wasn't being set if the header value's character length was too long. Unfortunately, even when manually removing some of the text from the token, it would then proceed to fail on a digest check, as it should!

I can't find any documentation that mentions this, so I was wondering if anyone else has come across it? I don't think the header is too long for IIS, because the header value appears in HttpRequestMessage.Headers.ToString(), so it IS being received, but for some reason it's not being assigned to the Authorization property.

Unfortunately I can't re-write the code that checks this property (this seems the easy solution) because it's apart of the Thinktecture library (ie not written by ourselves).

dark_perfect
  • 1,458
  • 1
  • 23
  • 41
  • did you get any solution to this problem? I am facing exact same problem. If my header is `Authorization: Basic` then it all works fine but for `Authorization: Digest` it is same behavior as you described above. – Suhas Apr 29 '14 at 16:24
  • I didn't to be honest - Our organisation was planning on changing the type of the token we were using anyway, so I waited for that. Fortunately, the new token is a lot shorter than the previous type, so I'm no longer experiencing the problem. A strange one though, I didn't really get anywhere with it - sorry! – dark_perfect Apr 29 '14 at 16:46

1 Answers1

1

If you are passing the parameters on a GET, you will be limited to 2100 characters. The RFC spec will be different between implementations. Most of the browsers limit you to 2083 characters. You can definitely get away with 1000 characters.

Microsoft

Pretty much everybody else

If you are passing the parameters on a POST, you should have virtually unlimited lengths.

Community
  • 1
  • 1
Adam Zuckerman
  • 1,633
  • 1
  • 14
  • 20
  • The HTTP request is made from a .NET application, so I'm not sure a browser comes into play here. If I enumerate through the Headers collection, I can see the full value of the token, but for some reason the Authorization property is null unless the token is smaller. – dark_perfect Apr 08 '14 at 08:11
  • A browser may not come into play, but the limit of the number of characters still applies. – Adam Zuckerman Apr 08 '14 at 15:48
  • It's in a header too, rather than parameters on a GET, so URL length limits don't apply, right? – dark_perfect Apr 08 '14 at 16:06
  • Headers also have a length limit. This appears to be something that can be configured by server. IIS will allow up to 32k bytes. Others have lower limits. It is going to depend on the server you are talking to. [How to set IIS' Maximum Header length](http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.maximumresponseheaderslength.aspx) – Adam Zuckerman Apr 08 '14 at 16:52
  • I'm experiencing the limit at around 2kb. And it doesn't explain why I can see the full header when calling request.Headers.ToString(), but not via request.Headers.Authorization, does it? Those statements are all from the application receiving the request, as opposed to sending it. I think this is different to any limits imposed via a browser or IIS... – dark_perfect Apr 08 '14 at 18:27
  • That would make sense since there are different specs for the browser and the server. – Adam Zuckerman Apr 08 '14 at 20:43
  • I'm not sure these comments are making sense. I can see the header value in the server code via one method, but not another. Surely this means that it's not being filtered out by the browser or web server, as it is accessible from the Web API application, and even in the very object (HttpHeadersCollection) I'd expect to see it in, but for some reason the actual Authorization property is null. – dark_perfect Apr 09 '14 at 09:16