IIS and HttpListener (.NET) with windows authentication - windows

I have a question about windows authentication with IIS and HttpListner
I have following setup (All installed in same windows 8.1 box. No outside communication). All requests are sent as http://localhost/......
IIS
ASP.Net web application authentication
Anonymous: Disabled
Windows Authentication: Enabled
.Net httpListener
running as a Service run as local System Account. and enabled windows authentication
this.httpListener = new HttpListener();
this.httpListener.AuthenticationSchemes = AuthenticationSchemes.IntegratedWindowsAuthentication;
UWP Application (Windows 8.1)
UWP Application is just like a web browser. It has WebView control to see web contents.
Following capabilities enabled
Enterprise Authentication
Internet (Client)
Location
Private Networks (Client & Server)
Problem
When I navigate from the uwp app to the IIS web app it is asking for the credentials by popping up windows dialog. This is annoying for the user experience perspective because user is logged in with same credencials. But When I access Http Listener it is authenticate correctly and no credentials dialog.
Also I checked the requests through fiddler. Initial request is identical, but with next steps for IIS request, it is continuously asking for NTLM.
HTTP/1.1 401 Unauthorized
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate oYHOMIHLoAMKAQGhDAYKKwYBBAGCNwICC........
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Initial Request/Response
IIS
Request
GET http://localhost/webapp_net/ HTTP/1.1
Accept-Encoding: gzip, deflate
Host: localhost
Connection: Keep-Alive
Response
HTTP/1.1 401 Unauthorized
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,POST
Date: Tue, 20 Nov 2018 21:37:24 GMT
Content-Length: 6016
Proxy-Support: Session-Based-Authentication
HttpListener
Request
GET http://localhost/appman HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-NZ
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; WebView/2.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: localhost
Response
HTTP/1.1 401 Unauthorized
Content-Length: 0
Server: Microsoft-HTTPAPI/2.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
Date: Tue, 20 Nov 2018 21:37:18 GMT
Proxy-Support: Session-Based-Authentication
Does anyone have similar experience or explanation for this ?

Related

Redirects stopped working in Firefox

I'm stumped, my website was working fine and now on Firefox suddenly the redirects stopped working.
I've tested IE and Chrome and going to /login redirects me to /dashboard however on Firefox the page is blank (no output sent) and no errors are logged. So this is why I'm assuming it to be a browser related issue. It might be due to a firefox update, but not sure how to confirm that.
Here are the headers:
Request Headers
GET /login HTTP/1.1
Host: local.example.com
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 FirePHP/0.7.4
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Cookie: __utma=34805930.947644602.1372214584.1380730296.1380733154.30; __utmz=34805930.1378700053.15.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); __utma=214248714.242656582.1377296111.1380047082.1380734348.30; __utmz=214248714.1377296111.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __qca=P0-705514134-1378344178153; __utmc=34805930; __utmb=34805930.15.10.1380733154; __utmb=214248714.5.10.1380734348; __utmc=214248714; PHPSESSID=lli8i30qkhvohfm9ufkbdvbki0
x-insight: activate
Connection: keep-alive
Response Headers
HTTP/1.1 302 Found
Date: Wed, 02 Oct 2013 17:30:58 GMT
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
X-Powered-By: PHP/5.4.7
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: /dashboard
Content-Length: 0
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
It all looks pretty standard to me, however FF stays stuck on /login Am I missing something?
This behaviour is both on my local windows host and my remote amazon Linux web-server. The body is empty...
How could I go about debugging this?
The Expires header field in the response is really off. Firefox probably does not bother to render stale responses.
Please check the system time in your server. It is possible it is an Amazon problem, but it is also possible that one of the server users set the system time.
You can look into setting up a Network Time Protocol (NTP) client to run regularly (with ntpd), if you don't have that yet.
I would fire up Fiddler to see what bits actually went over the wire. Among other information, Fiddler will show what content type is actually used during the HTTP request / response.
This could be related to the fact that there is no extension. Firefox could be having trouble determining if this is a document or folder. Try firebug and see what URL Firefox tries to request after the redirect.

IE8 can't download pdf file

I have MVC application that return PDF file.
public FileStreamResult GetDocument(int id)
{
return File(stream, "application/octet-stream", documentsModel.Name);
}
I have two test server. One is private and another is public.
From private I can download document and I get:
GET /Documents/GetDocument/3576 HTTP/1.1
Accept: */*
Accept-Language: en-GB
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; BRI/2)
Accept-Encoding: gzip, deflate
Host: appserver
Connection: Keep-Alive
Cookie: ASP.NET_SessionId=vgzn4qkelxdmic3nbaqftsxd; .FidesAuthCookie=BF08E0DCAAA54D7D78AB6BD30D5ECA523C045F9B401B10693B6CE57D7D4C677C0908E24D92511DC75A487D6CAE6DD780AA8B4419A5A5D9258A4985AF6870D3AD1A0B3C01B8A620A1E14FEDDE298CCE255AE4B4C2F76D2635B8C5DF332AF19AAB; dynatree-active=3576; dynatree-focus=; dynatree-expand=496%2C603%2Cfolder_622; dynatree-select=
HTTP/1.1 200 OK
**Cache-Control: private, s-maxage=0**
Content-Type: application/octet-stream
Server: Microsoft-IIS/7.5
Set-Cookie: .FidesAuthCookie=BF08E0DCAAA54D7D78AB6BD30D5ECA523C045F9B401B10693B6CE57D7D4C677C0908E24D92511DC75A487D6CAE6DD780AA8B4419A5A5D9258A4985AF6870D3AD1A0B3C01B8A620A1E14FEDDE298CCE255AE4B4C2F76D2635B8C5DF332AF19AAB; expires=Fri, 13-Apr-2012 13:31:05 GMT; path=/
X-AspNetMvc-Version: 3.0
Content-Disposition: attachment; filename=test.pdf
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 13 Apr 2012 13:01:04 GMT
Content-Length: 49613
From my public server I get
GET /Documents/GetDocument/97 HTTP/1.1
Accept: */*
Accept-Language: en-GB
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; BRI/2)
Accept-Encoding: gzip, deflate
Host: beta.qi-care.nl
Connection: Keep-Alive
Cookie: ASP.NET_SessionId=h3utp0bfu4zwhqysntame3we; dynatree-active=97; dynatree-focus=; dynatree-expand=4%2Cfolder_10; dynatree-select=; .FidesAuthCookie=F0DED3D98BF4115C910B0A29EC2C809902B49F15518952DFA78DDB4358B5F0C1A9EDAFB50DD0CA761B433ED68034C2539ABCCDA0C50FF5EEEE3573D3C77E550416CDB24B302C9EB831AC597040E6D255E9B582E8A29D5FC03454F2A0742ECC9DEC61070091F9A66D1C3FC7F9CA10C1B8BB9B5109CB613C98AEE32AFE5A0F8A28
HTTP/1.1 200 OK
**Cache-Control: private, no-cache="Set-Cookie", s-maxage=0**
Content-Type: application/octet-stream
Server: Microsoft-IIS/7.5
Set-Cookie: .FidesAuthCookie=F0DED3D98BF4115C910B0A29EC2C809902B49F15518952DFA78DDB4358B5F0C1A9EDAFB50DD0CA761B433ED68034C2539ABCCDA0C50FF5EEEE3573D3C77E550416CDB24B302C9EB831AC597040E6D255E9B582E8A29D5FC03454F2A0742ECC9DEC61070091F9A66D1C3FC7F9CA10C1B8BB9B5109CB613C98AEE32AFE5A0F8A28; expires=Fri, 13-Apr-2012 13:19:35 GMT; path=/
X-AspNetMvc-Version: 3.0
Content-Disposition: attachment; filename=test.pdf
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 13 Apr 2012 12:49:35 GMT
Content-Length: 49613
and I get error
http://support.microsoft.com/kb/323308
For some reason, I have from these two server, two different responses. But I found on Microsoft support that client should change registry
To resolve this issue in Internet Explorer 7 and in Internet Explorer 8, follow these steps:
Start Registry Editor.
For a per-user setting, locate the following registry key:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
For a per-computer setting, locate the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
On the Edit menu, click Add Value.
To override the directive for HTTPS connections, add the following registry value:
"BypassSSLNoCacheCheck"=Dword:00000001
To override the directive for HTTP connections, add the following registry value:
"BypassHTTPNoCacheCheck"=Dword:00000001
Quit Registry Editor.
Microsoft
We faced this problem at work, it turned out to be a bug in Internet Explorer (in our case IE8-), that gives an error when trying to download a file in SSL (Are you in https, right?). The problem is that if the server sends to the browser an http header that disables caching, Explorer gives an error. In your case, maxage=0 is equivalent to Cache-Control: no cache.
The solution server side is that you should overwrite this header to tell IE8 to cache the response, with Cache-Control: private for example.
Be careful that some application servers (such as in our case Websphere Application Server) append automatically no-cache="Set-Cookie" when a cookie is set.
Finally, there is another solution, if applicable, that solves the problem, but it should be applied client-side on the browser:
look at Method 1:
http://support.microsoft.com/kb/2549423

Firefox leaking cookies across Websocket hostdomains

Within Firefox 9 & 10 using Firebug and Live Headers,
I am seeing the websocket request/response pairs being sent across domains but with the wrong Cookie: contents.
Give two urls -
Base web page - http://www.mysite.test/mywebapp
Websocket url - http://stompeserver.mysite.test/stomp
The browser seems to be sending the cookies for the base page hostname rather any cookies associated with the secondary hostname. i.e. the JSESSIONID cookie loaded with the base web page is being echoed to the external connection.
Is this a bug or expected behavior? Nowhere have I seen how to websockets are suppose react to cookies.
IMO, this can be a really serious security violation by exposing a site's cookies to an external websocket service.
Updated to firefox 10 and still see an issue.
Below is a slightly clarified Live Headers trace of two back to back connections
The JSESSIONID and CLIENT_LOCALE cookies are copied to from 9443 the app server to 61623 the mq server.
----------------------------------------------------------
https://myapp.com:9443/server/themes/standard/public/gwt/xxstandard/images/logout-icon.png
GET https://myapp.com:9443/server/themes/standard/public/gwt/xxstandard/images/logout-icon.png HTTP/1.1
Host: myapp.com:9443
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: https://myapp.com:9443/server/example.htm?gwt.codesvr=127.0.0.1:9997&log_level=INFO
Cookie: JSESSIONID=0000wCOpgfIsSNOz2lL22O5LOiI:-1; CLIENT_LOCALE=en_US;
Pragma: no-cache
Cache-Control: no-cache
HTTP/1.1 200 OK
Date: Thu, 16 Feb 2012 19:02:55 GMT
Content-Type: text/plain
Last-Modified: Wed, 29 Jun 2011 20:44:11 GMT
Content-Length: 669
Content-Language: en-US
Server: WebSphere Application Server/7.0
----------------------------------------------------------
http://myapp.com:61623/stomp
GET http://myapp.com:61623/stomp HTTP/1.1
Host: myapp.com:61623
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Proxy-Connection: keep-alive
Sec-WebSocket-Version: 8
Sec-WebSocket-Origin: https://myapp.com:9443
Sec-WebSocket-Key: FToA/HGiVQN3CbGOgNffMA==
Cookie: JSESSIONID=0000wCOpgfIsSNOz2lL22O5LOiI:-1; CLIENT_LOCALE=en_US;
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Connection: Upgrade
HTTP/1.1 101 Switching Protocols
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Accept: 5lqrLU4mbPiEasSn4gqOlqWvGgw=
----------------------------------------------------------
Same-origin policy and CORS doesn't apply to WebSockets.
With WS, a "origin" HTTP header is sent in the initial WS opening handshake, and for browsers, this origin header MUST contain hostname of the server that originally served the HTML/JS that opens the WS.
The WS server is then free to accept/deny.
With non-browser WS clients, the origin header may or may not be present, and may contain anything.
Cookies: it's not specified by the WS spec. See Patrick's response (Firefox WS developer) here
http://www.ietf.org/mail-archive/web/hybi/current/msg08017.html

Can not log out from Tomcat using Firefox

I've encountered quite unexpected problem using Tomcat and CAS authorization. I just cannot logout in Firefox. I'm redirected to the logout page, but as soon as I reenter application url in the address bar, it is opened as if I'm logged (and I'm logged actually!).
First I've take a notable amount of attempts to fix something in tomcat config, then I've read logs, but nothing helped me actually before it comes up to my mind to check logout behavior in other browsers.
In other browsers everything work just as expected.
And I'm just stuck and would appreciate if one will give me a hint.
I guess [this question][1] is in some way relative with mine, but, helas, disabling caching on the page which should me logouted doesn't help either.
UPD: Some debug information. Firefox's version is 7.0.1, unfortunately, it is not a public application and I can not provide any url. It looks like response.sendRedirect output is something that Firefox is missing. Here is minimal code that works in any browser except Firefox.
session.invalidate();
response.sendRedirect("https://app:8552/cas/logout");
HEADERS
1st REQUEST - which invalidates session and redirect to CAS logout page
REQUEST HEADERS
Host: dev.service.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://dev.service.net/
Cookie: JSESSIONID=53B9469EFE9F130E9694F7406BFAB755
RESPONSE HEADERS
Server: nginx/1.0.4
Date: Thu, 20 Oct 2011 09:20:45 GMT
Content-Type: text/html
Content-Length: 184
Location: https://dev:8552/cas/logout
2nd REQUEST - cas logout page itself
REQUEST HEADERS
Host: dev:8552
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://dev.service.net/
Cookie: JSESSIONID=8A68F008825A0F0D14C6BF803E1332CF; GUEST_LANGUAGE_ID=en_US; COOKIE_SUPPORT=true
RESPONSE HEADERS
Server: Apache-Coyote/1.1
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache, no-store
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Content-Length: 1226
Date: Thu, 20 Oct 2011 15:53:57 GMT
3rd REQUEST - we are retuninig to the page which actually should
redirect us to login page, but it does not.
REQUEST HEADERS
Host: dev.service.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Cookie: JSESSIONID=53B9469EFE9F130E9694F7406BFAB755
RESPONSE HEADERS
Server: Apache-Coyote/1.1
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache, no-store
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Content-Length: 1226
Date: Thu, 20 Oct 2011 13:30:51 GMT
According to the headers, you're maintaining two different sessions on two different hosts. When you request a logout on the first host, you're redirected to the second host (which uses a different session cookie). The session cookie of the second host is in turn indeed invalidated (according to the presence of the Set-Cookie header). But based on the last request, the session has not been recreated on the server side (there is no Set-Cookie header). This means that session.invalidate() before response.sendRedirect() has failed somehow, or that the page is actually requested from the browser cache.
In Firebug you should be able to see if the page is requested from the browser cache by checking the text color of the request in the Net tab. If it's grayed out, then it means that it's been served from the browser cache. For Firefox, the must-revalidate header is actually mandatory next to the no-cache, no-store headers. You need to configure your server to add that entry to the header, or to change/create a Filter for that.
See also:
How to control web page caching, across all browsers?

"405 Method Not Allowed" only in Firefox 6 but not in IE 9 when calling WCF service

I have a WCF service hosted on http://localhost:8080, and a web application on http://localhost:82. I have Windows 7 64-bit and IIS 7.5.
The pages in the web app makes AJAX requests to the WCF service using jQuery.
In IE, the service calls perform fine. In Firefox, I get a 405 Method Not Allowed error. The service calls that the web application makes from the ASP.NET code-behind always succeed.
Other developer's builds are having the same problem. I initially thought it had to do with cross-site security restrictions that were introduced in FF 3.5, based on this article: https://developer.mozilla.org/En/HTTP_access_control. However, after adding all the response headers I appeared to need, the problem still occurred.
I've run the aspnet_regiis.exe command, and the WCF ServiceModelReg.exe command as well.
Here is the request that Firefox makes:
OPTIONS http://localhost:8080/ScoutService.svc/Contact_Add HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: http://localhost:82
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
Pragma: no-cache
Cache-Control: no-cache
Here is the response from the server:
HTTP/1.1 405 Method Not Allowed
Cache-Control: private
Allow: POST
Content-Length: 1565
Content-Type: text/html; charset=UTF-8
Server: Microsoft-IIS/7.5
Set-Cookie: ASP.NET_SessionId=53pqdbqgtj2cfdvtqrikiewu; path=/; HttpOnly
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Access-Control-Allow-Origin: http://localhost:82
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Max-Age: 17280
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Credentials: true
Date: Thu, 15 Sep 2011 15:55:27 GMT
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Service</title>
</head>
<body>
<div id="content">
<p class="heading1">Service</p>
<p>Method not allowed.</p>
</div>
</body>
</html>
Any ideas?
Firefox sends an OPTIONS request in addition to a POST or GET.
See http://forums.iis.net/t/1160649.aspx for how to fix it.
Edit
The other thing that is special in your case is that you are using IIS 7.5 which does not allow all verbs by default.
You need to allow the OPTIONS verb
IIS 7.5, Web Service and HTTP 405 error

Resources