WCF deliberately divorces itself from the transport, as WCF must work
equally with HTTP, TCP, MSMQ, carrier-pidgeon, etc.
What specifically are you looking to do? For custom authentication,
see below; for other operations, "inspectors" are often the way to
go...
You might also find the
microsoft.public.windows.developer.winfx.indigo group more apt.
http://groups.google.co.uk/group/microsoft.public.windows.developer.winfx.indigo
/browse_thread/thread/5b4d8a5790e76feb/4040905d321cce17
Marc
Marc Gravell - 18 May 2007 00:15 GMT
> microsoft.public.windows.developer.winfx.indigo group
Oops! my bad... my aggregator confused me... I thought this was
somewhere else ;-p
Marc
Marc Gravell - 18 May 2007 00:16 GMT
(ahh... multipost... don't do that ;-p)
dgilbert@cragmonttech.com - 18 May 2007 17:24 GMT
> WCF deliberately divorces itself from the transport, as WCF must work
> equally with HTTP, TCP, MSMQ, carrier-pidgeon, etc.
[quoted text clipped - 9 lines]
>
> Marc
I need to pass in a third-party session id, along with the username
and password that is used for authentication for a WCF service that is
hosted in IIS. I was hoping to use a cookie to return the session id
to the client and have them resubmit it on each request. I am using a
custom membership provider to implement the custom authentication
logic. I use this membership provider for web apps also so it has to
be ASP.NET compatible. When I use the attribute to make WCF ASP.NET
compatible I see neither the HttpContext nor the
OperationContext.Current objects. These appear to not be instantiated
until I get past the authentication process in WCF - in plain asp.net
this works fine. Can anyone confirm that this is normal behavior for
WCF? Also, is there a way that cookie data gets mapped to objects in
WCF? Lastly, other than using custom tokens or explicit parameters,
are there any other recommended approaches to passing in data to be
used in the preprocessing of a WCF service request?