Здравствуйте, дорогие читатели!

Не так давно мы занялись проработкой книги "Writing High-Performance .NET code", которая до сих пор не переведена на русский язык, хотя ей и скоро год.



Нас, конечно, не удивило, что такую книгу уже растаскивают на цитаты, однако выяснилось, что уважаемый автор Бен Уотсон даже выложил на сайте «Codeproject» целую статью, написанную по мотивам одной из глав. К сожалению, объем этого материала слишком велик для хабропубликации, однако мы решили все-таки перевести первую часть статьи, чтобы вы могли оценить материал книги. Приглашаем к прочтению и к участию в опросе. Кроме того, если все-таки целесообразно перевести и вторую часть — пишите в комментариях, постараемся учесть ваши пожелания.

Можно прочитать много книг по базам данных, написать кучу приложений на аутсорс или для себя. Но при этом невозможно не наступить на грабли, при работе с действительно большими базами/таблицами особенно, когда downtime на большом проекте хочется свести к минимуму, а еще лучше совсем избежать. Вот здесь самые простые операции, как например изменение структуры таблицы может стать более сложной задачей. Наиболее интересные случаи, проблемы, грабли и их решения из личного опыта с которыми нам на проекте Pushwoosh пришлось столкнуться описаны под катом. В статье нет красивых картинок, зато есть много сухого текста.

Вчера была опубликована статья, в которой, не без помощи Microsoft, раскрываются интересные подробности о внутренностях BitLocker. Статья длинная и ее содержимое можно резюмировать как «в целом выглядит адекватно, явных уязвимостей вроде не видно». Зато по ссылкам много интересной информации о разных атаках на зашифрованный жесткий диск. Полагаю, хабражителям будет интересно краткое изложение атаки с романтичным названием «evil maid» и ее логическое продолжение. Надежно ли защищена ваша деловая переписка от молодых любопытных таможенников, если в аэропорту солнечной Испании у вас на 10 минут попросили досмотреть ноутбук с зашифрованным жестким диском?

Предлагаю читателям «Хабрахабра» перевод статьи «12 Little-Known CSS Facts (The Sequel)». Она совсем недавно была упомянута в дайджесте интересных материалов из мира веб-разработки и IT.

Update: немного «шлифанул» перевод напильником. Выражаю благодарность всем неравнодушным читателям.
Внимание! Под катом почти 1.5 Мб картинок и много интересных ссылок.

Итак, начнём-с…

1. В свойстве border-radius можно использовать slash-синтаксис.

Об этом уже писалось 4 года назад, но многие новички и даже некоторые опытные разработчики не знают о существовании этой «фишки».

Верите или нет, но следующий код валиден:

.box {
  border-radius: 35px 25px 30px 20px / 35px 25px 15px 30px;
}

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

Пример №1.
Сайт крупнейшего агрегатора платежных методов в России, обслуживает лидера онлайн-игр. После оплаты заказа переадресовывает клиента на урл вида aggregator-domain/ok.php?payment_id=123456, который в свою очередь переадресовывает на сайт онлайн-игры с адресом вида (декодировал для читабельности) online-game-domain/shop/?...amount=32.86...&currency=RUB...&user=user_email@gmail.com...&item_name=1 день премиум аккаунта...
Перебирая значения параметра payment_id, мы можем видеть логины юзеров в онлайн-игре, покупки, которые они совершали, их сумму.

Это история о том, как я соединил 5 Low-severity багов в один большой баг, с помощью которого можно было читать/писать в приватные репы на Гитхабе (опять).

Несколько дней назад гитхаб запустил баунти программу. За 4 часа я смастерил такой URL после посещения которого я получал доступ к вашему гитхаб аккаунту и репозиториям. Хотите узнать как?

Сегодня я расскажу вам историю об уязвимости, которая существовала в одном интернет-банке много лет. Её эксплуатация была настолько элементарной, а опасность была настолько не очевидна, что ни кто так и не обратил на неё внимание.

С этим банком у меня была договорённость о поиске уязвимостей и все мои действия были санкционированными. В тот вечер я уже потратил приличное время на поиск более-менее критичной уязвимости и так не найдя ничего стоящего, было уже отчаялся. Но тут мой взгляд зацепился за один параметр в череде запросов к серверу в момент авторизации. К слову, этот банк использовал передовую и очень надежную технологию авторизации, а именно двухфакторную авторизацию через смс. Так вот, параметр GET запроса, на который я обратил внимание, имел вид: go=/path/to/some/page
и формировался на стороне сервера для дальнейшей переадресации. Но проблемой было то, что путь для переадресации был относительным и добавлялся к домену сайта и поэтому я игнорировал этот запрос в своих предыдущих исследованиях. К тому же, что бы в нем существовала потенциальная уязвимость, должен был иметь место ряд факторов, а именно:
1). возможность при помощи значения параметра go
обеспечить переадресацию на сторонний домен
2). возможность на клиенте задавать значение этого параметра
3). и наконец, после авторизации при редиректе на сторонний домен должна передаться какая нибудь ценная информация

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

Сложилась ситуация, что участвую в проекте, который работает с достаточно большой нагрузкой. Как уже написал — 36 млн запросов в час. Я много чего прочитал и перепробовал за последний месяц, настраивая сервер; хотелось бы просто сжато и компактно выдать тезисно то, что работает хорошо в такой конфигурации.

Первое, что я заметил — множество советов как все настроить под большую нагрузку. Читайте их внимательно, обычно в тексте найдете, что речь про «высокую нагрузку» в 15-20 тысяч клиентов в сутки. У нас клиентов примерно миллион, активных, ежедневных.

У нас нет денег и мы все делаем за свой счет, поэтому экономим. Итог — весь миллион клиентов обслуживается на одном сервере, вот на таком — EX-60 на hetzner.

Часто ли вы задумываетесь – почему что-то сделано так или иначе? Почему у вас микросервисы или монолит, двухзвенка или трехзвенка? Зачем вам многослойная архитектура и сколько у вас вообще слоев? Что такое бизнес-логика, логика приложения, презентационная логика и почему все так разделено? Посмотрите на свое приложение – как оно вообще спроектировано? Что в нем и где находится, почему это сделано именно так?
Потому что так написано в книжках или так говорят авторитетные личности? Какие ВАШИ проблемы решает тот или иной подход/паттерн?
Даже то, что на первый взгляд кажется очевидным, порой бывает очень сложно объяснить. А иногда, в попытке объяснения, приходит понимание того, что очевидные мысли были и вовсе ошибочны.
Давайте попробуем взять какой-нибудь пример и изучить на нем эти вопросы со всех сторон.

Чаще всего deadlock описывают примерно следующим образом:
Процесс 1 блокирует ресурс А.
Процесс 2 блокирует ресурс Б.
Процесс 1 пытается получить доступ к ресурсу Б.
Процесс 2 пытается получить доступ к ресурсу А.
В итоге один из процессов должен быть прерван, чтобы другой мог продолжить выполнение.
Но это простейший вариант взаимной блокировки, в реальности приходится сталкиваться с более сложными случаями. В этой статье мы расскажем с какими взаимными блокировками в MS SQL нам приходилось встречаться и как мы с ними боремся.

Я расскажу о применении различных способов аутентификации для веб-приложений, включая аутентификацию по паролю, по сертификатам, по одноразовым паролям, по ключам доступа и по токенам. Коснусь технологии единого входа (Single Sign-On), рассмотрю различные стандарты и протоколы аутентификации.

Перед тем, как перейти к техническим деталям, давайте немного освежим терминологию.

• Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд.
• Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” — истинный, подлинный).
• Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.

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

Аналогично эти термины применяются в компьютерных системах, где традиционно под идентификацией понимают получение вашей учетной записи (identity) по username или email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.

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

Здравствуйте, меня зовут Дмитрий Карловский и я… много думал. Думал я о том, что не так с XML и почему его в последнее время променяли, на бестолковый JSON. Результатом этих измышлений стал новый стандарт формат данных, который вобрал в себя гибкость XML, простоту JSON и наглядность YAML.

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

Больше — лучше	JSON	XML	YAML	INI	Tree
Человекопонятность	3	1	4	5	5
Удобство редактирования	3	1	4	5	5
Произвольная иерархия	3	3	3	1	5
Простота реализации	3	2	1	5	5
Скорость парсинга/сериализации	3	1	1	5	5
Размер в сериализованном виде	3	1	4	5	5
Поддержка поточной обработки	0	0	5	5	5
Бинарная безопасность	3	0	0	0	5
Распространённость	5	5	3	3	0
Поддержка редакторами	5	5	3	5	1
Поддержка языками программирования	5	5	3	5	1

В сети уже есть довольно немало сравнений Entity Framework и NHibernate, но все они по большей части фокусируются на технической стороне вопроса. В этой статье я бы хотел сравнить эти две технологии с точки зрения Domain Driven Design (DDD). Мы рассмотрим несколько примеров кода и увидим как эти две ORM позволяют нам справляться со сложностями.

Привет хабр!

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

"Пфф, ссылки они и в Африке ссылки, чего тут разбираться?" — скажете вы, тогда я задам вопрос:

Что есть что и куда нас приведет?

• http://example.com
• www.example.com
• //www.example.com
• mailto:user@example.com

Если вы не знаете однозначного ответа или вам просто интересно и если вы не боитесь огромного количества трехбуквенных аббревиатур — милости прошу под кат.

Пролог

Астронавты Олдрин (слева) и Армстронг в Хьюстоне во время тренировки выхода на лунную поверхность (22 апреля 1969 года)

Знаете, кого мне всегда напоминали сторонники теорий заговора? Назойливых шахматистов.

Да-да, бывают такие, которые продолжают ходить королем против вашей ладьи. И вы теряетесь, разинув рот от неожиданности: он что, не читал стандартных эндшпилей и не знает своей судьбы — мат не позднее 16-го хода? Что происходит? Он надеется, что вы забыли, как это делается, что вам станет скучно и вы бросите играть?

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

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

А что же тогда делать? Да все очень просто. Надо замолчать. А затем попросить теоретика заговора рассказать все с начала. Нет-нет, не пересказывать теорию, которая обычно является «сутью произошедшего». А описать. Все. Как было сделано. Подробно. С самого начала.

Давайте так и сделаем на примере лунного заговора, который живуч на фоне миссий LRO, Opportunity, Rosetta и сегодняшних ежедневных снимков все приближающегося Плутона.

Волею судеб в мои руки попал обученный на поисковых запросах Word2Vec. Под катом даны примеры использования с пояснениями.

Мишко Хевери, главный разработчик Ангуляра, как-то упомянул, что приложение гарантированно работает без тормозов, если в нем не более 100 активных областей видимости. Такой подход, в общем, применим к любым приложениям. В играх давно не рендерят то, чего игрок не видит и только в вебе пока еще считается нормой отобразить целиком список из нескольких тысяч элементов. С приходом js-фреймворков ситуация должна измениться и лучшим решением станет удаление из DOM того чего нет на экране, нежели отказ от промежуточных тегов, биндингов и других вещей, облегчающих разработку. Поэтому провел небольшой анализ решений для отображения больших списков. Наткнулся на пару статей:

1. The Infinite Path of Scrolling

В ней парень рассказывает, что проходил стажировку в Гугле в команде Ангуляра и ему поручили исследовать этот вопрос. (Радует, что разработчики заинтересованы этим. Надеюсь, скоро увидим родную поддержку бесконечного скролла).

В этой теме хотелось бы познакомить читателей с относительно новым подходом к контролю доступа под названием Attribute-based access control. Знакомство будет происходить на примере сравнения с популярным нынче Role-based access control.

Вот уже как неделю английская версия the art of command line висит в секции trending на Github. Для себя я нашел этот материал невероятно полезным и решил помочь сообществу его переводом на русский язык. В переводе наверняка есть несколько недоработок, поэтому милости прошу слать пулл-реквесты мне сюда или автору оригинальной работы Joshua Levy вот сюда. (Если PR отправите мне, то я после того, как пересмотрю изменения отправлю их в мастер-бранч Джоша). Отдельное спасибо jtraub за помощь и исправление опечаток.