centur
–1

Я вас не понимаю, ну статья, стандартный холивар-shit-throwing в коментах, как обычно. К чему тут Элегантные объекты или Егор (комменты читать особо не вижу смысла — много, бестолково да и пользы ноль. Могу угадать результат — никто никого не переубедил, ведь так? )

centur
0

понятно, а в случае если сетка падает\разделяется и восстанавливается — будет 2 Availability кластера да? А по восстановлению они как-то синхронизируются\обмениваются обновившимися данными или это за пределами функционала базы?

centur
0

Комменты не обновлялись. Вопросы 1 и 4 не актуальны.

centur
+1

Есть несколько вопросов —


  1. Вы не упомянули, но на офф сайте написано, что это все in-memory — т.е. выключили машинку — потеряли базу, правильно?
  2. А как ноды общаются и синхронизируются между собой, ну например, у меня 3 VM, на каждом запущено по Apache Ignite — какие порты открывать, какой протокол, как и через что делается node discovery? Или это только для одного сервера ?
  3. Если я добавляю ноду — насколько быстро она получит нужные данные в Replicated режиме? Будет ли она собирать c каждого инстанса по отдельному диапазону или просто с одной из реплик качнет все что нужно?
  4. Я правильно понимаю что для запуска нужен только наггет пакет? т.е. там внутри и jar для базы и обертка на.нет чтобы его стартовать?
centur
0

А вы тут сами себе отвечаете? self-contained token — хорошая оптимизация для good path. Т.е. можно токен при запросах валидировать и проверять без центральной синхронной базы. Это экономит поход за проверкой на каждый запрос пользователя = серьезно экономит ресурсы. Недостаток подхода — что отозвать такой токен тоже непросто. Можно не отзывать вообще и сделать небольшое окно жизни типа 10 минут. Понятно что в автоматическом режиме спама это не спасет, чем дальше уменьшаем окно — тем больше нагрузка за счет увеличения частоты перевыписывания токена. Ищем баланс и проглатываем риски.


Черный список — это та же проверка в базе, ну ее можно оптимизировать по памяти всякими свертками и временем жизни кэша (не имеет смысл держать записи отозваных токенов если текущее время уже после exp токена). Если он асинхронный — у вас та же проблема — спаммер может попасть на сервер с необновившимся списком, если синхронный = каждый отзыв токена вызывает волну обновлений и задержку работы валидного пользователя… И все равно на каждый запрос будете делать сверку с этим blacklist.


Так что эта модель не сильно в принципе отличается от модели хранения в базе — все равно на каждый запрос делаем валидацию + проверку = лишняя нагрузка.


Так что подбираем комфортное окно и проглатываем риски...

centur
0

Добро пожаловать в распределенный мир — не все сервера видят одно и то же состояние. Просто если это все мелко и быстро — пользователь не замечает рассинхронизации, а если масштабно — инвалидация кэша это больно

centur
0

Перечитал тред. "Не совсем так" относилось только к валидности access токена — его можно обновить если пользователь еще активный и у вашего сервиса есть возможность направить пользователя на переавторизацию. Такая авторизация второй раз уже может произойти без всяких consent окошек, т.е. втихую. Или рефреш токеном.


В остальном — все правильно, так и используется.


В период существования только стандарта oauth2 — фишка с offline и refresh_token — была на усмотрение каждого провайдера. C принятием OIDC — это теперь часть стандарта OIDC Core — это ответ на изначальный вопрос — "у всех так или только у гугла".


Про сервер-сервер — лишнее пояснение на самом деле потому что ни один из сценариев протокола не предусматривает полное отсутствие пользователя. Всегда есть пользователь с браузером\клиентом понимающим http, хотя бы в начале протокола, чтобы дать согласие или инициировать первый шаг — перейти по ссылке. Остальные вещи — это просто увлекся описанием...

centur
0

Сервер-сервер сам по себе не случается, должен быть инициатор поведения — пользователь, который говорит — хочу пользоваться ВебсайтомХ (или приложением которое поможет мне с gmail), не хочу регистрироваться, хочу залогиниться с гуглом, но не хочу давать им свой пароль от гугла. Вот из-за этого конфликта в мозгу пользователя и были созданы протоколы — openId1.0, openId2.0 Oauth1.o Oauth2.0, Open Id connect. Первые три умерли, четвертый выжил но его пользовали не по делу — вместо задуманной авторизации делали аутентификацию пользователей (потому что аутентификацию никто адекватно не сделал). В итоге OIDC, который протокол аутентификации был сделан поверх протокола авторизации. И вроде как теперь покрывает обе А-ции.
Описанный у вас сервер сервер — да, второй раз не выдаст, ваше левое почтовое приложение при появлении пользователя скажет ему — не могу логиниться, давай меня заново авторизуй. Что пользователь сам по себе и рад сделать, ибо привык что периодически что-то может отвалиться.


На самом деле чтобы ответить на вопрос — "а зачем такой токен ?" надо понимать протоколы и модель злоумышленника. Т.е. сначала понимаете как можно с помощью современных атак сделать гадость от имени пользователя, если вдруг удастся заполучить его токен, а потом смотрите на протоколы и понимаете — вот такое ограничение в таком режиме — потому что иначе яваскрипт через xss может сделать такую вот каку и чтобы это не случилось — протокол не разрешает какую-то такую фичу...


PS простой момент — протокол не защищает от man in the middle ( это вам к Oauth1 c подписями), он просто снижает риск того что случайный МитМ получит меньше возможностей. Если МитМ постоянный — тут не важно какие токены — он вас поимеет в любом случае.

centur
+1

Это не совсем так — если случился случай 2 — все верно, пользователь обменял, злоумышленник в дураках. Если же злоумышленник адекватный — он обменяет пару сразу, получив монопольный доступ ( потому что у него будет и новый валидный рефреш и валидный аксесс токен). Пользователь же — в лучшем случае будет выкинут из системы (если система при обновлении токена инвалидирует старый аксес токен немедленно), в худшем же (если access_token — self contained и он не инвалидируется а просто истекает) — продолжит пользоваться пока аксесс токеном и спустя время жизни этого токена — будет разлогинен или сервис перестанет работать как надо…


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


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


Не то что бы я против refresh токенов, но надо понимать особенности их использования и связанные с этим риски...

centur
0

Это не так, пользователь уже дал доступ к своим данным "навсегда", единственное что сервису надо делать когда истекает 1час жизни access_token — это организовать запрос по получению access token, — если пользователь залогинен в гугле, и пользователь уже дал свое согласие (consent) — выдача access_token происходит в серии редиректов автоматически. Единственное принципиальное требование — надо чтобы пользовательский браузер был онлайн. Т.е. токен можно обновить только при непосредственном активном участии браузера пользователя ( при этом — почти прозрачно для пользователя т.к. редиректы). В Implicit flow — абсолютно прозрачно через js.


Оффлайн доступ подразумевает что сервис может обновить access token самостоятельно, без вовлечения пользователя в процесс обмена. Что более рисковано потому что если refresh токен утекает — любой знающий токен сможет им воспользоваться для обновления — вся остальная информация о деталях flow и client id — публична.


Это все было очень "гибко" описано в стандарте OAuth2 вот тут 1.5 Refresh Token.


Issuing a refresh token is optional at the discretion of the authorization server.

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


В итоге в OpenID Connect сказали — хватит разврата и "закопали стюардессу" — т.е. добавили более строгое описание в свой стандарт — 11. Offline Access
тут уже и четко прописано какой скоуп запрашивать, как сервер должен себя вести и все такое.


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

centur
+1

топик про Oauth 2.0 не про OpenId Connect

centur
0

https://tools.ietf.org/html/rfc6749#page-10
Спека с вами не согласна. скоупы там просто для того чтобы определить что можно с токеном звать а что нет, offline_access — это вообще чей то частный скоуп, в спеке ни слова про offline.
Вы случайно не путаете чью-то реализацию Oauth 2.0 (Facebook? ) с самим протоколом?

centur
+3

но там есть оговорки, все же абзац весь выглядит так :


The authorization server MAY issue a new refresh token, in which case
the client MUST discard the old refresh token and replace it with the
new refresh token. The authorization server MAY revoke the old
refresh token after issuing a new refresh token to the client. If a
new refresh token is issued, the refresh token scope MUST be
identical to that of the refresh token included by the client in the
request.

А вообще протокол часто используется не по делу =) для аутентификации, а не авторизации (хотя на фоне всех остальных протоколов аутентификации — он прост и понятен...)


Вообще есть куда более простое объяснение — момент аутентификации\авторизации — более уязвим для атакующего чем момент доступа к ресурсам..


Т.е. если Ева перехватила оба токена — то тут все довольно плохо — в зависимости от реализации — она может выдавить легального пользователя Алису. Но такой перехват — сложнее потому что нужно угадать момент.


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


Речь конечно не идет о постоянном MitM на Алису — там никакие схемы и токены не помогут...

centur
+2

Да уж, "хорошая шпаргалка"… Эту шпаргалку писали люди которые с ажуром знакомы только по маркетинговой документации .


Вот прям по пунктам с самого начала — одни косяки


Service Fabric — аналогов особо нету, ближайший это наверное Akka.net и WebJobs от того же ажура, зверек уникальный, и уж точно не Lambda и API Gateway, Azure Functions — это вот есть AWS Lambda


WebApps — только хероку туда попадает


Cloud Services — Это beanstalk, а совсем не EC2, менеджмента машин там нету, все настроено за нас, все развертывание — в портале зип файл с xml загрузил и только смотришь как оно разворачивается...


А вот уже IaaS\ AzureVM — это всеми любимые EC2


TableStorage — чистый noSQL, никакого между там нету, Key-Value Storage


Ну и так далее…

centur
0

Мс ориентируется на рынок и на своих больших ынтерпрайз партнеров, а там мало кто на десктопе сидит на линуксе. А сервера — SQL Server первая ласточка, Service Fabric, да и много всего потянется. В общем не все так категорично и однозначно. А еще полезно иногда выглянуть из echo-chamber и посмотреть на то, что реально происходит, и куда МС движется, а не критиковать с позиций фактов 5летней давности.


И да, такой хинт — многие в МС говорят, что публично компания релизит только то, что внутри обкатывали по несколько лет, теперь давайте пофантазируем о том, что публичный МС — это то что там внутри было три года назад, а то что мы увидим через 3 года — строят сегодня. Так что будущие они — могут быть оочень очень интересными. И главное — не судить на основе фактов о старом МС. МС Балмера и МС Сатьи — 2 разных компании

centur
+6

Самое понятное объяснение что такое .NET Standard я видел у David Fowler вот тут

centur
+1

на электроне? Странные у вас цифры, у мня всего 6 команд залогинено и все эта коммуникационная тттелега тормозит хуже visual studio 2010...

centur
+1

ну почему же виндофилы. Безаппеляционное утверждение что поддержки линукс от МС "конечно же" нет — .NET Core, VSCode, Azure Storage Explorer и другие тулы от МС которые кроссплатформенные и на электроне — конечно же поддерживают этот аргумент.
Остальные претензии что это не уровень слака без банальной скидки на возраст продукта выглядят больше как оскорбления, т.е. вы хотите чтобы все продукты выходили и тут же убивали своей крутизной крупнейших конкурентов на рынке? Так только в сказке бывает..


Что слак мог бы позаимствовать так это например приложения в табах — можно делать кастомный набор интеграций и под себя создавать персонализированную площадку для работы (более доступный пример такого подхода — meetfranz.com — центр персональных коммуникаций), а не делать как слак — принуждать интеграции любить пользователя только "рекомендованным способом".

centur
0

Угол обзора — средний. Ну т.е. не сильно уж узкий, но и не 100%. Сложно описать, представьте вы держите лист формата А4 перед лицом на расстоянии наверное ~20-25 сантиметров — вот какой-то такой. Края активной области — видны, но они не сильно мешают. Их перестаешь замечать когда делаешь что-то — всегда можно немного повернуть голову чтобы объект оказался ровно по центру и тогда с обзором проблем нет. Даже я бы сказал это иногда помогает сосредоточиться — я ради прикола увешал угол комнаты окнами браузера если видеть их все сразу — у меня сильно отвлекается внимание. А с ограниченным углом обзора — повернул голову и оказался в конкретном контексте — одно окно.


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

centur
0

У меня не устают, но это все индивидуально.

centur
+3

Гоняем в офисе периодически. Все-таки девайс не готов к повседневной работе — в офисе свет не выключить а при ярких лампах такого классного погружения нет.
Очень интересно и удобно браузить и смотреть youtube — я бы себе взял подобный девайс для просмотра видео — никому не мешаешь и диагональ телевизора — любая. Rogue One ролик как в кинотеатре смотрится.
Немного тяжеловат, но привыкаешь быстро.


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


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


Я бы сказал так — направление самое правильное — смешивать реальность и цифровой мир, осталось сделать устройство которое будет легче, компактнее и более автономное — нужно хотя бы сутки работы. А пока — очень классная, но все же игрушка, как и остальные гаджеты такого рода. И пока не хватает экосистемы приложений и дополнительных гаджетов. Руками 8 часов в день не намашешься.


И да, зарядный порт надо делать другим — Все-таки немного страшно в девайсе за $5к обломать USB порт, а заряжать приходится довольно регулярно.

centur
+2

Это "объектная" ориентация. Все в этом мире — объект. Потом чешут репу и удивляются обилию аллокаций и GC.
Хотя мне кажется тут автор пропустил один важный компонент — не хватает абстрактной фабрики провайдеров языков. Ну чтобы уж точно добить бедный простой switch-case. А то как-то предложенное решение не до конца "объектно" ориентированно.

centur
+3

Это рекордная для самого сайта krebsonsecurity.com.
Вообще то вот тут есть более интересный твит (похоже что использовали такой же или тот же IoT botnet)


centur
+1

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


Вообще чем больше в интернете Logging as a service, тем больше приходишь к выводу что вот эти ребята предлагают тебе установить свой bottleneck за деньги. Современные логгеры настолько просты и удобны, что added value таких прокси в части scalability стремится к нулю. Хорошо если они еще какую-то аналитику предлагают по вашим логам, но чаще всего оказывается чтобы она работала — надо писать сообщения в service-specific формате ( что приводит к тому что эти фичи не работают при переходе между вендорами). Структурные логи в этом отношении спасают, т.к. хранят не конечный результат, а все исходные данные и могут отдать их в любой sink с сохранением большего количества деталей, чем "просто строка"


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

centur
+1

Хмм, и где вы нашли в моем комментарии что я что-то хочу этим компенсировать? Особенно пресловутое неумение программирования…


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


А я, случайно, младенцев по ночам в вашей интерпретации не ем ??

centur
+18

Отличный способ избавиться от VB на планете!

centur
0

Да, точно, это я смешал со своими размышлениями о потенциальных граблях Орлеанс когда они поверх SF… Мой косяк.


А вы кстати тут упомянуты ? Если нет — отправляйте PR, adoption cases всегда интересны.

centur
0

а, про Tcp теперь понял, у нас наверное похожая ситуация с вебсокетами — стримы просто сказка для этого...

centur
0

Та же самая схема…
Ну учитывая что орлеанс хост жадный до памяти и CPU чтобы работать наиболее эффективно — засовывать все на одну машину все равно не рекомендуется, что в cloud service, что в SF. Сейчас вы это тоже можете сделать захостив Host или клиента в отдельном AppDomain, примеры есть в тестах. Это даст отсутствие раундтрипа по сети только если клиент обращается к зерну в сило на нем самом. А так — будете также общаться по сети между вебролями.
А теперь представьте кейс когда в SF у вас по какой-то причине на одной машине будет 2-3 сило крутиться и драться за CPU — чем это полезно то? Да, фабрика из коробки прикольная, но все же я бы ставил на орлеанс.

centur
0

Ну кстати в сообществе, есть желание сделать глубокую интеграцию с SF, чтобы не было всякого головняка с деплоем и обновлениями. И я знаю что так некоторые делают (и мы тоже возможно соберемся). потому как орлеанс не предоставляет хостинг сам по себе — нужно или в консольке или в вин-сервисе или в клауд сервисе хостить. Там у каждого свой велосипед с обновлениями, кластером и мониторингом здоровья. А СФ именно предлагает полный стек — с хорошей штукой вокруг инфраструктуры и убого скопированной моделью акторов.


Низкоуровневые кейсы это например про описанный сценарий TcpListener. Может я не очень понял для чего такие сложности, хотя видно необходимы без поддержки клиентской подписки. А при наличии стримов — такие коммуникации организовываются очень просто.

centur
+2

Если кому интересно как работает атака, но читать оригинальные 26 страниц — TL;DR — есть неплохая статья на arstechnica.com
Там же есть и ссылки на описания Breach и Crime в стиле научпоп — не глубоко но подробнее чем — "Эээ, у нас проблема, назвали heist, интернет сломан, мы все умрем."

centur
0

А почему не взяли Orleans? Из всего что вы описали выглядит так, что решение принималось — "потому что это Майкрософт", а не исходя из объективных потребностей проекта и удобств фреймворков.
А тут так много описаний низкоуровневых кейсов, т.е. то что фремворк призван решить и спрятать — он выдает наружу и создает сложности программистам. К тому же можно взгромоздить Orleans на SF в Stateless Worker, хотя мы чем дальше — тем более скептически смотрим на это решение. SF выглядит хорошо в плане возможностей devops, но в плане актеров — Orleans ощутимо впереди. В gitter проекта Orleans народ плачет когда их заставляют переходить на SF...

centur
0

Теперь понятно, спасибо. Это печалька что при использовании NLA опять надо быть или доменным пользователем или ходить со старым NTLM

centur
0

Это была вторая линия, первая обычно там мартышки на телефоне, он лазил по логам… Ну или они сильно проапгрейдили саппорт.
Извините но или я не понимаю ваши аргументы или вы не очень четко объясняете, т.к. я все еще не могу понять:
при ВКЛЮЧЕННОМ NLA на сервере в облаке ( не доверенный домен, не локальная сеть, не VPN) почему клиентские настройки NTLM влияют на способность подсоединяться по RDP?


Пока у меня сложилось впечатление что вы утверждаете что настроки NTLM на клиенте НЕ могут влиять на способность ходить по RDP на сервер с NLA. Но тогда ваши утверждения противоречат моей реальности.

centur
0

Ну раз они все такие друг с другом не связанные — почему при выключеном NTLM не пускает на сервер по RDP (сервер не в домене, просто свежая виртуалка в ажуре) пока на сервере включен NLA.
Выключаем NLA на сервере при выключенном NTLM на клиенте — все работает снова, включаем NLA и включаем NTLM — все тоже ок.


Это клево конечно что МС в документации написали что никто ни на что не влияет, но по полученному фидбеку от инженера МС саппорта — они тоже удивились когда мы вместе докопались до реальной причины.

centur
0

А что они делают — вполне понятно. А вот почему такая комбинация приводит к неработоспособным новым RDP ( которые с NLA) — не очень понятно, потому как NTLM это вроде как не очень свежее и очень внутридоменное и локальное, и какого это внутрилокальное влияет на RDP по интернету (куда никакие NTLM вообще ходить не должны ) — не так уж очевидны

centur
0

Если наступили на эти грабли и у вас перестал работать RDP к серверам — вот как вычистить эти эээ "настройки безопасности" через PowerShell ( выполнять под админом):


# these settings are the conflicting configuration on the client
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictReceivingNTLMTraffic"
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictSendingNTLMTraffic"

# Remove these settings to restore NLA support for RDP and working latest RDP to Azure VMs
Remove-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictReceivingNTLMTraffic"
Remove-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictSendingNTLMTraffic"

# Restore these settings to have protection from NTLM hash leak until there will be better ways to prevent the problem
#Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictReceivingNTLMTraffic" -value 2
#Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictSendingNTLMTraffic" -value 2

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictReceivingNTLMTraffic"
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictSendingNTLMTraffic"
centur
0

Ага, отваливается в том числе и Azure VM RDP, причем жестко


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

centur
+1

А можно сделать команды создания образа не скриншотами а текстом, вроде ограничения на количество символов нет.