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.
Related
I'm seeing this HTTP header on some requests made to my server:
X-P2P-PeerDist: Version=1.0
I'm aware of this: http://www.faqs.org/patents/app/20110016220#ixzz3g3X8lSYF, but I would like to know what are the known clients sending that header.
Any idea?
UPDATE: as requested, i'm including the other headers sent with the request (I've obfuscated some private stuff that are related to our customer with ***):
GET http://***.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Connection: Keep-Alive
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Win64; x64; Trident/7.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; InfoPath.3; .NET4.0C; .NET4.0E)
X-P2P-PeerDist: Version=1.0
UA-CPU: AMD64
Accept-Encoding: gzip, deflate, peerdist
Host: ***.com
Cookie: SMSESSION=***; OrgName=***; authCookie=***; ASP.NET_SessionId=***
Pragma: no-cache
Cache-Control: no-cache
The user agent seems to indicate IE11 (Trident/) in IE7 mode (compatible; MSIE 7.0), but I'm not getting the X-P2P-PeerDist header when I'm using this config, so I don't think it's directly related.
It is one of the headers used in the PeerDist peer content caching protocol. It has never been standardized and are not even registered with the IANA registry for HTTP headers.
It is known to be sent from some recent versions of Internet Explorer, .NET HTTP clients and SilverLight HTTP clients.
I’m relatively certain that this header is send when if the client is configured to use BranchCache and a request is made using WinHTTP. About BranchCache:
To optimize WAN bandwidth, BranchCache copies content from your main office content servers and caches the content at branch office locations, allowing client computers at branch offices to access the content locally rather than over the WAN. (Source).
When testing here locally, a client that has BranchCache enabled sends the X-P2P-PeerDist header, while a brand new client (no BranchCache configured) does not sent it.
The underlying protocol seems for is Peer Content Caching and Retrieval (MS-PCCRTP), as the section Message Syntax from the protocol description defines X-P2P-PeerDist as one of the HTTP header extension it uses.
However, the document BranchCache Deployment Guide for Windows Server 2008 R2 and Windows 7 lists other MS-PCCx protocols but not MS-PCCRTP. So I don't have an external evidence that this header is caused by a BranchCache enabled client.
I have seen this in IE11 + compatibility mode on Windows 7, connected to an intranet application and downloading a docx file. The request only appears when downloading a document. All requests are going through an F5 load balancer. In other non-download requests on the same browser and same application, the X-p2p-peerdist header is missing.
On Production I am receiving the error below.
POST http://publicIP:9080/AppName/apps/services/api/proj/common/query
403 (Forbidden ( The server denied the specified Uniform Resource
Locator (URL). Contact the server administrator. ))worklight.js:1099
window.WLJSX.Ajax.Request.WLJSX.Class.create.requestworklight.js:1062
window.WLJSX.Ajax.Request.WLJSX.Class.create.initializeworklight.js:526
klassworklight.js:3410
window.WLJSX.Ajax.WLRequest.WLJSX.Class.create.sendRequestworklight.js:3278
window.WLJSX.Ajax.WLRequest.WLJSX.Class.create.initializeworklight.js:526
klassworklight.js:8580 __invokeProcedureworklight.js:8623 (anonymous
function) worklight.js:5061
[/AppName/apps/services/api/AppName/common/query] failure. state: 403,
response: The server was unable to process the request from the
application. Please try again later.worklight.js:5061
WL.Logger.__logworklight.js:5445 PUBLIC_API.(anonymous
function)worklight.js:3559
window.WLJSX.Ajax.WLRequest.WLJSX.Class.create.onFailureworklight.js:3522
window.WLJSX.Ajax.WLRequest.WLJSX.Class.create.onWlFailureworklight.js:958
(anonymous function)worklight.js:1181
window.WLJSX.Ajax.Request.WLJSX.Class.create.respondToReadyStateworklight.js:1114
window.WLJSX.Ajax.Request.WLJSX.Class.create.onStateChangeworklight.js:958
(anonymous function)
I am using
IBM MobileFirst 6.3 Consumer Edition
Liberty profile 8.5.3
Scenarios Run
This App is running on Localhost and within internal Network perfectly well.
But at Public IP, I am unable to access the httpadapter from Application.
//********ERROR Browser LoG On Calling App
Blockquote
Denied Connection
INTERNALTMG 2/26/2015 1:43:12 PM
Log type: Web Proxy (Reverse)
Status: 12202 Forefront TMG denied the specified Uniform Resource Locator (URL).
Rule: mobileapps
Source: Internal (10.39.30.64:52151)
Destination: Local Host (worklightsvr.local.machine 132.20.68.46:9080)
Request: POST http://132.20.68.46:9080/AppName/apps/services/api/example/common/query
Filter information: Req ID: 0a68784f; Compression: client=Yes, server=No, compress rate=0% decompress rate=0%
Protocol: http
User: anonymous
Description: C:\Program Files\Microsoft Forefront Threat Management Gateway\UI_HTMLs_image\general\minusImg.gifAdditional information
1. Client agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36
2. Object source: Internet (Source is the Internet. Object was added to the cache.)
3. Cache info: 0x51c0000 (Response includes the CACHE-CONTROL: NO-CACHE or PRAGMA: NO-CACHE header. Response includes the CACHE-CONTROL: NO-STORE header. Response includes either the CACHE-CONTROL: MUST-REVALIDATE or CACHE-CONTROL: PROXY-REVALIDATE header. Response includes the EXPIRES header. Response includes the WWW-AUTHENTICATE header.)
4. Processing time: 1 MIME type:
Blockquote
As the error says, verify with your IT department that you are not blocking the URL/domain somewhere in your corporate firewall.
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>
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..