Personalize

Text Size

Layout

Navigation Position

hacked.brain

Ramblings from a compromised mind.

<< Major Vista Problem Strikes | Home | Collection properties need a setter implementation when using DataContractSerializer >>

I've hit a snag with TransportWithMessageCredential over plain HTTP

So a couple days ago I posted an entry about how to implement a custom transport that allows you to send message credentials over plain old HTTP. Unfortunately when I rolled this into the test environment where I had all the "real" infrastructure in place I ran into a new problem. It appears that the username token implementation built into WCF has some hardcoded logic for how it deals with addresses. I have filed a bug over on Microsoft Connect and I hope that Microsoft addresses it soon. Lately they haven't responded to a single post I've made about WCF problems in the forums including the original question about how to even solve the SSL passthrough problem. :(

The fact is, there's a workaround but it's completely unreasonable because none of Microsoft's own web service stacks (WSE, WCF, built in .NET) make it easy to change the address of the request. They just assumes that the wsa:To should be the URL that your connecting to... and technically this is right 99% of the time. The workaround for now is that I have to have my client connect to https, but change the actual wsa:To to be http. Does it work? Yes. Should I have to resort to that? No way. :\

Monday, October 02, 2006 6:07 PM

Your Comments.

# re: I've hit a snag with TransportWithMessageCredential over plain HTTP
Drew,

Out of curiosity: Have you tried just inserting a via element on the client side and see if it works? (i.e. leave your wsa:To alone and add a wsa:via pointing to where you're really connecting).

I ask because it sure sounds like the kind of problems you run if, for example, you try introducing TcpTrace in the middle of a WS-Addressing aware connection, and that's the usual workaround:
http://www.winterdom.com/weblog/2006/04/17/RedirectingThroughTcpTraceWithWSEAndWCF.aspx

Left by Tomas Restrepo at 10/2/2006 8:35 PM
# re: I've hit a snag with TransportWithMessageCredential over plain HTTP
Tomas,

Yes, it's exactly the same kind of problem. I'm certain that clientVia would be a good workaround for WCF, but in my case I was actually using SOAP toolkit and WSE 3.0 as test clients since I want to make sure I'm not locking myself into anything WCF specific.

The workaround for SOAP toolkit was pretty easy because you have to do all the addressing headers yourself there anyway. I *think* the workaround for WSE 3.0 is to set the RequestSoapContract.Addressing.To propery of the proxy, but I haven't gotten it to work just yet... think I'm missing something silly.

So yeah, I have work arounds, but, as I'm sure you realize, they're not ideal. I'd have to document in big red bold letters that the To needs to be set to something diff. than the actual URL, because every stack out there combines the concepts two when they generate proxies. :\

Thanks,
Drew

Left by Drew Marsh at 10/2/2006 10:12 PM
# re: I've hit a snag with TransportWithMessageCredential over plain HTTP
So, quick follow up:

For WSE you need to set the Destination property of the proxy to a new EnpointReference with the correct URI (which would be the http address in my case).

Left by Drew Marsh at 10/2/2006 10:47 PM
# re: I've hit a snag with TransportWithMessageCredential over plain HTTP
Drew,

Well, the page I referenced showed how to do it both for WSE and WCF :)

Am glad at least you have a temporary workaround. Not pretty, I agree, though...

Left by Tomas Restrepo at 10/3/2006 12:47 AM
# re: I've hit a snag with TransportWithMessageCredential over plain HTTP
D'oh, sorry 'bout that. Luckily I didn't waste too much time finding Destination by myself. :)

Left by Drew Marsh at 10/3/2006 9:46 PM

Comments have been closed on this topic.