I've got a localhost website and an IIS(7.5) hosted WCF service implemented like this with a Visual Studio debugger attached. Whenever I make a CORS request to my service I'm getting the following 404 response, along with the standard ASP.Net error page:
OPTIONS http://192.168.200.44/api/values HTTP/1.1
Host: 192.168.200.44
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Origin: http://localhost:51946
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Response >>
HTTP/1.1 404 Not Found
Content-Type: text/html
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Thu, 26 Sep 2013 09:38:49 GMT
Content-Length: 1245
Originally I was receiving erroneous 200 messages which didn't touch my WCF applictions numerous breakpoints, so it was being handled by IIS itself. I then followed this and this SO posts and removed the OPTIONSVerbHandler from the site and add "OPTIONS, PUT, POST & DELETE" as allowed HTTP verbs in the IIS manager UI (rather then web.conf), which progressed me to my 404 message. I've looked into WebDav which is highlighted as a problem but I haven't disabled/removed it because I don't know how but have read that it only affects "PUT & DELETE" operations where as my "POST" ops are also failing.
GET requests work as expected so the service definitely exists/works in IIS, just the Options preflight isn't reaching my service.
TY
Although the OP managed to find a solution that worked in their specific case, the same issue has been driving me round the bend for the past few hours.
In my case I knew it wasn't a code / web.config issue as the same code ran perfectly fine on my local IIS, but not on the production version.
After reading numerous posts and trying everything they suggested (including the OP's answer) I actually got round to looking at the IIS logs (should have done that first!) and found this:
2015-03-09 14:43:39 <IP Addr> GET /Rejected-By-UrlScan ~/Service.svc/H2dbImportTxtFile <Port> - <IP Addr>
This led me too:
http://www.pressthered.com/rejected-by-urlscan_404_errors/
And ultimately [AllowVerbs] the section of:
\system32\inetsrv\urlscan\UrlScan.ini
I just needed to add OPTIONS.
And now the OPTIONS request gets through, and everything works.
Hope that helps some-one else who is being driven mad.
EDIT:
As stated in another SO post (I'm afraid I've lost it now), as mine was a WCF service I also had to change the interface of the listening service from:
[WebInvoke(Method = "POST", etc]
to
[WebInvoke(Method = "*", etc]
In Handler Mappings on the IIS GUI, I had to restore defaults to get back the OPTIONSVerbHandler I'd previously deleted, once done I edited it to be an IsapiModule rather than a ProtocolSupportModule, you also need to set an executable "%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll". This allowed me to make POST requests in addition to GET requests.
PUT and DELETE were still reporting 404 until I re-enabled the OPTIONSVerbHandler, then they began reporting 200 (OK), though I couldn't see them touching my web services when I attached a debugger.
There are then 3 modules called "ExtensionlessUrlHandler-*", two for 32/64bit and one for Integrated, I only changed the 32/64bit variants (running on a classic app pool) which worked for me, but for anyone using an integrated app pool some experimentation may be needed here.
Anyway I edited the 32/64bit variants, under the "Request Restrictions" button on the Verbs tab I added "PUT,DELETE" so it read "GET,HEAD,POST,DEBUG,PUT,DELETE" and everything in my CORS ready service is working
I had <remove name="OPTIONSVerbHandler"> in my handlers section of web.config. I commented it out to fix the problem!
<system.webServer>
<handlers>
<!--<remove name="OPTIONSVerbHandler" />-->
</handlers>
</system.webServer>
Related
When I send a http request to my couchdb server like it is shown in the docs here CouchDB Proxy Authentication, it doesn't give the response shown in the docs, just empty data. What am I doing wrong?
Also, am I able to start a session with this Proxy Auth? If I try a POST /_session, I get 500 error code.
GET /_session HTTP/1.1
Host: 127.0.0.2:5984
User-Agent: curl/7.51.0
Accept: application/json
Content-Type: application/json; charset=utf-8
X-Auth-CouchDB-UserName: john
X-Auth-CouchDB-Roles: blogger
< HTTP/1.1 200 OK
< Cache-Control: must-revalidate
< Content-Length: 132
< Content-Type: application/json
< Date: Sun, 06 Nov 2016 01:10:58 GMT
< Server: CouchDB/2.0.0 (Erlang OTP/17)
<
{"ok":true,"userCtx":{"name":null,"roles":[]},"info":{"authentication_db":"_users","authentication_handlers":["cookie","default"]}}
I found in the CouchDB issue tracker that the Proxy Authentication is broken in version 2.0.0. Either that or the docs aren't updated to indicate that it only works with clusters or something. I changed back to version 1.6.1 and everything works fine. I must say that the documentation for how Proxy Authentication works is very poor.
How it works is you need your third party authentication server to have the "[couch_httpd_auth] secret" and when a client authenticates, you need to generate a HMAC-SHA1 token by combining the username and secret. Then, on any http requests you make from the client to the CouchDB server, if you include all the headers:
X-Auth-CouchDB-Roles
X-Auth-CouchDB-UserName
X-Auth-CouchDB-Token
that request will be authenticated as a user client.
Also, it is not mentioned in the docs, but POST on the /_session API using these headers does nothing.
It's not the Proxy Authentication itself which is broken in CouchDB 2.0, it's just that in the current release there's no way to configure the authentication handlers like there was in the old 1.6 days.
There are some patches mentioned in the issue tracker which add proxy authentication to the list of authentication handlers. Furthermore there was a pull request which was accepted and merged which brings back configurability to CouchDB 2.0.
However in order to take advantage of those I'm afraid you either have to wait until the next release, or build CouchDB 2.0 yourself from the sources.
Proxy authentication is fixed as of CouchDB 2.1.1. The latest (>2.1.1) documentation shows how to configure proxy authentication again, along with the important proxy_use_secret option.
My iOS app makes Rest calls to my WCF web service.
The responding speed is very slow, over 3 min.
However, when I set up Fiddler as a Proxy to monitor the iOS traffic. The call was finished in 1 sec.
What does make Fiddler magically accelerate the Rest call from iOS?
p.s. Fiddler is setup on a windows PC where uses the same network with iOS App.
The rest call example (from Fiddler)
Request
GET https://xxxx.xxxx.com/Deals HTTP/1.1
Host: xxx.xxxx.com
Proxy-Connection: keep-alive
Accept-Encoding: gzip
Content-Type: application/json
Cookie: ASPXAUTH=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Connection: keep-alive
User-Agent: Natural xxxx x.x.x (iPad; iPhone OS 7.0.2; en_US)
Response
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 891437
Content-Type: application/json; charset=utf-8
Server: Microsoft-IIS/7.5
LastFetchDateTimeUTC: 2014-02-14T16:52:43.5465273Z
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 14 Feb 2014 16:52:45 GMT
Response body is a large json (2MB)
p.s.
Except for Fiddler, we also tried to install wireshark and use it to capture traffic on the mac while running the app from on the simulator.
We see a lot DUP ACK, I guess that's causing tcp re-transmission
p.s.
We pinged from iOS too, there is no delay to the WCF web service.
Help!
UPDATE:
We found out a problem, looks like the respond time decreases with the length of the body. Does it mean anything?
The WireShark logs should provide you plenty of information about what happens in each case. When Fiddler "magically" makes things faster, it's typically due to:
Better connection reuse (e.g. Fiddler may reuse connections better than client)
Better buffer sizes (e.g. not using tiny buffers for read/write)
Non-broken proxy determination behavior
I wrote a bit about these in this blog post.
We solved this problem by proving that server is a shitty one. We deployed the same service on another VM and it works. Must be the a broken network card
I'm totally new to WIF and to start playing with it a bit I tried the simplest "f5 experience" with an MVC4 application; according to the tutorials I found, which sadly for the most part refer to releases before .net 4.5, I should just create an MVC app, configure it with the identity and access tool and hit f5 to get up and running with local STS. Yet, I'm probably missing something obvious because when I try to access a restricted page I always end bumped back to the homepage.
Here is what I did, you can easily repro the issue with these steps (VS2012 in Win8 with WIF SDK; ensure to launch VS with admin rights):
create a new ASP.NET MVC4 Internet application. Set its port to 7777 (just picking the port number used in most code samples for the sake of commodity).
update all the NuGet packages (this is optional).
right click the solution, choose identity and access and set the IP=local STS, then click OK. Then reopen the identity and access popup, and choose generate a controller, then click OK.
add an [Authorize] attribute to the About action of the Home controller.
hit F5 and click the About link. As expected, the login view appears, prompting me to login: the only option is of course localSTS. When I click it, I am returned to the homepage and no authentication occurs. I can repeat the process, but nothing changes, so I can never access the secured About page.
The link underlying the localSTS anchor is:
http://localhost:14743/wsFederationSTS/Issue?wa=wsignin1.0&wtrealm=http%3a%2f%2flocalhost%3a7777%2f&wctx=rm%3d0%26id%3d664ff3c2-95b1-40b3-b538-a8357233ea7e%26ru%3dhttp%253a%252f%252flocalhost%253a7777%252f&wct=2013-03-10T13%3a39%3a32Z
AFAIK, its parameters look OK.
If I examine the network traffic, I cannot see any relevant item (if I understand well, I would expect a response setting some cookies for the current session, representing the IClaimsPrincipal).
(BTW, by looking at the web.config, I can see that in modules WSFederationAuthenticationModule is referenced from System.Identity.Services, which is NOT included in the solution after configuring Identity and access; I suppose this is a bug in the tool. Anyway I added a reference to it, but nothing changed.)
Update
Thank you for the reply! If I examine the traffic, here are the relevant GET/POSTs. I get no cookie. I tried recreating the whole test solution, even skipping step #2 above to keep it minimal, but nothing changed.
As for your suggestion #2, I tried to add in global asax:
FederatedAuthentication.WSFederationAuthenticationModule.SecurityTokenValidated
+= (sender, e) => FederatedAuthentication.SessionAuthenticationModule.IsReferenceMode = true;
but the SessionAuthenticationModule is null at the time this code executes and thus a corresponding exception is thrown. I cannot find up-to-date code samples or articles about this, yet WIF seems a very promising tech; I'd like it to be easy for security newbies like me; my main purpose is applying it to a site providing both MVC controllers and WebApi controllers, to a wide range of consumers (JS code, mobile apps, WinRT apps, the site pages themselves...). Any suggestion?
(1) a GET which gets 307, temporary redirect
GET /wsFederationSTS/Issue?wa=wsignin1.0&wtrealm=http%3a%2f%2flocalhost%3a7777%2f&wctx=rm%3d0%26id%3d664ff3c2-95b1-40b3-b538-a8357233ea7e%26ru%3dhttp%253a%252f%252flocalhost%253a7777%252f&wct=2013-03-10T13%3a39%3a32Z HTTP/1.1
Host: localhost:14743
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.2; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.160 Safari/537.22
Referer: http://localhost:7777/HrdAuthentication/Login?ReturnUrl=%2fHome%2fAbout
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
Cookie:
(2) GET with signin request:
GET /wsFederationSTS/Issue/?wa=wsignin1.0&wtrealm=http%3a%2f%2flocalhost%3a7777%2f&wctx=rm%3d0%26id%3d664ff3c2-95b1-40b3-b538-a8357233ea7e%26ru%3dhttp%253a%252f%252flocalhost%253a7777%252f&wct=2013-03-10T13%3a39%3a32Z HTTP/1.1
Host: localhost:14743
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.2; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.160 Safari/537.22
Referer: http://localhost:7777/HrdAuthentication/Login?ReturnUrl=%2fHome%2fAbout
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
Cookie:
(3) a POST to the homepage: the respone is of course the homepage content; no cookies set.
POST / HTTP/1.1
Host: localhost:7777
Connection: keep-alive
Content-Length: 7063
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Origin: http://localhost:14743
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.160 Safari/537.22
Content-Type: application/x-www-form-urlencoded
Referer: http://localhost:14743/wsFederationSTS/Issue/?wa=wsignin1.0&wtrealm=http%3a%2f%2flocalhost%3a7777%2f&wctx=rm%3d0%26id%3d664ff3c2-95b1-40b3-b538-a8357233ea7e%26ru%3dhttp%253a%252f%252flocalhost%253a7777%252f&wct=2013-03-10T13%3a39%3a32Z
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
Cookie:
A working variation
I found a way for letting it work, maybe this can be useful to someone else: if you follow the above procedure without changing from the local IIS server to the VS development server, it seems it's working and I'm still redirected to the Home page (I wonder why:), but as an authenticated user; at this point, I can click the About link again to effectively enter the page.
I reproduce your steps and everything worked. Chrome debugger show that you must have two steps:
GET http://localhost:12263/wsFederationSTS/Issue/?wa=wsignin1.0&wtrealm=http%3a%2f%2flocalhost%3a54306%2f&wctx=rm%3d0%26id%3dc6e46b99-417b-49b6-96a0-40efcead898f%26ru%3dhttp%253a%252f%252flocalhost%253a54306%252f&wct=2013-03-10T18%3a14%3a19Z
POST http://localhost:54306/ with wa:wsignin1.0 and wresult:trust:RequestSecurityTokenResponseCollection
Result of POST is Set-Cookie named FedAuth and FedAuth1. Cookie is split because of cookie size limit.
Please check this in debugger.
p.s. Once i saw a same behavior - cookie is not set normally. Problem was in cookie size and solved by switching to ReferenceMode. Don't forget to to register it in Application_Start:
FederatedAuthentication.WSFederationAuthenticationModule.SessionSecurityTokenCreated
+= this.WSFederationAuthenticationModule_SessionSecurityTokenCreated;
I'm currently trying to connect to a webservice placed on https://xxx.xxx.xx/myapp
It has anonymous access and SSL enabled for testing purposes atm.
While trying to connect from the 3G network, i get Status 403: Access denied. You do not have permission to view this directory or page using the credentials that you supplied.
I get these headers while trying to connect to the webservice locally:
Headers
Request URL:https://xxx.xxx.xx/myapp
Request Method:GET
Status Code:200 OK
Request Headers
GET /myapp/ HTTP/1.1
Host: xxx.xxx.xxx
Connection: keep-alive
Authorization: Basic amViZTAyOlE3ZSVNNHNB
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.56 Safari/535.11
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: sv-SE,sv;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response Headers
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Thu, 16 Feb 2012 12:26:13 GMT
Content-Length: 622
But when accessing outside the local area, we get the big ol 403. Which in turn wants credentials to grant the user access to the webservice.
However, i've tried using the ASIHTTPRequest library without success, and that project has been abandoned. And they suggest going back to NSURLConnection.
And i have no clue where to start, not even which direction to take.
-connection:(connection *)connection didRecieveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge
The above delegate method of NSURLConnection doesnt even trigger. So i have no idea what so ever how to authenticate myself.
All i get is the parsed results of the xml elements of the 403-page.
I needs dem seriouz helps! plx.
This was all just a major f-up.
The site had ssl required and enabled, and setting ssl required for the virtual directories does some kind of superduper meta-blocking.
So, by disabling ssl required for the virtual directories, it runs over ssl and is not blocking 3G access..
Greetings,
I create a new project (in VS2010) using;
File -> New Web Site -> .NET Framework 3.5 -> WCF Service
Service works great via Cassini, can view the WSDL metadata with success. Then I attempt to setup the application to be served via IIS. Using a .NET 2.0 application pool with "Integrated" pipeline.
I made sure the svc handler is setup on the application (both managed and script) and ran this command as well:
"%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe" /r
Then when I attempt to view the service metadata via the IIS service I get this (text from a Fiddler session);
GET http://localhost/WCFService2/Service.svc HTTP/1.1
Host: localhost
Connection: keep-alive
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
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
HTTP/1.1 200 OK
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Wed, 12 Jan 2011 19:04:43 GMT
Content-Length: 0
I was getting a HTTP Error 500 but I changed the permissions on all the files in the folder to "EveryOne" and "full" - just to remove any security issues. Its after this action that the error 500 stopped but the empty content started.
I am using Windows 7 64 bit, VS2010 and have v2.0, v3.0, v3.5 and v.4.0.30319 frameworks installed. I hoped that it would work as simple as this screencast, silly me.
Any suggestions?
Try enabling static content support from "Windows features on or off", this is most likely what is causing the problem.
If the "Static Content" is not enabled the IIS will return a response with Content-Length = 0
Go to Control Panel >>
Programs And Features >>
Turn Windows features on or off >>
Internet Information Services >>
World Wide Web Services >>
Common HTTP Features >>check Static Content.