I have an asp.net 4 application that hosts a WCF REST service via WebServiceHost...
WebServiceHostFactory factory = new WebServiceHostFactory();
routes.Add(new ServiceRoute("mss", factory, typeof(ModuleStorage)));
My application has a custom authentication module and requires IIS Anonymous access. I also have Windows Integrated so that I can debug my application.
The issue I am having is the WebHttpBinding created by the WebServiceHost does not support having two authentication methods enabled in IIS. I can turn off Win. Auth. and it works but I can not debug.
So my question is... Can I enable WebHttpBinding to support both or can I somehow enable debugging without Win. Auth.
This service must be hosted as part of the application and I need a way to debug it.
Try debugging WCF REST Service using Fiddler, see the following links for more informations :
http://www.codeproject.com/Tips/213007/Debug-WCF-REST-Service
Depends what you are trying to debug. You could always trace the WCF service using SvcTraceViewer. Here is the config you can use on the server.
I ended up using ASP.NET Web API. I have to say so far I am a big fan!
http://www.asp.net/web-api
Related
I have written WCF and hosted in windows service now when accessing the services via basic http binding, it is showing "This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details." Please suggest solution step by step
Thanks to all for not replying but I got the solution. Please suggest if anything is not in order.
We have created WCF and hosted it in Windows Services as netTCP. Now, I created Silverlight Enabled WCF Services in Silverlight.Web Project and call netTcp service from here and Silverlight WCF enabled Services called in Silverlight Project and it is running fantastic. Before this I tried from Web Service but it is taking when large data calling from silverlight application.
I've been looking into the possibility of using ASP.NET Web API and SignalR in a self-hosted application, and I noticed that the ASP.NET Web API self-hosted implementation uses WCF, and the SignalR self-hosted implementation uses System.Net.HttpListener. This makes it a little harder to come up with a combined self-hosting solution, but it does get me wondering why the different project teams would use different approaches.
What are the advantages and disadvantages of each approach? Is there any particular reason why SignalR could not use WCF self-hosting, or Web API could not use HttpListener?
EDIT: I understand that Web API self-hosting provides a more complete stack than SignalR, my question is more about why you would choose a WCF implementation over System.Net.HttpListener when implementing your own self-hosting solution.
Web API self host provides entire HTTP stack so it's much much richer than System.Net.HttpListener.
SignalR uses that to purely open a communication window for its own purposes.
So yeah for now, you need to run them in parallel on different ports.
In the future, with OWIN, you will have everything under one roof.
EDIT: there was actually an issue similar to yours raised on SignalR github, and the answer was pretty much what I just said - https://github.com/SignalR/SignalR/issues/277
Just so we are on the same page, The WCF Self-host that Web API Self host uses, does use HttpListener under the covers. However, I think I may have found a major downside to the WCF Self-host.
I have not confirmed this yet, but it seems that when you use Web API Self Host, the base address you provide is not translated directly into a HttpListener prefix. It seems like WCF translates the base address and wildcards the host.
This means that the WCF self-host will respond to any host on the specified port. This means that you cannot run a Web API Self hosted service side by side with IIS on the same port using a different host name.
This might be the reason that SignalR decided to scrap the WCF Self-Host and use HTTPListener directly.
While you can use the WCF stack to host the services yourself, you may want to consider the "IIS 7.0 Hostable Web Core". It has the benefit of running IIS in your user process. Using this approach, you can have several applications running on the same port, irrespective of the technologies.
If you are interested, you can look at:
Host your own Web Server in your application using IIS 7.0 Hostable Web Core
Creating Hosted Web Core Applications
This all assumes you are running Vista or later...
We have a windows service that is self-hosting a WCF Data Service, using the DataServiceHost class. Everything is working just fine, but we would like to hook up some HTTPModules to the service, if possible. One of the HTTP Modules would be for custom basic authentication, the other for auditing (including responses, which is why an HTTP Module works so well for this).
Keep in mind that we are running as a regular windows service, so we have no web.config, the service is not hosted by IIS, and it is not an ASP.Net application.
So, my questions are:
Is it possible to have an HTTP Module listen on a self-hosted WCF data service?
If this is not possible, what options would I have that are similiar to the power of an HTTP Module?
WCF doesn't operate on the same request pipeline as standard ASP.NET applications, although you can take advantage of a number of ASP.NET features (like session) if you configure your service for ASP.NET compatibility.
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
However, it looks like you just need something that will let you jump into the pipeline the way that HTTPModules do for an ASP.NET Application. That being the case, there are plenty of options. You can check out this page for a lot of samples.
You mentioned authentication, and there are plenty of options built into WCF that can save you from rolling your own solution. Check it out here.
I've got an MVC web application that is used as an interface to a Console based app that exposes a bunch of ServiceHost/s using the net.pipe protocol.
I would like to use the asp.net membership/role/profile provider to manage my users and their roles and profile information (Inside the Console Application). I've done this in quite a few apps, but normally I reference these providers directly from the web application itself.
This is a good walk-through on doing pretty much what I would like, except I don't want to host the WCF service endpoints in IIS, but inside my console app - which will eventually become a windows service. When I try and host the ServiceHost through my console application I get the following error:
This service requires ASP.NET compatibility and must be hosted in IIS.
Either host the service in IIS with ASP.NET compatibility turned on in
web.config or set the
AspNetCompatibilityRequirementsAttribute.AspNetCompatibilityRequirementsMode
property to a value other than Required.
Now it seems that I won't be able to set that property to anything other than Required.
I've tried another route which is using the wrapper class/interface defined here for my authentication service, which I managed to get wired into in my MVC app without too much trouble, but this doesn't cover my Authorisation (using roles) or profile needs.
Has anyone got a solution to this, I can't be the only one trying to do this? I'm not
I have this existing environment:
1) ASP.NET 3.5 web application
2) forms authentication with the SqlMembershipProvider
I need to add the following:
1) a Silverlight charting object embedded in a web page.
2) a WCF service to be consumed by:
a) the Silverlight component embedded in an authenticated
web page, as mentioned above
b) server-based WCF clients with certificate based authentication
My question is - what is the easiest/best way to configure the WCF endpoints for the Silverlight object to authenticate to the WCF service using the security context of the already logged-in user (via the page that’s hosting the Silverlight object) without having to use the user's username/password again?
I've researched a lot of the MSDN and Patterns & Practices material and I thought I had a decent grasp of many of the potential authentication scenarios. But I can't seem to figure out a way to tie them together for the scenario I've outlined. I've found other people posting similar questions to mine but none of the answers I've read seem to fully answer their questions either. (Maybe I'm making this harder than it needs to be?)
I would think that the solution would be to somehow use the authentication token/cookie generated in the asp.net form login and somehow pass that to the Silverlight object which then includes it in the WCF request. But I don't see how to configure the WCF endpoint to use that token.
(In some of my other projects I've implemented the server-to-server scenario in 2.b above using certificate-based authentication, so I'm not too worried about adding that to the current mix I've outlined.)
Thanks in advance for any insight or pointers to the path forward.
Terry
Thanks codemeit for trying to help but I finally figured out what I was doing wrong - it was pilot error.
In trying to configure the endpoints for my Silverlight app I was testing with an asp.net page. I finally realized that when I test that way, the client endpoint is no longer originating from the authenticated browser - the client endpoint is the IIS server which in turn executes the request against the WCF server endpoint. So the security context changes and HttpContext.Current.User.Identity is always empty at the WCF server endpoint.
Once I got my test SL app running in the browser, it automatically inherited the security context of the authenticated browser and then HttpContext.Current.User.Identity was correct and authenticated at the WCF server endpoint.
Have you tried to enable your WCF services with aspNet compatibility, then see if the following is true.
string currentUserName = HttpContext.Current.User.Identity.Name;
bool isLoggedIn = HttpContext.Current.User.Identity.IsAuthenticated;
if these properties are being populated with the expected values, then this is the one you are after.
To enable aspNet Compatibility
add to web.config
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
add to the service impl class
[AspNetCompatibilityRequirements
(RequirementsMode=AspNetCompatibilityRequirementsMode.Required)]
In this case, the endpoint would be using basicHttpBinding, and you could check the authentication at run time within WCF.