Develop Reference

WCF basicHttpBinding configuration is being ignored

I'm having an issue with my basicHttpBinding configuration in web.config file, all configuration was configured through "Edit WCF configration" VS2013 tool, but when I called method in "WCFTestClient" tool it returned:
The maximum message size quota for incoming messages (65536) has been exceeded.
I know that my configuration is OK and it's being ignored because when I open that config "WCFTestClient" tool it shows me different values, default values. Then why MS is offering that configuration if it's being ignored brutally, that's stupid, I guess. But the main question would be, how can I resolve it, or to tell him to take my configuration not his, compiled from somewhere?
P.S my Web.config basicHttpBinding
<basicHttpBinding>
<binding name="BindingConfiguration" closeTimeout="01:50:00"
openTimeout="01:50:00" receiveTimeout="01:50:00" sendTimeout="01:50:00"
maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">
<readerQuotas maxDepth="128" maxStringContentLength="8388608"
maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
</binding>
</basicHttpBinding>
and usage:
<endpoint address="PersonService" binding="basicHttpBinding"
bindingConfiguration="BindingConfiguration" name="PersonSvcBasicHttpBinding"
contract="WebService.IPersonService" />

Usually having both maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647" works for me.

WCF Service failing - HTTP/1.1 400 Bad Request

I was getting exception while making a call the my WCF service more larger request XML object content length 65708, where it is working without any issues with request XML file content length less than this.
This is service we are exposed to external clients and I used SoapUI to debug the service and I am getting the exception HTTP/1.1 400 Bad Request[\r][\n] and not even hitting to the debug point. I searched the web and applied the configuration values provided, but none of them helped me to resolve the issue.
After all the config changes, my web.config file is looks like this (only binding part).
<bindings>
<basicHttpBinding>
<binding name="GDASHttp" closeTimeout="00:10:00" openTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferSize="2147483647" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647" messageEncoding="Mtom" textEncoding="utf-8" transferMode="Streamed" useDefaultWebProxy="true">
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647"/>
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows"/>
</security>
</binding>
</basicHttpBinding>
I didn't changed any settings in the client file as I can getting the exception from SoapUI and issue is related to server configuration only. I do understand the issue with some the settings is accepting according to the file size, but not sure what is maximum values we can provide in the above settings.
I modified the IIS settings as per some of the Google advises in the server and this is my changed applicationhost.config file.
<location path="Default Web Site/GDAS.FY15R2.3.1/Trusted" overrideMode="Allow">
<system.webServer>
<handlers accessPolicy="Read, Execute" />
<security>
<ipSecurity>
<add ipAddress="127.0.0.1" subnetMask="255.255.255.255" allowed="true" />
</ipSecurity>
<requestFiltering>
<requestLimits maxAllowedContentLength="40000000" />
</requestFiltering>
</security>
<serverRuntime uploadReadAheadSize="2147483647" />
</system.webServer>
</location>

This is the value you would use: 2147483647
But for WCF you need to configure that in both the client and the server. You can not just change the Server Binding, as the two Bindings are basically shaking hands so the MAX value should match in both configs.
I would turn on tracing and see exactly what is happening.

WCF Authentication Error

I'm accessing a third party WCF service (I have no access to the service configuration) We're using SSL certificates for the authentication.
I'm getting this error when trying to access to any of the provided methods
The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The
authentication header received from the server was 'Negotiate,NTLM
I checked many google links and no luck so far- No idea what else to check on my side.
EDIT
Here is the configuration
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="wsHttpBinding" closeTimeout="00:01:00" openTimeout="00:01:00"
receiveTimeout="00:10:00" sendTimeout="00:01:00" bypassProxyOnLocal="false"
transactionFlow="false" hostNameComparisonMode="StrongWildcard"
maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
allowCookies="false">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<reliableSession ordered="true" inactivityTimeout="00:10:00"
enabled="false" />
<security mode="Transport">
<transport clientCredentialType="Windows" proxyCredentialType="None"
realm="" />
<message clientCredentialType="Windows" negotiateServiceCredential="true"
establishSecurityContext="true" />
</security>
</binding>
</wsHttpBinding>
</bindings>
<client>
<endpoint address="https://url"
binding="wsHttpBinding" bindingConfiguration="wsHttpBinding"
contract="IApiWS" name="wsHttpBinding">
</endpoint>
</client>
</system.serviceModel>

Try setting your clientCredentialType="Windows" to clientCredentialType="Certificate" I usually use hard-coded WCF config, not config file, so I'm not really sure on this, but either way, take a look at the following link: Selecting a Credential Type on MSDN.
Good luck. I'm surprised what/whom you're connecting to didn't give explicit endpoint connection instructions, but hey, you deal with every kind when working with 3rd-party stuff.

Ok, this may be a little vague so I aplogise in advance, essentially the server is telling you you are not authorised, normally for this you would add something like the below onto the proxy you generated
svc.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;
where svc is your generated proxy. I have also seen this on a misconfigured IIS hosted endpoint where the virtual folder does not have allow anonymous set (though you say you cannot access the service configuration so that may not be to helpful). hope this helps
edit added more info,
It may be, depending on security, that a setting similar to below may be more usefull
svc.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Anonymous;
Edit 2
The config above shows that the wsHttpBinding you are using has Windows set as clientCredentialtype for the transport security and user authentication, this mean that you will be sending through the credentials of the currently logged on user to the service for authentication using NTLM (as negotiateServiceCredentials is true) have you confirmed that the user logged on has rights on the service?

The HTTP request is unauthorized with client authentication scheme 'Ntlm' The authentication header received from the server was 'NTLM'

I know there's a lot of questions on SO similar to this, but I couldn't find one for this particular issue.
A couple of points, first:
I have no control over our Sharepoint server. I cannot tweak any IIS settings.
I believe our IIS server version is IIS 7.0.
Our Sharepoint Server is anticipating requests via NTLM.
Our Sharepoint Server is on the same domain as my client computer.
I am using .NET Framework 3.5, Visual Studio 2008
I am trying to write a simple console app to manipulate Sharepoint data using Sharepoint Web Services. I have added the Service Reference, and the following is my app.config:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="ListsSoap" closeTimeout="00:01:00" openTimeout="00:01:00"
receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false"
bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<security mode="Transport">
<transport clientCredentialType="Ntlm" proxyCredentialType="Ntlm" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="https://subdomain.companysite.com/subsite/_vti_bin/Lists.asmx"
binding="basicHttpBinding" bindingConfiguration="ListsSoap"
contract="ServiceReference1.ListsSoap" name="ListsSoap" />
</client>
</system.serviceModel>
This is my code:
static void Main(string[] args)
{
using (var client = new ListsSoapClient())
{
client.ClientCredentials.Windows.ClientCredential = new NetworkCredential("username", "password", "domain");
client.GetListCollection();
}
}
When I call GetListCollection(), the following MessageSecurityException gets thrown:
The HTTP request is unauthorized with client authentication scheme 'Ntlm'.
The authentication header received from the server was 'NTLM'.
With an inner WebException:
"The remote server returned an error: (401) Unauthorized."
I've tried various bindings and various code tweaks to try to authenticate properly, but to no avail. I'll list those below.
I've tried the following steps:
Using a native Win32 Impersonator before creating the client
using (new Impersonator.Impersonator("username", "password", "domain"))
using (var client = new ListsSoapClient())
{
client.ClientCredentials.Windows.ClientCredential = new NetworkCredential("dpincas", "password", "domain");
client.GetListCollection();
}
This produced the same error message.
Setting TokenImpersonationLevel for my client credentials
using (var client = new ListsSoapClient())
{
client.ClientCredentials.Windows.AllowedImpersonationLevel = TokenImpersonationLevel.Impersonation;
client.GetListCollection();
}
This produced the same error message.
Using security mode=TransportCredentialOnly
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm" />
</security>
This resulted in a different error message:
The provided URI scheme 'https' is invalid; expected 'http'.
Parameter name: via
However, I need to use https, so I cannot change my URI scheme.
I've tried some other combinations that I can't remember, but I'll post them when I do. I'm really at wits end here. I see a lot of links on Google that say "switch to Kerberos", but my server seems to only be accepting NTLM, not "Negotiate" (as it would say if it was looking for Kerberos), so that is unfortunately not an option.
Any help out there, folks?

Visual Studio 2005
Create a new console application project in Visual Studio
Add a "Web Reference" to the Lists.asmx web service.
Your URL will probably look like: http://servername/sites/SiteCollection/SubSite/_vti_bin/Lists.asmx
I named my web reference: ListsWebService
Write the code in program.cs (I have an Issues list here)
Here is the code.
using System;
using System.Collections.Generic;
using System.Text;
using System.Xml;
namespace WebServicesConsoleApp
{
class Program
{
static void Main(string[] args)
{
try
{
ListsWebService.Lists listsWebSvc = new WebServicesConsoleApp.ListsWebService.Lists();
listsWebSvc.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials;
listsWebSvc.Url = "http://servername/sites/SiteCollection/SubSite/_vti_bin/Lists.asmx";
XmlNode node = listsWebSvc.GetList("Issues");
}
catch (Exception ex)
{
Console.WriteLine(ex.ToString());
}
}
}
}
Visual Studio 2008
Create a new console application project in Visual Studio
Right click on References and Add Service Reference
Put in the URL to the Lists.asmx service on your server
Ex: http://servername/sites/SiteCollection/SubSite/_vti_bin/Lists.asmx
Click Go
Click OK
Make the following code changes:
Change your app.config file from:
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
To:
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm"/>
</security>
Change your program.cs file and add the following code to your Main function:
ListsSoapClient client = new ListsSoapClient();
client.ClientCredentials.Windows.ClientCredential = System.Net.CredentialCache.DefaultNetworkCredentials;
client.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;
XmlElement listCollection = client.GetListCollection();
Add the using statements:
using [your app name].ServiceReference1;
using System.Xml;
Reference: http://sharepointmagazine.net/technical/development/writing-caml-queries-for-retrieving-list-items-from-a-sharepoint-list

After a lot of trial and error, followed by a stagnant period while I waited for an opportunity to speak with our server guys, I finally had a chance to discuss the problem with them and asked them if they wouldn't mind switching our Sharepoint authentication over to Kerberos.
To my surprise, they said this wouldn't be a problem and was in fact easy to do. They enabled Kerberos and I modified my app.config as follows:
<security mode="Transport">
<transport clientCredentialType="Windows" />
</security>
For reference, my full serviceModel entry in my app.config looks like this:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="TestServerReference" closeTimeout="00:01:00" openTimeout="00:01:00"
receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false"
bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="2000000" maxBufferPoolSize="2000000" maxReceivedMessageSize="2000000"
messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<security mode="Transport">
<transport clientCredentialType="Windows" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="https://path/to/site/_vti_bin/Lists.asmx"
binding="basicHttpBinding" bindingConfiguration="TestServerReference"
contract="TestServerReference.ListsSoap" name="TestServerReference" />
</client>
</system.serviceModel>
After this, everything worked like a charm. I can now (finally!) utilize Sharepoint Web Services. So, if anyone else out there can't get their Sharepoint Web Services to work with NTLM, see if you can convince the sysadmins to switch over to Kerberos.

After many answers that did not work, I finally found a solution when Anonymous access is Disabled on the IIS server. Our server is using Windows authentication, not Kerberos. This is thanks to this blog posting.
No changes were made to web.config.
On the server side, the .SVC file in the ISAPI folder uses MultipleBaseAddressBasicHttpBindingServiceHostFactory
The class attributes of the service are:
[BasicHttpBindingServiceMetadataExchangeEndpointAttribute]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
public class InvoiceServices : IInvoiceServices
{
...
}
On the client side, the key that made it work was the http binding security attributes:
EndpointAddress endpoint =
new EndpointAddress(new Uri("http://SharePointserver/_vti_bin/InvoiceServices.svc"));
BasicHttpBinding httpBinding = new BasicHttpBinding();
httpBinding.Security.Mode = BasicHttpSecurityMode.TransportCredentialOnly;
httpBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Ntlm;
InvoiceServicesClient myClient = new InvoiceServicesClient(httpBinding, endpoint);
myClient.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;
(call service)
I hope this works for you!

If I recall correctly, there are some issues with adding SharePoint web services as a VS2K8 "Service Reference". You need to add it as an old-style "Web Reference" to work properly.

I have the same setup that you do, and this works fine for me. I think that maybe the problem lies somewhere on your moss configuration or on your network.
You said that moss resides on the same domain as your application. If you have access to the site with your user (that is logged into your machine)... have you tried:
client.ClientCredentials.Windows.ClientCredential = System.Net.CredentialCache.DefaultNetworkCredentials;

I had exactly the same issue last week - WCF program behaves strangely on one server - why?
For me the solution was rather simple. Sharepoint has its own set of permissions. My client tried to log on as a user that wasn't explicitly given access to the webservice through Sharepoint's administration panel.
I added the user to Sharepoint's whitelist and bang - it just worked.
Even if that isn't the issue, please note that
The HTTP request is unauthorized with client authentication scheme ‘Ntlm’. The authentication header received from the server was ‘NTLM’.
Means (in English) that you simply don't have permission. Your protocol is probably right - your user just doesn't have permissions.

I would try to connect to your Sharepoint site with this tool here. If that works you can be sure that the problem is in your code / configuration. That maybe does not solve your problem immediately but it rules out that there is something wrong with the server. Assuming that it does not work I would investigate the following:
Does your user really have enough rights on the site?
Is there a proxy that interferes? (Your configuration looks a bit like there is a proxy. Can you bypass it?)
I think there is nothing wrong with using security mode Transport, but I am not so sure about the proxyCredentialType="Ntlm", maybe this should be set to None.

I have had this issue before.
client.ClientCredentials.Windows.AllowedImpersonationLevel = TokenImpersonationLevel.Impersonation;
do this against your wcf proxy before making the call.

Try this
<client>
<endpoint>
<identity>
<servicePrincipalName value="" />
</identity>
</endpoint>
</client>
I've encountered this error before when working in a webfarm and this fixed it for me.

This issue was even more strange for us. Everything worked if you had previously visited the sharepoint site from the browser, before you made the SOAP call. However, if you did the SOAP call first we'd throw the above error.
We were able to resolve this issue by installing the sharepoint certificate on the client and adding the domain to the local intranet sites.

Workflow as WCF Service Unexpectedly stops

We have a .Net 3.5 Workflow hosted as a service that sometimes stops unexpectedly. This has occurred at times while it is writing a file and, most recently, when receiving a reply from another WCF service. There are no exceptions being caught, as these all get logged, and there are no messages in the event logs on the server where both are hosted. I added logging to verify that the service is completing it's logic, which it is (taking about 6 minutes). All my timeouts are far higher than they need be. I'm starting to think the issue might be that the channel is getting closed and, due to the very high timeouts, an error is not yet thrown. Of potential relevance, the workflow is calling the wcf service asynchronously and then using a WaitOne() on the AsyncWaitHandle. I have a feeling this is maybe not the best idea, but I'm not sure if it could cause this issue. Also, persistence is not set up on the workflow (I had previously thought that the unloadOnIdle setting might have been causing issues with getting return values from the called service, as I'm not very clear on how this is supposed to work).
Any help/advice would be greatly appreciated.

Have you checked the timeout settings on the client. I know in the past I had to update both the client timeout settings as well as the server settings.

In the workflow App.config (missing a timeout for the hosting of the workflow?):
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IService" closeTimeout="00:02:00"
openTimeout="00:02:00" receiveTimeout="04:00:00" sendTimeout="04:00:00"
allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="655360000" maxBufferPoolSize="2147483647" maxReceivedMessageSize="655360000"
messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://url/Service.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IService"
contract="DALService.IService" name="BasicHttpBinding_IService" />
</client>
In the DalService WCF web.config:
<httpRuntime
maxRequestLength="1048576"
executionTimeout="6000000"
/>
<basicHttpBinding>
<binding name ="LargeMessageBinding"
closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="04:30:00" sendTimeout="04:30:00"
allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="655360000" maxBufferPoolSize="524288" maxReceivedMessageSize="655360000"
messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
useDefaultWebProxy="true"
/>
<!--maxReceivedMessageSize="6553600" -->
<!--maxBufferSize="6553600" -->

Turns out, the workflow was not being hosted in its own worker process, as I had thought. Another app was crashing the process. The WCF service was correctly configured to use its own worker process, hence it would correctly return, but to a no longer running app.