I have OpenRIA WCF Service hosted within an asp.net website. I have a WPF client that connects to the Authentiction and DomainService. I am having trouble calling the Login method. It basically does not like that the message parameters are not "Wrapped". See the error message below
An unhandled exception of type 'System.InvalidOperationException' occurred in OpenRiaServices.DomainServices.Client.dll Additional information: Operation 'Login' of contract 'IPatientAuthenticationDomainServiceContract' specifies multiple request body parameters to be serialized without any wrapper elements. At most one body parameter can be serialized without wrapper elements. Either remove the extra body parameters or set the BodyStyle property on the WebGetAttribute/WebInvokeAttribute to Wrapped. On the client side, The WebHttpBehavior in domainClient.ChannelFactory.Endpoint.EndpointBehaviors has DefaultBodyStyle = Wrapped
The asp.net project that's hosting the OpenRIA services has web behavior set to Wrapped.
<system.serviceModel>
<behaviors>
<endpointBehaviors>
<behavior name="web">
<webHttp defaultBodyStyle="Wrapped"/>
</behavior>
</endpointBehaviors>
</behaviors>
</system.serviceModel>
What could I be missing? Has anyone encountered this issue?
A possible workaround is to change the method parameters to accept a complex type but I do not have control over the Login method of the AuthenticationService. It is part of a base class that RIA framework provides.
Thanks,
Ankur
Issue resolved. Just wanted to share the fix. I am using SharedCookieContainer that Kyle McClellan wrote for sharing cookie between Auth service and Domain service when not using an in-browser client. See http://blogs.msdn.com/b/kylemc/archive/2010/05/14/ria-services-authentication-out-of-browser.aspx
The SharedCookieBehavior in this code is an extension of WebHttpBehavior. This class needs to have the DefaultBodyStyle set to Wrapped when its newed up. Simple fix but took me a while to figure out.
Thanks,
Ankur
Related
I have an ASP.NET application calling a WCF service.
In ASP.NET application, I make a call to ADFS to perform authentication and I can see all the claims of the user in CurrentPrincipal. Then I perform the call of the WCF service (wsHttpBinding), but the list of claims is empty.
What could be the reason?
If I'am not mistake there different ways to get Claims in WCF.
Thread.CurrentPrincipal - Simple and easy to used but need some setting in your configuration, which is most neglected.
<behaviors>
<serviceBehaviors>
<behavior name="Test.Services.WifBehavior">
<serviceCredentials useIdentityConfiguration="true" />
<!---Set principalPermissionMode to always to pass the ClaimsIdentity info to the Thread.CurrentPrincipal-->
<serviceAuthorization principalPermissionMode="Always"/>
</behavior>
<serviceBehaviors>
</behaviors>
OperationContext.Current.ClaimsPrincipal - I can't remember if this needs some configuration but I guess you can get it directly from method invoked.
OperationContext.ServiceSecurityContext.AuthorizationContext.ClaimSets - Create a Custom Authorization Manager for a Service and need to add in config.
Note that I used Windows Identity Foundation (WIF).
I have, without any luck, been googling for some time now trying to find out how a WCF service reacts to null values - both directly as in the actual parameter of the service method is set to null; as well indirectly: any property of the parameter (DataContract-annotated object) is null.
Should my service perform null checks on any property value it accesses or is this somehow implicit? In case my service method performs a call on a null-property, will this simply result in a FaultException (without any information on what went wrong) being passed to the client?
Regards
I turned on error reporting in my service configuration to return useful error information to the client:
<behaviors>
<serviceBehaviors>
<behavior name="errorEnabledBehavior">
<serviceDebug includeExceptionDetailInFaults="true"/> <!-- THIS IS IT! -->
</behavior>
</serviceBehaviors>
</behaviors>
Make sure to use this behavior in your service definition
<service behaviorConfiguration="errorEnabledBehavior" ...>
EDIT
I'm using this in a local environment where I log errors on the server side anyway including a full stack trace. As the OP mentioned in his comment, passing this information to the client may be dangerous and should not be used in a production environment. Another solution would be to use a custom fault contract as described here.
I have a WCF web service hosted in IIS7 which is reporting its endpoint URL as the following in its WSDL
http://machinename/virtualdirectory/service.svc
However the actual public URL which clients need to use is actually
http://machinename.mydomain.com/virtualdirectory/service.svc
And so at the moment clients that attempt to use this web service fail unless they manually edit the endpoint URL.
I know that I can fix this by changing the bindings of the site in IIS as per HOWTO: Fix WCF Host Name on IIS however in this case the site is shared with another application which stops working if I do this and so this isn't an option.
Is there another way that I can change the endpoint URL that WCF uses for this one virtual directory?
Although not directly answering my question (how can I set the WSDL endpoint URL in the web.config file) adding the <useRequestHeadersForMetadataAddress /> element to the <serviceBehaviors> section of my web.config file did fix my problems as now the endpoint URL is based on the URL used to access the WSDL, which is always the same as the URL used to call the web service.
Note that in this SO question it indicated that I needed to supply port numbers, note that this wasn't necessary for me - just adding the <useRequestHeadersForMetadataAddress /> element was enough
<serviceBehaviors>
<behavior name="<name>">
<!-- Other options would go here -->
<useRequestHeadersForMetadataAddress />
</behavior>
</serviceBehaviors>
There are a couple of options depending on which version of WCF your service is using. If you're using .NET 4 or higher, look at the accepted answer to this SO question. Otherwise you can either apply the hotfix that question references or if you're really desperate, hack the metadata URL of the httpGetUrl attribut to point to a copy of the WSDL which has been manually edited to contain the desired endpoint URL.
I was hoping to be able to protect my WCF services on an operation level not service level.
Hence some methods are protected and others not. I know there is an attribute called PrincipalPermission but this works with Windows
I was hoping something existed for WCF Soap like it does for WCF Rest in this contrib project. WcfRestContrib
This extra project allows the use of a custom username and password validator and allow it only to protect certain methods by decorating the methods with an attribute
Is this possible with WCF (soap)?
Thanks in advance
Yes, it is possible to do operation level authorization checks with SOAP in WCF, but you'll need to do claims based authorization (as far as I know). That's what my team does for our product.
The hook point in WCF is to implement a custom ServiceAuthorizationManger
ServiceAuthorizationManager.CheckAccessCore Method
How to: Create a Custom Authorization Manager for a Service
and plug that into your service behaviour:
<behaviors>
<serviceBehaviors>
<behavior name="ServiceBehavior">
<serviceAuthorization serviceAuthorizationManagerType="MyServiceAuthorizationManager" />
</behavior>
</serviceBehaviors>
When you implement your authorization manager, override CheckAccessCore, and then simply return true/false is they are authorized or not.
I have created a WCF service, now this WCF service has to call a Web Service. What I am doing is adding the service reference of web service in WCF and calling the method of the web service which I want to use.
Just an example shown below :
CalcWebReference.CalculatorSoapClient fct =
new CalcWebReference.CalculatorSoapClient();
int rq = fct.Add(q, r);
return rq;
Now this method when I tried to call from the client it is giving following error
The server was unable to process the
request due to an internal error. For
more information about the error,
either turn on
IncludeExceptionDetailInFaults (either
from ServiceBehaviorAttribute or from
the configuration
behavior) on the server in order to
send the exception information back to
the client, or turn on tracing as per
the Microsoft .NET Framework 3.0 SDK
documentation and inspect the server
trace logs.
Thanks i did what u told but now i am getting following error "Could not find default endpoint element that references contract 'CalcWebReference.CalculatorSoap' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element."
Now do i need to give some end points in the WCF service or in the web service to get the function from web service and if so then how do i give it.
Please help.
Hi,
CalcWebReference.CalculatorSoapClient is reffering to the web service not WCF.
Given below is the code written in WCF(sample code) which is calling the web service :-
CalcWebReference.CalculatorSoapClient fct = new CalcWebReference.CalculatorSoapClient();
int rq = fct.Add(12, 10);
return rq;
Am i not putting the syntax right or is there any additional thing that i need to do in this?
This is the generic WCF "something bad happened" error message. That won't really be much help.
Approaches:
make sure the web service you're calling works on its own - otherwise fix it!
enable the detailed error information, as described in the error message, by including the error details in your WCF service (do this in DEV environments only! Never in production...)
try to launch your WCF service inside Visual Studio and debug what's happening
In order to enable detailed error reporting, you need to add this section to your WCF service's configuration:
<behaviors>
<serviceBehaviors>
<behavior name="DebugBehavior">
<serviceDebug includeExceptionDetailInFaults="True" />
</behavior>
</serviceBehaviors>
</behaviors>
You might already have a service behavior configured - in that case, just add the <serviceDebug> tag to your service behavior.
If you don't have a service config yet - you'll also need to make sure your service actually uses that service config:
<service name="YourServiceNameHere"
behaviorConfiguration="DebugBehavior">
Make sure to have a behaviorConfiguration= attribute on your <service> tag, and make sure to reference that defined service behavior (by specifying its <behavior name="..." > property).
Once you've done that, your error should hopefully give you more information - you should definitely get an .InnerException on your exception that should point you in the right direction.