100000000 день в году

Завтра, 12 сентября 100000000 (256) день в году. А это значит, что завтра профессиональный праздник всех программистов и системных администраторов, ну в общем, то и всех IT-шников. Поэтому:

Поздравляю всех коллег с профессиональным праздником!!!

Я буду праздновать заранее в клубе Авиатор, где уже традиционно пройдет 256 Party. Уже в 4 раз … J

Число 256 = 2^8 — максимальное число количество чисел, которое можно выразить одним байтом. (Впрочем, любому ИТ-шнику это и так известно).

256 Party — это вечеринка, пропитанная настроением ИТ. В 2007 году мы впервые собрались в нашем городе, чтобы официально отпраздновать этот, тогда еще неофициальный, праздник. Праздник программистов, системных администраторов, тестировщиков — короче, всех специалистов в области информационных технологий.

Posted via email from Комуникликабельность

Поскрипулькины, булки и лоси.

Ребята на КатаемВместе.ru составили отличную классификацию велосипедистов-любителей.

1. Лось. Высшая ступень достижения велосипедиста. Выше только профики, но это уже не любительский ранг.

2. Булка. Довольно хорошая подготовка, рвёт многих.

3. Тесто (я - тесто). Булки делаются из теста. Толком неоформленный велосипедист, подающий надежды.

4. Покатушкины. В общем, тут все остальные велосипедисты, в основном неспешно катающиеся по городу, иногда вне его.

5. Поскрипулькины. Низшая каста велосипедистов, катаются по-малу, за велосипедом не ухаживают (ещё пока не видят нужды), поэтому он издаёт массу жалобных звуков.

На счёт стать лосем за год из теста - это конечно нереально. В лучшем случае можно стать сильной булкой))

Классифицирую себя как покатушкина. А Вы?

Posted via email from Комуникликабельность

Бритва Хэнлона

Бритва Хэнлона:

Никогда не приписывайте злонамеренности тому, что вполне может быть объяснено глупостью.

Never attribute to malice that which can be adequately explained by stupidity

Надо бы попробовать.

Posted via email from Комуникликабельность

.NET 4.0. Кешируем данные в памяти.

Ждете что я начну писать про System.Web.Cache? Вы одновременно правы и не правы.

ASP.NET программисты уже давно пользуются очень удобным средством для кэширования данных, из пространства имен System.Web.Cache. Он самостоятельно управляет жизнью объектов в себе, самостоятельно удаляет элементы из кеша по наступлению событий каких бы то ни было зависимостей, например изменении файла, или таблицы базы данных. Тем, кому стало интересно, отправляю к статье на MSDN.

Осталось только сказать об одном его достаточно большом недостатке – этот кеш нельзя использовать вне ASP.NET, потому что все свои данные он хранит в текущем контексте HttpContext.Current. Если у вас не ASP.NET приложение – этот объект будет недоступен.

Однако, сегодня .NET 4 меня удивил – я наткнулся на другой класс, который предназначен решить эту проблему – System.Runtime.Caching.MemoryCache.

Кроме того, что этот кеш больше не зависит от сборки System.Web, можно создавать несколько экземпляров данного класса. Есть и недостатки – не поддерживаются регионы. Хотя они и есть в базовом классе, однако сам кеш в памяти возвращает null для всех вызовов перегруженных методов с указанием параметра regionName.

В MSDN приведен такой пример использования MemoryCache:

ObjectCache cache = MemoryCache.Default;
string fileContents = cache["filecontents"] as string;

if (fileContents == null)
{
         CacheItemPolicy policy = new CacheItemPolicy();
 
         List<string> filePaths = new List<string>();
         filePaths.Add("c:\\cache\\example.txt");
 
         policy.ChangeMonitors.Add(new
         HostFileChangeMonitor(filePaths));
 
         // Fetch the file contents.fileContents = 
         File.ReadAllText("c:\\cache\\example.txt");
 
         cache.Set("filecontents", fileContents, policy);
}

Судя по этому куску кода, MemoryCache, как и Web.Cache поддерживает различные события на обновления. Например в этом куске кода создается событие на изменение файла. Из коробки доступны мониторы на изменение данных в самом кеше, изменение в файловой системе, изменений на SQL Server.

Очень интересен для рассмотрения также бызовый объект ObjectCache. Он предоставляет базовую логику кеша и представляет возможности для дальнейшего расширения поставщиков кеша. Это означает, что можно писать свой собственный кеш на стандартных интерфейсах и использовать его как стандартный кеш.

Posted via email from Комуникликабельность

WCF. BasicHttpBinding, аутентификация и Streamed режим

Если вы хотите приготовить дрожжевое тесто, а дрожжей у вас нет

… то ни хрена у вас не получится.

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

Исходная задачка была достаточно простой с точки зрения Enterprise приложения: обеспечить для WCF сервиса передачу больших данных с учетом аутентификации.

WCF использует два режима для передачи данных: Buffered и Streamed. Buffered режим соответствует первоначальной сериализации всего пакета данных в память с последующей передачей клиенту. Соответственно передача в Buffered режиме определяет несколько ограничений, как то ограничение на размер передаваемых данных. Buffered режим также не оптимален с точки зрения использования памяти (ну тут все понятно из описания).

Streamed режим предназначен для передачи данных потоком, без занесения всех их в память. Данный режим также накладывает ряд ограничений, но в общем случае это касается контракта данных. Так, тип возвращаемого параметра должен быть Stream или его наследником, тип параметра метода сервиса также должен быть потоком. Данное ограничение можно снять, если использовать контракты сообщений (MessageContracts).

Остальные ограничения Streamed режима можно понять, если учесть одно обстоятельство – ни принимающая, ни отправляющая сторона не знают размер потока. Если учесть этот факт, то понятны ограничении, означенные в статье Large Data and Streaming:

You cannot use a significant number of WCF features when streaming is enabled:

·         Digital signatures for the message body cannot be performed because they require computing a hash over the entire message contents. With streaming, the content is not fully available when the message headers are constructed and sent and, therefore, a digital signature cannot be computed.

·         Encryption depends on digital signatures to verify that the data has been reconstructed correctly.

·         Reliable sessions must buffer sent messages on the client for redelivery if a message gets lost in transfer and must hold messages on the service before handing them to the service implementation to preserve message order in case messages are received out-of-sequence.

Because of these functional constraints, you can use only transport-level security options for streaming and you cannot turn on reliable sessions. Streaming is only available with the following system-defined bindings:

·         BasicHttpBinding

·         NetTcpBinding

·         NetNamedPipeBinding

·         WebHttpBinding

---

Вы не можете использовать некоторое число возможностей WCF при использовании Streaming режима:

·         Невозможно выполнять цифровую подпись сообщения, поскольку она требует вычисления хеша всего содержимого сообщения. При использовании Streaming режима, содержимое пакета не доступно полностью во время сборки и отправки заголовков сообщения, поэтому вычисление цифровой подписи невозможно.

·         Шифрование связано с цифровой подписью для проверки корректности дешифрации данных.

·         Зависимые сессии должны записывать сообщения в буфер на клиенте для повторения сообщения в случае его потери при передаче и должны сохранять сообщения на сервисе перед тем, как передаст его реализации сервиса для поддержания порядка обработки методов, если запросы приходят непоследовательно.

Поскольку накладываются перечисленные ограничения на функционал, вы можете использовать только безопасность на уровне транспорта и не можете включать надежные сессии. Streamed режим поддерживается только в следующих предопределенных биндингах:

·         BasicHttpBinding

·         NetTcpBinding

·         NetNamedPipeBinding

·         WebHttpBinding

От себя также могу добавить, что ко всему этому добавляется невозможность использования поверх Streaming режима аутентификации на транспортном уровне. У меня не получилось добавить такую возможность для basicHttpBinding поскольку клиент при включении опции потоковой передачи при этом страшно ругался.

PS: Попробую еще поковырять WCF, может быть что то выгорит с кастомными биндингами, но я сомневаюсь.

PSPS: У меня на очереди еще статья на тему WCF, а конкретно о некоторой особенности его поведения при хостинге на IIS.

Posted via email from Комуникликабельность

WCF. Расширение OperationContext.

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

WCF предоставляет средства расширения, которые позволяют добавлять свои расширения к некоторым инфраструктурным элементам. Подробнее про расширяемость WCF можно почитать  тут. Расскажу о том, как привязать к OperationContext свой собственный контекст выполнения.

Шаг 1. Реализовываем класс-расширение.

Для реализации класса, который будет хранить наш контекст, необходимо реализовать интерфейс IExtension. Данный интерфейс позволяет расширять возможности некоторых инфраструктурных элементов WCF, например, OperationContext. Реализовать необходимо два метода: Attach и Detach.

1: using System.ServiceModel;

2:

3: namespace ContextExtentionSample

4: {

5: public class ContextExtention : IExtension<OperationContext>

6: {

7: // custom data...

8:

9: #region IExtension<OperationContext> Members

10:

11: public void Attach(OperationContext owner)

12: {

13: // attach to OperationCompleted to destroy context

14: owner.OperationCompleted += new EventHandler(delegate (object sender, EventArgs args)

15: {

16: this.Detach((OperationContext)sender);

17: });

18: }

19:

20: public void Detach(OperationContext owner)

21: {

22: // free context data

23: }

24: #endregion

25: }

26: }

Шаг 2. Реализовываем привязку к OperationContext.

При инициализации вашего контекста необходимо означить контекст для OperationContext.

1:ContextExtention extention;

2:extention = new ContextExtention(user.Id, gropIds);

3:OperationContext.Current.Extensions.Add(extention);

Шаг 3. Использвование контекста.

Получить контекст достаточно просто, для этого необходимо просто обратиться к OperationContext следующим образом:

1:OperationContext.Current.Extensions.Find<ContextExtention >()

В итоге, получится контекст, который можно получить в любом месте выполнения операций сервиса начиная от инициализации этого контекста и заканчивая завершением операции (уничтожением OperationContext).

В следующей статье расскажу как расширять InstanceContext.

Posted via email from Комуникликабельность

WCF. Custom windows autentication

Недавно столкнулся со следующей задачей: сервис должен аутентифицировать Windows пользователя с учетом списка пользователей прикладного приложения, сохраненного в базе. Простого решения не нашел, поскольку точки расшинрения WCF позволяют подвязывать Custom аутентификацию только к аутентификацию по паролю, поэтому появилось такое решение.

Создаем провайдер аутентификации.

public class AutenticationManager : ServiceAuthenticationManager

{

public override ReadOnlyCollection<IAuthorizationPolicy> Authenticate(ReadOnlyCollection<System.IdentityModel.Policy.IAuthorizationPolicy> authPolicy,

Uri listenUri,

ref System.ServiceModel.Channels.Message message)

{

// autenticate base.

ReadOnlyCollection<IAuthorizationPolicy> res = base .Authenticate(authPolicy, listenUri, ref message);

// custom autentication.

User user = DataSession.GetUserByName(ServiceSecurityContext.Current.PrimaryIdentity.Name);

if (user != null )

// return base autentication.

return res;

else

// return none autentication.

return null ;

}

}

 

Затем подвешиваем его при помощи атрибута или конфигурации. С помощью атрибута можно сделать так:

[AttributeUsage(AttributeTargets.Class)]

public class AutenticationBehaviorAttribute : Attribute, IServiceBehavior

{

#region IServiceBehavior Members

public void AddBindingParameters(ServiceDescription serviceDescription,

System.ServiceModel.ServiceHostBase serviceHostBase,

System.Collections.ObjectModel.Collection <ServiceEndpoint> endpoints,

System.ServiceModel.Channels.BindingParameterCollection bindingParameters) { }

 

public void ApplyDispatchBehavior(ServiceDescription serviceDescription, System.ServiceModel.ServiceHostBase serviceHostBase)

{

serviceHostBase.Authentication.ServiceAuthenticationManager = new AutenticationManager();

}

 

public void Validate(ServiceDescription serviceDescription, System.ServiceModel.ServiceHostBase serviceHostBase) { }

#endregion

}

 

При помощи конфигурации не подвешивал, но думаю это достаточно просто (лень искать), да и нескольк небезопасно на мой взгляд, поскольку это всеже проверка аутентификации и подмена конфигарации ее может отрубить, а вот отменить конфигурирование в коде достаточно проблематично для администратора сервиса.

Далее навешиваем этот аттрибут на реализацию сервиса:

[AutenticationBehavior()]

public class DataService : IDataService

{

}

В итоге, если пользователь не аутентифицирован вашим кодом, то на клиент уходит сообщение с ошибкой «The Caller was not authenticated by the service».

Информации о менеджере аутентификации к сожалению достаточно мало и как с ним работать пока непонятно до конца. Например непонятно какой результат должен быть у метода Autenticate, если аутентификация не прошла. В принципе нормально отрабатываются ситуации с ошибками, однако это не очень хороший вариант. А при передаче на выход пустой коллекции пользователь считается аутентифицированным.

Если у кого то есть соображения какие значения должен возвращать менеджер или ктото знает способ проверки Windows пользователей лучше и/или правильней – вэлкам. 

 

Posted via email from Комуникликабельность