Nicklas Laine Overgaard - 16 - Jan 22, 2015

Hi there,

I’m facing some trouble with using ServiceStack v4 and SOAP. Long story short, I’m tasked with building a SOAP api that BizTalk should interact with.

When enabling the Auth plugin, i’m facing the same trouble as this guy on stackoverflow:

Any suggestions on how to handle this? I would prefer to keep the Auth plugin enabled as I have built a custom “token” auth provider that works with the Authenticate attribute.

It’s unlikely SOAP clients support HTTP Basic Authentication, you should be able to use Credentials (i.e. UserName/Password) AuthProvider but the SOAP Client needs to support Cookies to be able to make subsequent authenticated requests.

Nicklas Laine Overgaard:

+Demis Bellot Yes that is of course an issue - which is why I decided to create a “token auth provider” with auto-login like you suggested on this question:

But I guess disabling the Auth feature and then implementing a custom request filter should do the trick?

Don’t think you’ll need to disable it, if you’re using your own Auth Provider you should be able to detect SOAP requests and handle them differently.

Nicklas Laine Overgaard:

The issue is with the additional types that the AuthProvider registers and renders into the WSDL. When the Visual Studio BizTalk plugin does it’s magic, it tries to validate the entire type hierarchy so it ends up giving errors like:

A screenshot the BizTalk guy sent me:

And finally, I have these things registered in the DTO project’s AssemblyInfo to try and navigate around the issue:

Unfortunately the Assembly Contract namespaces only works for classes in that Assembly, i.e. you wont be able to redefine namespaces for types in different dls.

I’ve just added an Assembly Contract for ServiceStack.Client in this commit:

This should help with the namespace of the Authenticate DTO’s. This change is now on v4.0.37+ that’s now on MyGet:

Nicklas Laine Overgaard:

You are the man +Demis Bellot . Thank you!