Go-reverseproxy interferes with .net [Authorize] attribute - asp.net

I am running an ASP.NET MVC web application with Vue.js as frontend. For access control management, I am using pritunl-zero, a zero-trust reverse-proxy written in Go.
Locally the app works fine with anonymous authentication but deployed and protected from the proxy every method call that need auth will be denied with 401.0 from the IIS10 web server.
When I remove the proxy from the infrastructure it works.
Protected method call (eg)
[Authorize]
[HttpPut, Route("api/ping"), ResponseType(typeof(WorkflowDto))]
public IHttpActionResult PingWorkflow(WorkflowCommentDto commentDto)
Vue frontend log in console
createError.js:16
Uncaught (in promise) Error: Request failed with status code 401
at e.exports (createError.js:16:15)
at e.exports (settle.js:17:12)
at XMLHttpRequest.O (xhr.js:66:7)
The HTTP-header causing 401 response
GET /api/workflow/ping HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: de,de-DE;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6,cy;q=0.5
Cache-Control: no-cache
Connection: keep-alive
Cookie: pritunl-zero=MTY1NzY5OTc0NHxEdEU...
Host: workflow.host.de
Pragma: no-cache
Referer: https://workflow.host.de/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36 Edg/103.0.1264.49
sec-ch-ua: ".Not/A)Brand";v="99", "Microsoft Edge";v="103", "Chromium";v="103"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
token: 8cf78dcd-3b17-4481-8be3-10821519c23c
The working HTTP-header
:authority: wf.host.de
:method: GET
:path: /api/workflow/Ping
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: de,de-DE;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6,cy;q=0.5
cache-control: no-cache
cookie: pritunl-zero=MTY1Nzc3NjkwOHxZTVRUWUF5d0s0c180aTB...; pritunl-zero=MTY1NzgwMTE3MnxlWk9vYkZ2ZGQ0TTdVZmZKODdWb19SRzFSV...
pragma: no-cache
referer: https://wf.host.de/
sec-ch-ua: ".Not/A)Brand";v="99", "Microsoft Edge";v="103", "Chromium";v="103"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-origin
token: 8cf78dcd-3b17-4481-8be3-10821519c23c
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36 Edg/103.0.1264.49
The response from server (that one works)
cache-control: no-cache
content-length: 214
content-type: application/json; charset=utf-8
date: Thu, 14 Jul 2022 12:25:09 GMT
expires: -1
pragma: no-cache
server: Microsoft-IIS/10.0
strict-transport-security: max-age=0; includeSubDomains; preload
x-aspnet-version: 4.0.30319
x-powered-by: ASP.NET
Response from server (401)
HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
Content-Length: 61
Content-Type: application/json; charset=utf-8
Date: Wed, 13 Jul 2022 08:09:12 GMT
Expires: -1
Pragma: no-cache
Server: Microsoft-IIS/10.0
X-Aspnet-Version: 4.0.30319
X-Powered-By: ASP.NET
Has anyone any hint how to fix this, that the application can work with the proxy?
What I tried:
New IIS with new site and new deployment
Many web.config settings regarding anonymous authentication
Different configs regarding the application pool
Latest update from pritunl
Thanks in advance for any hint.

Related

Why do I have 404 Not Found when Clicking home wordpress

The Situation
Every time I click the home button below I find thaty it takes me to 404 not found as below that:
Wordpress dashboard
Error
I am not sure why this is occuring, but it seems to be redirecting to away from the port:8080 but I have set the wp_options site_url and home_url to http://localhost:8080/wordpress within phpAdmin. How could I fix this?
======
EDIT:
The behavior when looking in the log in the console after clicking the home button is:
Request URL: http://localhost:8080/wordpress/
Request Method: GET
Status Code: 301 Moved Permanently (from disk cache)
Remote Address: [::1]:8080
Referrer Policy: strict-origin-when-cross-origin
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Date: Wed, 03 Feb 2021 17:40:28 GMT
Location: http://localhost/wordpress/
Server: Apache/2.4.46 (Win64) OpenSSL/1.1.1h PHP/7.4.13
X-Powered-By: PHP/7.4.13
X-Redirect-By: WordPress
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: en-ES,en-US;q=0.9,en;q=0.8
Connection: keep-alive
Cookie: wp-settings-1=mfold%3Do; wp-settings-time-1=1612439758; wordpress_test_cookie=WP%20Cookie%20check; wordpress_logged_in_7d02bf5d4e081af2908123233e7fb2e7=Kwsswart%7C1612681149%7C3lzaDUQayIVeJSHGTZiiOEF0IPOnAvdyMTTlSq6SP7Z%7C66c2a42cd2b27d342bd5a234fb1276e73122a06eb9761a76f336f26c5cea485e
Host: localhost
Referer: http://localhost:8080/
sec-ch-ua: "Chromium";v="88", "Google Chrome";v="88", ";Not A Brand";v="99"
sec-ch-ua-mobile: ?0
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-site
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
Followed by:
Request URL: http://localhost/wordpress/
Request Method: GET
Status Code: 404 Not Found
Remote Address: [::1]:80
Referrer Policy: strict-origin-when-cross-origin
Connection: Keep-Alive
Content-Length: 196
Content-Type: text/html; charset=iso-8859-1
Date: Fri, 05 Feb 2021 06:59:33 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.46 (Win64) PHP/7.4.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: en-ES,en-US;q=0.9,en;q=0.8
Connection: keep-alive
Cookie: wp-settings-1=mfold%3Do; wp-settings-time-1=1612439758; wordpress_test_cookie=WP%20Cookie%20check; wordpress_logged_in_7d02bf5d4e081af2908123233e7fb2e7=Kwsswart%7C1612681149%7C3lzaDUQayIVeJSHGTZiiOEF0IPOnAvdyMTTlSq6SP7Z%7C66c2a42cd2b27d342bd5a234fb1276e73122a06eb9761a76f336f26c5cea485e
Host: localhost
Referer: http://localhost:8080/
sec-ch-ua: "Chromium";v="88", "Google Chrome";v="88", ";Not A Brand";v="99"
sec-ch-ua-mobile: ?0
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-site
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like
wp_admin settings
You still have to call your frontend under port 8080
localhost:8080/wordpress
EDIT:
Have a look here: themeisle.com/blog/install-xampp-and-wordpress-locally

302 Redirect Originates from ASP.NET or IIS

Is it possible to work out whether a redirect occurred from something setup within IIS, or whether an ASP.NET application issued the redirect for IIS to perform?
I have an ASP.NET site which is redirecting a HTTPS page to HTTP page (which I don't want it do do), and which I have confirmed by the following headers:
https://***.co.uk/MainWebsite/Intro.aspx
GET /MainWebsite/Intro.aspx HTTP/1.1
Host: ***.co.uk
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
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, br
Cookie: _ga=GA1.3.1422039573.1457307455; ASP.NET_SessionId=bazsdsfsdfrre0vp30joy
Connection: keep-alive
Upgrade-Insecure-Requests: 1
HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=utf-8
Location: http://***.co.uk/MainWebsite/Intro.aspx
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Thu, 22 Sep 2016 08:04:13 GMT
Content-Length: 184
Do the "X-AspNet-Version" and "X-Powered-By" headers suggest that ASP.NET have told IIS to do a redirect, or is it impossible to tell from this information?
Thanks

IIS6 Compression only working over HTTPS

We have recently enabled compression in IIS6 for our ASP.NET applications (some 2.0 some 4.0) and have found that GZip is only being performed when the request is made over HTTPS.
This problem is being seen on all servers in our web farm. I have also checked that the same problem exists regardless of the browser used.
I've searched for over an hour and can't find anything on this, so hoping someone may be able to help. Examples follow
HTTP Request:
GET /about.htm HTTP/1.1
Host: www.website.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36
Referer: http://www.google.co.uk
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
HTTP Response (not GZipping):
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 65568
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Thu, 26 Sep 2013 09:26:46 GMT
HTTPS Request:
GET /about.htm HTTP/1.1
Host: www.website.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
HTTPS Response (GZip working):
HTTP/1.1 200 OK
Cache-Control: private
Date: Thu, 26 Sep 2013 09:29:39 GMT
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Encoding: gzip
Vary: Accept-Encoding
Transfer-Encoding: chunked
UPDATE
I've run a request trace in IIS - the offending requests have the following line
IISCompression DYNAMIC_COMPRESSION_NOT_SUCCESS "NO_MATCHING_SCHEME"

Http Request not reaching the IIS module

During development of an IIS module for basic authentication, I stocked to a problem. The module is working fine when browsing the pages, but when calling web-services it seems that request does not reach the module and some in-the-middle module takes control of request.
using fiddler, I found out when Content-type in http request header is set to application/json that in the middle module/handler is triggered. so following request does not work:
when working fine, the server should ask client to send the user credentials by setting the WWW-Authenticate header in response
GET /WebServices/service.asmx/someMethod?param=test HTTP/1.1
Host: localhost
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.152 Safari/537.22
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Content-Type: application/json
asdfasdf
asdfasdfasdf
response: notice the jsonerror header in response
HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
Server: Microsoft-IIS/7.5
jsonerror: true
X-Powered-By: ASP.NET
Date: Mon, 11 Mar 2013 23:49:02 GMT
Content-Length: 105
{"Message":"Authentication failed.","StackTrace":null,"ExceptionType":"System.In
validOperationException"}
where this one works fine: notice that there is no content-type
GET /WebServices/service.asmx/someMethod?param=test HTTP/1.1
Host: localhost
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.152 Safari/537.22
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
asdfasdf
asdfasdfasdf
and the correct response is: notice the WWW-Authenticate header in response
HTTP/1.1 401 Unauthorized
Location: http://localhost/WebServices/service.asmx/someMethod?param=test
Server: Microsoft-IIS/7.5
WWW-Authenticate: Basic
X-Powered-By: ASP.NET
Date: Mon, 11 Mar 2013 23:59:48 GMT
Content-Length: 0
Well, that in-the-middle module was ScriptModule where we had both 3.5 and 4.0 version being added in the config. inspecting them through dotpeek, I found that the script module checks request's content-type against being application/json and then tries to handle the request as a REST request or webservice call.
By removing them, nothing special happened. I assume that they are to be used when script manager or Microsoft Specific AJAX services are used. You can find more about it in
ASP.Net Ajax Programming Tricks

SignalR: Troubleshooting Suggestions for 404 Response at Connection() time

I am getting a 404 - Not Found Error at connection time in my QA environment. No issue with the same code in our dev integration environment.
I've looked at the other 404's reported here and was not able to find a good match.
Running fiddler, the outgoing request looks very similar in both environments.
Any suggestions on how to troubleshoot this further? Thanks.
* Test Server Connection OK *
var connection = $.connection('http://sdbntrwebdev01.sddev.lpl.com/AlertsService/request/' + token);
POST /AlertsService/request/7077342FE79A4EA99B939C24528EFB8E/negotiate HTTP/1.1
Host: sdbntrwebdev01.sddev.lpl.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
X-Requested-With: XMLHttpRequest
Referer: http://sdbntrwebdev01.sddev.lpl.com/alertsservice/healthcheck.aspx
Cookie: ASP.NET_SessionId=zadzj3je5ofm3e51350jl25b; Auth=7077342FE79A4EA99B939C24528EFB8E
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 0
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Tue, 27 Mar 2012 23:51:41 GMT
* QA Server Connection gets 404 *
var connection = $.connection('http://sdalertwebqa01.qadmz.lpl.com/AlertsService/request/' + token);
POST /AlertsService/request/B8E02A155BBF4C55AC4E715C7F1CA968/negotiate HTTP/1.1
Host: sdalertwebqa01.qadmz.lpl.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
X-Requested-With: XMLHttpRequest
Referer: http://sdalertwebqa01.qadmz.lpl.com/alertsservice/healthcheck.aspx
Cookie: ASP.NET_SessionId=4zx05otp5oztqjqxvdaafa5e; Auth=B8E02A155BBF4C55AC4E715C7F1CA968
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 0
HTTP/1.1 404 Not Found
Content-Type: text/html
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Tue, 27 Mar 2012 23:48:12 GMT
Content-Length: 1245
Another guy here found the answer and I will share.
In IIS7, there is a setting called "URLRoutingModule-4.0". The "Edit Managed Module" dialog also contains a checkbox as "Invoke only for requests to ASP.NET applications or managed handlers". Un-check that checkbox.
This setting is at the "Default Web Site" level, double-click "Modules" from feature view to get a list of modules, double-click line item "URLRoutingModule-4.0" to launch the "Edit Managed Module" dialog.

Resources