Блог

У меня есть WSDL, из которого я сгенерировал реализацию клиентской базы, а именно MyService

 
function void updateData(Data data){
   BasicHttpBinding binding = new BasicHttpBinding();
    // see there is naked username and password.           
   EndpointAddress address = new EndpointAddress("http://qa.farwaha.com/eai_enu/start.swe?SWEExtSource=WebServiceamp;SWEExtCmd=Executeamp;UserName=johnamp;Password=johspassword");
   MyService service = new MyService(binding, address);
   try{
     service.update(data);
   }finally{
     service.close();
   }
}
  

К сожалению, для вызова этого веб-сервиса я должен передать имя пользователя и пароль, как показано в коде. итак, мой вопрос касается лучших практик.

Учитывая, что это приложение Winform.

1. Насколько интенсивно использование памяти / процессора при создании объекта MyService?

2. Если вы предложите обналичить сервис, он сохранит адрес конечной точки; у какого стажера есть строка с именем пользователя и паролем. Что не очень хорошая идея .. есть какие-нибудь обходные пути?

3. Если я сохраню код как таковой, объект service будет собран как мусор .. и не будет никаких следов имени пользователя или пароля (как только GC запустится)

Это пример кода, у меня есть объект User, который хранит пароль в SecureString, и каждый раз, когда мне нужно получить доступ к паролю; я получаю строку из SecureString в частном методе экземпляра, быстро использую ее и оставляю ее для сбора мусора. Я полагаю, что если я использую метод, подобный описанному выше, это будет безопасно или достаточно безопасно, вместо того, чтобы цепляться за ссылку на сервис, что вы предлагаете !!

На ваши конкретные вопросы:

1. В вашем клиентском коде вы создаете экземпляры облегченных прокси-классов, которые оборачивают инфраструктуру канала, которая сериализует сообщения в / из конечных точек сервиса. Как таковые, эти клиентские прокси-классы дешевы и быстры в создании, потому что они обычно мало что делают, пока вы на самом деле не отправите что-либо в службу. Следует остерегаться одной вещи, когда вы вызываете службы, которые используют более сложную схему безопасности — установление соединений с такими службами может быть дорогостоящим, и поэтому стоит кэшировать или повторно использовать такие соединения, если вы можете.
2. «Какие-либо обходные пути»? Нет! Увы, служба, которую вы используете, плохо спроектирована — они не только требуют предоставления имени пользователя и пароля как части вызова метода службы, но и требуют, чтобы вы передавали их в открытом виде по HTTP. Возможно, вы захотите попросить их, по крайней мере, предоставить конечную точку SSL, чтобы имя пользователя и пароль могли быть защищены во время передачи. Что еще лучше, они могли бы реализовать basic-auth, чтобы позволить вам получать файлы cookie HTTP auth, которые вы можете прикреплять к последующим вызовам их сервисов.
3. Да, GC в конечном итоге очистит ваши прокси-экземпляры. Еще лучше, вы могли бы обернуть свои экземпляры в using инструкции, чтобы вызвать шаблон Dispose и выполнить детерминированную очистку. Смотрите мой сервис WCF Magic8Ball на Codeplex для примеров.

Другие наблюдения:

1. Поскольку вашему сервису требуется ваше имя пользователя и пароль, каждый раз, когда вы вызываете его, вам нужно очень тщательно продумать, как вы собираетесь получить и сохранить имя пользователя и пароль.
2. Я бы настоятельно рекомендовал вам указывать информацию о привязке в app.config, а не встроенную в ваш код. Опять же, смотрите Службу WCF Magic8Ball: если вы создаете привязки в коде и конечная точка изменяется или если они открывают новую конечную точку, протокол, кодировку и / или привязку, вам придется перекомпилировать и переделать все ваше приложение. Если вы укажете свои привязки в config, возможно, вам просто удастся отправить обновленное app.config.

Надеюсь, это поможет.