How can I access HttpContext.Current.User.Username from a web application in a WCF service?
Generally you don't - HttpContext is an ASP.NET concept and doesn't apply to WCF unless you run it with ASP.NET Compatibility turned on.
If you want the current user in WCF then use ServiceSecurityContext.Current.PrimaryIdentity or get the security context via the OperationContext.
Actually, with Asp.Net Compatibility mode on, you can access HttpContext.Current.User from a WCF service hosted in the site. See Microsoft's site for details: https://msdn.microsoft.com/en-us/library/aa702682(v=vs.110).aspx
If your service is hosted in an Asp.net site you just need to update your web.config to set aspNetCompatibilityEnabled="true" on the serviceHostingEnvironment element:
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
</system.serviceModel>
Related
i added
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
but it's giving me an error"
The service cannot be activated because it requires ASP.NET compatibility. ASP.NET compatibility is not enabled for this application
it seems like the WCF service has no HTTP context related to it? please help
It has check out the following link
http://msdn.microsoft.com/en-us/library/aa702682.aspx
and make sure you have added this tag in your web config
In a related post, I am having trouble connecting to a basicHttp endpoint and it seems that it is due to WCF impersonation issues when connecting to a downstream service. The funny thing is that it works fine when I replace the basicHttp WCF service with an ASMX web service. Both services use <identity impersonate="true" userName=".." password=".." /> from ASP.NET web.config file, but the ASMX service works while the basicHttp WCF service doesn't.
Does this seem likely to be some sort if Kerberos delegation issue between ASP.NET and WCF?
Or is there something that I can add to my WCF configuration to pass this impersonated user (note I am using framework 4, so I currently have almost no configurtation)?
Finally worked out that I needed to add <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/> to the WCF part of the web.config file, and an AspNetCompatibilityRequirementsMode attribute to the implementation of the basicHttp endpoint. This will then call the downstream netTcp endpoint using the credentials defined in <identity impersonate="true" userName=".." password=".." />.
I'm able to run the WCF-SecureProfile sample that comes with the MSFT WCF samples download (http://msdn.microsoft.com/en-us/library/ee818238.aspx)
However I can't port this server component to IIS. I get the error that
<MakeConnectionBindingElement/> can't be loaded. Considering that I have the behavior extensions loaded I don't know why IIS can't see the extension, however the self-host version of my app can.
I uploaded the sourcecode of the project into codeplex for easy browsing. Here is a direct link to web.config and all other files.
2
I got the sample and set it up to run on IIS local. I didn't get the same issue as the one in this question but I did run into a big gotcha. Accessing the service in IIS gave me this error message:
Contract requires Duplex, but Binding 'BasicHttpBinding' doesn't support it or isn't configured properly to support it.
After some head scratching, I found the cause of this issue. WCF 4 now assigns default bindings to each transport (I'm liking this feature less & less). For the HTTP transport, the default binding is basicHttpBinding. The problem is the customBinding config does not override any default binding. This causes WCF to attempt to configure duplex over basicHttpBinding which of course isn't supported. The fix is to turn off the default transport mapping for HTTP and assign it to your custom binding as shown below for this service:
<protocolMapping>
<clear/> <!-- removes all defaults which you may or may not want. -->
<!-- If not, use <remove scheme="http" /> -->
<add scheme="http" binding="customBinding" bindingConfiguration="rspBinding"/>
</protocolMapping>
Once I added this to the serviceModel element, the IIS based service worked just fine.
I am new to WCF and WCF derived services.
I am using VS 2010, silverlight 4, ria services 4.
Recently I created plain WCF REST services (no RIA, no SOAP) with my endpoint (using wsHttpBinging):
<endpoint address="" behaviorConfiguration="wsBehavior" binding="wsHttpBinding" bindingConfiguration="wsbinding" contract="WcfService1.IService1"/>
<behaviors>
<endpointBehaviors>
<behavior name="wsBehavior">
<webHttp/>
</behavior>.........
I use this service from silverlight 4 client and everything works fine.
THEN, i created new project using "silverlight Business application" template which used RIA service. Now the web.config uses DomainServices and when i add wsHttpBind endpoint I doesnot work. I know i am not doing this correctly and i cant find any help online so far.
What I am trying to do is creat a RESTful WCF application with RIA (no SOAP) and that i can use from silverlight 4 client. For some reason i cannot get the service working.
I don't think silverlight supports wsHttpBinding.
I want to get the working folder of a WCF application. How can I get it?
If I try
HttpContext.Current.Request.MapPath(HttpContext.Current.Request.ApplicationPath)
I get a null reference exception (the Http.Current object is null).
What I meant with the working folder was the folder where my WCF service is running. If I set aspNetCompatibilityEnabled="true", I get this error:
The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error.
I needed the same information for my IIS6 hosted WCF application and I found that this worked for me:
string apPath = System.Web.Hosting.HostingEnvironment.ApplicationPhysicalPath;
As always, YMMV.
Please see ongle's answer below. It is much better than this one.
Updated after more information
The following worked for me. I tested it with a new WCF Service I hosted on IIS through a Service1.svc.
Add <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/> to web config. <system.serviceModel>..</ ..> existed already.
Add AspNetCompatibilityRequirementsAttribute to the service with Mode Allowed.
Use HttpContext.Current.Server.MapPath("."); to get the root directory.
Below is the full code for the service class. I made no changes in the IService1 interface.
[AspNetCompatibilityRequirements(RequirementsMode=AspNetCompatibilityRequirementsMode.Allowed)]
public class Service1 : IService1
{
public void DoWork()
{
HttpContext.Current.Server.MapPath(".");
}
}
And below is an excerpt from the web.config.
<system.serviceModel>
<!-- Added only the one line below -->
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
<!-- Everything else was left intact -->
<behaviors>
<!-- ... -->
</behaviors>
<services>
<!-- ... -->
</services>
</system.serviceModel>
Old answer
What do you mean by the Working Folder? WCF services can be hosted in several different ways and with different endpoints so working folder is slightly ambiguous.
You can retrieve the normal "Working folder" with a call to Directory.GetCurrentDirectory().
HttpContext is an ASP.Net object. Even if WCF can be hosted on IIS, it's still not ASP.Net and for that reason most of the ASP.Net techniques do not work by default. OperationContext is the WCF's equivalent of HttpContext. The OperationContext contains information on the incoming request, outgoing response among other things.
Though the easiest way might be to run the service in ASP.Net compatibility mode by toggling it in the web.config. This should give you access to the ASP.Net HttpContext. It will limit you to the *HttpBindings and IIS hosting though. To toggle the compatibility mode, add the following to the web.config.
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
</system.serviceModel>
Depending on what you want. I usually want to resolve a url like "~/folder/file". This is what worked.
System.Web.Hosting.HostingEnvironment.MapPath("~/folder/file");
More general, I am using this one
AppDomain.CurrentDomain.BaseDirectory
The aspNetCompatibilityEnabled="true" should have resolved my problem, but I got this error:
The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error.
I resolved my problem with getting the physical path of my running WCF service by getting it from my current app domain:
AppDomain.CurrentDomain.BaseDirectory
In order to reference ASP.NET features like the HttpContext object, you need to run your WCF app in ASP.NET compatibility mode. This article explains how to do this.
Use HostingEnvironment.ApplicationPhysicalPath in WCF to find your application physical path.
Use namespace
using System.Web.Hosting;