views:

1672

answers:

6

I have a proxy object generated by Visual Studio (client side) named ServerClient. I am attempting to set ClientCredentials.UserName.UserName/Password before opening up a new connection using this code:

InstanceContext context = new InstanceContext(this);

m_client = new ServerClient(context);
m_client.ClientCredentials.UserName.UserName = "Sample";

As soon as the code hits the UserName line it fails with an "Object is read-only" error. I know this can happen if the connection is already open or faulted, but at this point I haven't called context.Open() yet.

I have configured the Bindings (which uses netTcpBinding) to use Message as it's security mode, and MessageClientCredentialType is set to UserName.

Any ideas?

A: 

I think your problem might be related to the use of the InstanceContext. I thought that was only needed for duplex communication channels from the server side.

I admit I'm not sure about this, but I think in this case you are telling the client to use an existing instance context so it thinks there is already a running service and will not allow changes.

What is driving the use of InstanceContext?

Mike Two
A: 

It appears that you can only access these properties pretty early in the instanciation cycle. If I override the constructor in the proxy class (ServerClient), I'm able to set these properties:

base.ClientCredentials.UserName.UserName = "Sample";

I'm beginning to appreciate the people who suggest not using the automatically built proxies provided by VS.

Paul Mrozowski
A: 

I have similar code that's passing UserName fine:

  FooServiceClient client = new FooServiceClient("BasicHttpBinding_IFooService");
  client.ClientCredentials.UserName.UserName = "user";
  client.ClientCredentials.UserName.Password = "password";

Try creating the proxy with binding name in app.config.

eed3si9n
A: 

here is the colution:

using SysSvcmod = System.ServiceModel.Description;

SysSvcmod.ClientCredentials clientCredentials = new SysSvcmod.ClientCredentials(); clientCredentials.UserName.UserName = "user_name"; clientCredentials.UserName.Password = "pass_word";

m_client.ChannelFactory.Endpoint.Behaviors.RemoveAt(1); m_client.ChannelFactory.Endpoint.Behaviors.Add(clientCredentials);

A: 

If using a duplex client, when you instantiate it the DuplexChannelFactory within the DuplexClientBase that your client is derived from is initialized with existing credentials so it can open the callback channel, which is why the credentials would be read only.

I second Mike's question and also ask why are you using NetTcpBinding if you are not going to use its inherent transport level security? Perhaps an HTTP based binding would be a better fit? That would allow you to use certificate based security which I believe can be modified after instantiation (http://msdn.microsoft.com/en-us/library/ms576164.aspx).

MattK
A: 

A shot in the dark but does netTcpBinding allow username and password validation? Try using application layer (SOAP) security using a http binding

Shane