MCP

воскресенье, 1 ноября 2015 г.

Про продукты Microsoft

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

Например, Visual Studio, одна из лучших IDE, а C#, на мой взгляд — лучший язык программирования (именно в качестве языка), а MSSQL — неплохая база данных, с отличными инструментами. IIS... в принципе, терпимо. Т.е. есть отличный стек для разработки программ, но дальше начинается жесть.

Была придумана придумана клёвая технология LINQ, для работы с базой данных, а потом появился он...  Entity Framework — ужасный и тормозной монстр, который захватил всю работу с базой, и которрый, всё толстеет и толстеет. Я уже запутался в версиях, просто вижу гигабайты места, сожранного им на билд-сервере.

MVC — это был глоток свежего воздуха по сравнению с Web Form'ами, третья версия была вообще отличная, но Microsoft было не остановить, сейчас есть какой-то могучий монстр 5-ой версии, из главных достижений которого — работа с Azure и клёвая интеграция с EF (это я на сайте посмотрел, чтобы выяснить, что же клёвого).

Или взять, например, SignalR, офигеннейшая штука была, я по крайней мере два доклада про него читал. Отличная технология. Но, когда последний раз я его решил взять, я получил 5 сборок с различными компонентами для него, страшного монстра, к которому непонятно с какой стороны было подступиться. На этом, я решил больше не связываться с данной технологией.

Что я хочу сказать, в Microsoft'е могут делать крутые технологии, но потом сами же и превращают их в монстров. Так что от сайтика на две странички начинает тошнить, когда видишь там огромный комбайн под капотом.

И весть этот комбайн должен крутиться на очень дорогом Windows Server, или не менее дорогом и ужасном Azure...

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

А сейчас... сейчас мир изменился. В вебе стало модно SPA и много логики на клиенте. Появился nodejs, просто работающий искаропки, появился nginx, который позволил замаскировать косяки линуксовых приложений через балансировку, появилось куча дешёвых и крутых Linux-хостингов (привет, DigitalOcean!), появился Docker.

И вся круть Microsoft'а уже стала не такой уж и крутью. Microsoft просто в очередной раз задрал цены, и сказал — жрите что дают, не предложив ничего крутого взамен.

И я уже думаю, а зачем оно мне всё? Есть столько всего вкусного. И это будет работать везде, а не только на Windows. Например, knockProxy я изначально хотел написать на C#, но потом передумал и написал на node.

В общем, Microsoft меня задолбала. Они делают клёвые штуки, но сами же втаптывают их в грязь, хотят кучу денег, лезут во все щели, но при всём этом, не делают удобно, не делают быстро, не делают понятно. И меня всё это бесит до зубовного скрежета. Я понятия не имею, что мне дальше делать.


понедельник, 7 сентября 2015 г.

knockProxy

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

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

Прямой доступ

Неплохой вариант, простой для использования, но есть нюансы. Первый, нельзя добраться до машин за NAT'ом, но это можно решить пробросом портов на шлюзе. Второй, более существенный, открывать доступ снаружи даже к одному сервису весьма неприятно в плане безопасности. Неверная настройка сервиса или security issue в нём, и твой компьютер уже как бы не твой. Ну или взять RDP в домене — можно не спеша перебирать логины и пароли всего домена, и если повезёт с одним каким-нить забытым тестовым логином, внутрь уже залезает злоумышленник. Так что этот способ отпадает

VPN

Отличный способ, постоянно использую. Положительных качеств вагон и маленькая тележка: работа с NAT'ом, видна вся сеть, сжатие и шифрование трафика при желании. Но есть один недостаток: сложная настройка. Например, самый простой для системы PPTP не работает на домашнем интернете от Билайна (ибо у них тоже PPTP, а PPTP over PPTP это слишком сложно). А универсальный OpenVPN требует телодвижений по настройки как на клиенте, так и на сервере. Одного логина с паролем не хватит. Так что хотелось бы что-то более простое.

IPSec

Отличная штука, можно загнать в транспортном или туннельном режиме, позволяет делать гарантированно работающие туннели, но чтобы хорошо настроить, надо очень сильно потрудиться. Если по какой-то причине он отказывается работать, то можно долго и упорно тыкать галочки, пока не отживеет. Ну и красивый IPSec без статичных IP, да так, чтобы не завалить всех остальных — сделать не очень легко. В результате, можно потратить много времени на настройку дом-работа, но уже с ноутбуком в поездке работать ничего не будет. Так что этот вариант отложен до лучших времён.

Отдельная программа для связи

Например, что-то типа TeamViewer. Платно и неспортивно.

Свой велосипед

Моё любимое занятие. Ибо точно знаешь что программа умеет, что нет, и какая область применения.
Итак, был написан свой велосипед knockProxy, на node.js, лежит на ГитХабе. Я думал следующим образом: самый удобный вариант, это прямой доступ, но напрямую доступ давать нельзя. Так будем его выдавать после ввода логина и пароля (отдельного, чтобы сузить область возможной атаки). Бонусом, дадим несколько логинов для разных пользователей.

Т.е. всё работает следующим образом: клиент заходит на сайт (браузер у всех ведь есть!), вводит логин и пароль. Для его IP открывается дырка на необходимый компьютер, дырка открывается на пару минут и 5 попыток подключения, так что перебором особо ничего не сделать, даже если пассивно слушать трафик (пароль, естественно не передаю в сыром виде, сплошные солёные хеши).

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

Но, естественно, есть недостатки, например, доступ только на один порт (я предпочитаю RDP), что для полноценной работы не хватает. Зато хватает быстро посмотреть. Второй, более существенный недостаток — соединение по этой дырке по-хорошему должно быть шифрованное. Иначе, где-то в кафе по WiFi могут утечь секурные данные. Но RDP шифруется, правильный VNC тоже, так что для них это не существенно. Обойти данную проблему можно созданием ручного туннеля, но тогда придётся настраивать клиента, что совершенно не подходит в плане удобства (уж лучше честный VPN).

Также, данную штуку можно использовать как хитрый TCP port forwarder, если есть желание, но для этого есть более простые штуки. Что ещё с ней делать, пока не придумал, но в принципе это не важно, главное, чтобы хотя бы одна задача выполнялась на отлично.

Для тулзени выбрал лицензию MIT, для работы нужен node, и какой-нить сервер с мордой наружу (нужен прямой открытый TCP порт). Веб-часть может при необходимости жить через proxy, хотя больше любит напрямую. Работает и под *NIX и под Windows. Наверное и под маком может жить. Так что универсальность полнейшая.

В общем, прошу любить и пользоваться.

суббота, 5 сентября 2015 г.

Microsoft EDGE

Смотрю я на данный браузер и поражаюсь, Microsoft в очередной раз сосредоточилась не пойми на чём, вместо того, чтобы сделать удобный браузер. Вся реклама основана на том, какой он быстрый, хотя в реальности ничего особо быстрого нет, обычный средненький по производительности браузер. При этом, в плане использования всё очень плохо, и видны торчащие ноги из IE.

Собственно по пунктам, банальные вещи, которые видны сразу:
  • Если обратиться к сайту на нестандартный порт, браузер не догадается что он предназначен для http и с упорством дебила пойдёт гуглить, что же ему подсунули. Ну детский сад же... UPD: это исправлено, претензия снимается
  • Восстановление сессий, вроде бы старая и must have фича, по-прежнему работает некорректно. А именно, постоянно восстанавливается куча пустых вкладок. Откуда, блин, он их берёт?
  • При запуске, если система тормозит, то при попытке ввести адрес, добрый браузер сотрёт его, и нарисует вместо него свою домашнюю страницу. Блин, я уже собираюсь уйти куда мне надо, не решай за меня!
Все эти пункты тянутся с IE и до сих пор не пофикшены, хотя в любом другом браузере — работают гораздо лучше. Неужели разработчика браузера запрещено смотреть на другие, не дай бог, сделают что-то удобное.

При этом в Edge оторвали всё хорошее из IE — акселераторы, фрагменты, плагины. Интерфейс теперь стал одним из самых габаритных среди других браузеров (а раньше хвалились, что они экономят место), окна браузера теперь все объединены в один значок, а не делятся на отдельные как в IE...

В общем, в очередной раз, Microsoft решила всё переделать, но начала переделку с копипейста и отрывания функционала. Буду с нетерпением ждать очередной реинкарнации браузера и рассказов о том, насколько теперь он быстрее.

воскресенье, 30 августа 2015 г.

Проблемы REST API или Яндекс тоже лажает

Вчера заметил лажу Яндекса в реализации REST API и решил немного высказаться про идеологов правильного использования REST.

Под данными идеологами я понимаю людей, которые месяцами выбирают HTTP-метод (PUT или PATCH? Сложный выбор!), вылизывают урлы (так, /user/add/group или /group/add/user, или POST /, а остальное данными?), при этом по факту никому их API никогда не нужно, а если и нужно то используется через врапперы и библиотеки.

Красивые урлы и семантика, конечно, важна, но проблема в том, что REST работает через HTTP со своими заморочками и ограничениями. Например, в GET нельзя закидывать body, и надо пытаться засунуть всё в URL, а если не влезает, то сделать POST, получить ID запроса, и сделать GET. Идиотизм. зато семантично.

Или моё любимое: по стандарту GET-ответы кешируются, если не сказано иное (хотя хрому наплевать на это). Звучит разумно, например, мы получаем текущую фазу луны, никаких параметров, она всегда одинаковая, хотя... стоп... Давайте что-нить попроще, например количество входящих сообщений пользователя... блин... Пол пользователя! Во! Главное, чтобы он к врачу не сходил. В общем, если умерить сарказм, то получается, что GET-запросы для API практически никогда не надо кешировать, ибо хоть они и получают данные, но те данные имеют тенденцию меняться в самый непредсказуемый момент.

Решений для убирания кешироания несколько:
  • С сервера посылать запрет кеширования. Работает, но несемантично
  • К каждому запросу подсовывать рандомную строку. Работает, но выглядит ужасно и по факту засираем кеш браузера
  • Переделать API так, чтобы в нём участвовала рандомная строка. Например, дать количество сообщений пользователя на определённую дату. Пофиг, что кроме текущей мы ничего не можем сделать, зато прикрутили параметр
  • Делать POST, а потом GET - очень глупо, медленно, неудобно, но семантично
В общем, вместо того, чтобы тупо сделать всё на POST'ах, мы активно боремся с инфраструктурой. И подобные проблемы периодически возникают то тут, то там. И борьба с ними идёт в основном ради красоты.

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

Собственно, а что с Яндексом? Дело в том, что недавно они написали умную статью, о том как работать с HTTP, типа учитесь как правильно. Ок, поучился. Захожу на internet.yandex.ru и вижу картину следующего вида:
Естественно, со временем всё было в порядке. Просто я обновил данную страницу в браузере, а запрос о времени, сделанный по всем правилам Яндекса по урлу http://yandex.ru/internet/api/v0/datetime/ не имел никаких параметров кеширования. Что привело к тому, что браузер честно отдал ответ, который он запомнил 6 часов назад.
Как видите, Яндекс умеет делать красиво, рассказывать всем как правильно, только выкатывает в итоге нерабочий сервис.

UPD: Увидел ссылку, которая описывает архитектурные проблемы REST чуть в другом ключе, но пересекается с данным постом и я с ней в целом согласен. Также, могу сказать, что в одном из проектов я использовал JSON-pure API, и с ним не было никаких проблем. Данный код до сих пор бродит по разным проектам и не вызывает нареканий.

вторник, 2 июня 2015 г.

Чудесатые интернеты

Решил написать про бредовую ситуацию, с которой я сегодня столкнулся. Связана она была с настройкой виртуалки в Амстердаме у Infobox.

Итак, есть виртуалка, вроде бы всё работает, но при попытке достучаться по самбе, получаю ошибку. Фактически, блокируются 135, 139 и 445-ые порты. Я поплясал с бубном, помучал фаирвол, всё бестолку. В конце-концов, решил проверить доступ с внешней машины. Он был. В полном офигении, я начал копать проблему дальше, и выяснил следующие факты
  1. Любой порт кроме этих трёх работает корректно
  2. Эти три порта работают корректно из любой доступной мне сети (и интернет-утилит), кроме рабочей
  3. Из рабочей сети доступ на данные порты на другие внешние сервисы открыт и работает
  4. Никаких запретов на подобное во внутренней сети нет
Т.е., фактически получается, что или провайдер, или хостер рубят эти три порта, именно для нашей сети или для сети хостера. Совершенно безумная ситуация, которая по идее невозможна, а если возможна, то кто-то ведёт себя очень плохо.

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

Вот так, блин, и работаем.

UPD: Оказалось, что это посредник Инфобокса блокирует часть портов, почему-то считая именно эти "небезопасными". Причём, блокирует только с части сетей. Признались они только после длительной переписки с саппортом.

вторник, 26 мая 2015 г.

Управление виртуалками для обычных пользователей в Hyper-V 2012 R2

Microsoft иногда очень оригинально относится к безопасности. Перекроет все щели так, что прорваться могут только админы. А потом начинает ныть, что же все сидят под админами. Ну, может быть, потому что кто-то ленится подумать про права?

В своё время, Microsoft выпустила сервер виртуализации Hyper-V, весьма неплохой, хоть и со своими тараканами. И там можно было сделать замечательную вещь: выдать пользователю права на виртуалку, которая крутится на сервере. Т.е. он мог её включать, выключать, дёргать у неё сеть, но при этом, он постоянно к ней подключён, и в тоже время не видит соседей.

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

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

Зато, после всех этих мучений, можно было весьма гранулированно раздавать права через AzMan (я, кстати, первый раз его видел, хотя, судя по всему, существовал в системе давно, с XP. Но мы-то знаем, что Microsoft не ищет лёгких путей и всегда есть по крайней мере три несовместимых технологии).

К сожалению, в 2012 R2, эта магия больше не работает. Всё сломано. Мне понадобилось достаточно длительное время, чтобы понять это, т.к. народ умудряется писать статьи о том, что всё таки работает. Не работает. Проверено. С большим скрежетом, я всё-таки нашёл, что можно с этим сделать. А сделать можно только одно: давать пользователю подключаться, к виртуальной машине. Т.е. включить он её не может, но хотя бы может работать с ней. Для того, чтобы как-то добавить права, судя по всему нужна отдельная прослойка, которая со своими жирными правами будет всё делать, уже сам раздавая права. Данной прослойкой может быть System Center Virtual Machine Manager или что-то своё самописное (можно добавить имперсонацию и рулить юзерами, действия тупо выполнять через PowerShell). Но само подключение можно реализовать чуть проще, хотя и не очень очевидно.

Собственно, для возможности подключения пользователя (не админа) к определённой виртуалке надо сделать следующее):

  1. Выдать права на виртуалку через PowerShell
    Grant-VMConnectAccess -ComputerName host_name -VMName vm_name -UserName user_name
    Есть ещё команды Get-VMConnectAccess для просмотра прав и Revoke-VMConnectAccess для отбирания
  2. В PowerShell выяснить id-нужной нам виртуалки
    Get-VM -ComputerName host_name | select id,name
  3. Установить Remote Desktop Connection Manager (стандартный не катит)
  4. В нём сделать новую группу, в группу добавить сервер, на вкладке Server Settings поставить VM Console Connect, ввести нужный Id и сохранить всё это дело


После этого можно пользоваться прямым подключением к виртуалке (возможно придётся открыть ещё порт 2179).

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



четверг, 23 апреля 2015 г.

Ещё одна проблема HttpWebReqest

Я уже писал про грабли HttpWebRequest, но тут нашёл ещё одну забавную, и местами неприятную. Правда наполовину она относится к HttpWebResponse, но классы связаны метровым канатом, так что не принципиально.
Вкратце: работа с куками организована очень оригинально, и не очень логично.

Для удобства распишу по условным пунктам. Для начала диспозиция:
  • Сервер возвращает куки в Http-заголовке Set-Cookie
  • Если надо установить две куки, сервер передаёт два заголовка (не очень логично, но ок)
  • HttpWebResponse имеет пропертю Headers, и по имени заголовка можно получить значение
Тут начинаются проблемы, ибо куки две, а заголовок один. Как вы думаете что вернётся? Не буду томить, скажу, что вернётся в этом методе содержимое двух кук через запятую. Очень, блин удобно. Считаем, что куки у нас разломаны в этом виде.

Но! У Headers можно взять значения через .GetValues(), вернётся честный массив из двух элементов. И вроде бы всё хорошо, и пост можно жакончить, но тут приходит сервер, и выдаёт нам:

Set-Cookie: ABC=123; expires=Fri, 31 Dec 2010 23:59:59 GMT; path=/;


Вы заметили, что между пятницей и 31-ым числом есть запятая? HttpWebResponse тоже заметил, и вместо этой куки честно вернул нам две, обе разломанные. Всё, приехали.

Но обойти это надо, поэтому можно сделать следующие вещи:
  • Вручную распарсить значения кук, зная, что запятая, по стандарту, запрещённый символ. Т.е. встретится она может только в expires
  • Взять у HttpWebResponse пропертю Cookies, с уже обработанными куками
Вроде второй вариант самый правильный и логичный, за исключением случаев, когда вам хочется посмотреть на изначальные данные от сервера, а не обработанные странным кодом. Но чтобы он работал, надо обязательно, у HttpWebReqest установить пропертю CookieContainer, иначе вам вернётся пустой массив в респонзе.

request.CookieContainer = new CookieContainer()

Немного нелогично (нам ведь только ответные нужны), но в принципе допустимо. И всё из-за весьма странной реализации работы с заголовками.

На этом всё, буду ловить очередные грабли данного класса.