Какая точность у timestamp в sqlite? Забавный баг с #радиоТ

У АйтиБороды вышел видос, где он рассказывает что будет с контентом и его каналом, а так же выражает и объясняет свою позицию. Имхо, большой респект ему, т.к. реально по пальцам одной руки можно пересчитать публичных блогеров и так называемых "лидеров мнений" из СНГ, которые рискуя своей "долей пирога" - остаются людьми с большой буквы.

В ролике он в том числе упоминал кейс, когда ему писали по поводу рекламы из РФ, он отказывался, а на вопрос "почему" - уже начинало гореть. Отлично понимаю. Вспомнил как 4-ого марта мне написал HR из РФ с дефолтным "привет, не хотел бы [вакансия]?". Я прогуглил человечка и удостоверившись, что их hr-агенство действительно базируется в Питере, ответил, что не хочу иметь дел с HR из РФ.

Собственно, ответ на это письмо на скриншоте. Бывает и так, поэтому старайтесь не делить людей по паспорту. Делите по личным качествам конкретного человека.

🇺🇦❤️

Сколько человек работает в тиктоке? 😜 #радиоТ

Основы Linux (обзор с практическим уклоном)

https://habr.com/ru/post/655275/ - хорошая входная статья в мир Linux.

Рекомендую тем, кто хочет начать разбираться в unix системах, подойдёт даже джунам :) Время чтения ~20 минут

#библиотека_знаний #habr

Aspect Oriented Programming (AOP)

Аспектно ориентированное программирование? WTF!? Мало нам аббревиатур и концепций, подавай больше. На самом деле штука очень крутая и перспективная - расскажу в двух словах на примере C#.

Задача
Есть, допустим, репозиторий. К примеру UserRepository. Со стандартными CRUD операциями. Положить пользователя, вытащить по ID, удалить - ну вот это вот всё. И нужно вот нам собрать метрики - хотим видеть время выполнения каждого похода в субд.

Т.е. метрика, которая будет содержать название метода и время исполнения к примеру.

Как это сделать?

Решение
1) Пойдём от решения "в лоб".

Пишем в начале каждого метода StopWatch.Start, а в конце StopWatch.ElapsedMilliseconds и пушаем метрику.

CreateUser(User user){
StopWatch sw = new StopWatch();
sw.Start();

//поход в базу

sw.Stop();
Metrics.Add('UserRepository.CreateUser',sw.ElapsedMs);
}

и что дальше? Будем нарушать DRY (don't repeat yourself) и вставлять данный кусок ВО ВСЕ МЕТОДЫ? Можно, но ... не можно. Очевидно, что нужно это куда-то выносить. Куда и как?

2) Окей, тут у нас развилочка по решениям. Более топорный способ - создадим базовый класс/хелпер, где сделаем метод-враппер, который будет в себя принимать некий Action (делегат), исполнять его и обернув тем же самым кодом - успокаиваемся. Или нет?

class RepositoryBase : {

CallWithMetric(Action act){
StopWatch sw = new StopWatch();
sw.Start();

act.Invoke();

sw.Stop();
Metrics.Add('UserRepository.CreateUser',sw.ElapsedMs);
}
}

и получается что-то такое :

CreateUser(User user){
CallWithMetric(() => {
//идём в базу
})
}

неплохо, но не сказать, что красиво. коллбековая джаваскриптщина какая-то.

3) Третья стадия уже более generic-like подход и в целом скорее уже ближе к AOP, хотя по факту скорее ООП.

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

Это уже взрослый подход. Но всё еще хочется немного магии.

3) И так. А вот и дошли до AOP. А что если нам создать атрибут, который будет сам оборачивать наш метод в нужный код? Звучит-то клёво, но как? Ведь атрибуты это про метаданные, они не являются декораторами сами по себе.

В C# есть пару классных библиотек. Самые известные это PostSharp и Fody. Они на этапе компиляции могут менять IL код. Это значит, вы можете пометить, допустим специальным атрибутом вам класс/метод и уже после компиляции в него вставится нужный код. В нашем случае - вызов метрик будет выглядеть уже как-то так :

[TimeElapsedMetric]
CreateUser(User user){
       //поход в базу      
}

Удобно. Красиво. Магия!

Но... есть нюансы :) Во-первых, PostSharp, говорят, хорош, но стоит по 700$ per developer. Цена - 🐴. Есть фри версия, но с ограничениями. Не интересно.

Fody же - бесплатный и с открытым кодом. Наш кейс он отлично покрывает (см. MethodTimer), + умеет навешивать "хуки" на методы из коробки. Но и тут есть нюансы. Например, он не позволяет делать re-execute методов, т.е. какой-нибудь Retry Policy уже не навесишь. Так же есть нюансы по работе с async/await - он не везде поддерживается и судя по вкладке Issues на гитхабе - есть баги.

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

Что ж. Штука классная, но ждём развития. Надеюсь, в ближайшие пару лет появится что-то "из-коробки".

Пара общих статей с рефами :
Aspect Oriented Programming (AOP) через исходный код
Теория и практика AOP. Как мы это делаем в Яндексе
Aspect-Oriented Programming : Aspect-Oriented Programming with the RealProxy Class

#csharp #библиотека_знаний #авторское

Виктория Бородина сделала неплохую базовую табличку по иммиграции, довольно интересно глянуть. Тема, конечно, сложная и много нюансов по каждому из пунктов, но в целом - маст си.

Польша улыбнула. Всё в целом закономерно и в двух словах - лучше там, куда сложнее всего уехать. Законы конкуренции они такие.

[20min] : https://www.youtube.com/watch?v=5aexqRQeLNE

#иммиграция

Очередное крутое интервью. Про работу в гугле, пет-проекты ну и в первую очередь личная история.

https://www.youtube.com/watch?v=53nKPT7L0Do

#video

Про goto: помнят многие олды (привет turbo pascal!) , но есть ещё более весёлая штука 😁😁 #радиот

Немного из мира сигналов. Которые по проводам бегают.

Если кто-то увлекается автомобилями и подписан на ютуб канал "ИЛЬДАР АВТО-ПОДБОР", те знают, что у него есть рубрика "оживление мертвеца". Её суть в двух словах : ребята выезжают на сложные "баги" в автомобилях и стараются найти их причину/пофиксать. Вы все понимаете, что более ли менее современный автомобиль состоит из сотен электронных систем/схем/блоков и так далее. И зачастую, по очень разным причинам это всё ломается и сбоит. Особенно со временем.

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

В данном ролике ребята оживляют BMW x5 e53, и используют осцилограф для дебага! Тут же и разъясняют как это всё работает. Оч крутой контент, имхо.

Советую к просмотру :) Таймкод проставлен, длительность просмотра ~5 минут.

https://youtu.be/06cWmc2Zpnk?t=1359

У Dev Jungles вышло очень крутое трёхчасовое видео в стиле "вопрос-ответ" по .net/C#. Имеет смысл смотреть всем дотнетчикам от middle+, много хардовых вопросов.

Было интересно, допустим, почему нельзя делать lock на string и в целом про интернированные строки, и например то, что

string s = "qwe"+"rty"+"uio";

будет на этапе компиляции развёрнуто в string.concat (есть нюансы, не всегда). Или по какой причине нельзя лочиться на структуры. + типичные области применения TCP vs UDP. В общем, много интересных моментов.

Единственное что, заметил, что перепутан ответ на вопрос про "Аутентификацию/Авторизацию/Идентификацию" - первое и второе нужно местами поменять в ответе. Авторизация - роли, Аутентификация - проверка логина/пароля.

Маст си, добавляйте в закладки, редкий контент. Ну и подписывайтесь на автора - хоть канал и молодой, незаслуженно мало подписоты.

#csharp #библиотека_знаний

https://www.youtube.com/watch?v=M32SEu0hY7w

Как бы вы реализовали форму логина и пароля/регистрации на сайте крупного заказчика?

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

Хорош этот вопрос потому что это задание можно сделать как "на коленке", так и "по всем канонам" - зависит от знаний конкретного дева и тз. А так же не привязывается к конкретному языку. Что nodejs, что .net, что PHP - на ответы это не влияет.

Попробуйте потратить минут 5-10 на обдумывание как бы вы ответили на этот вопрос, а после - пункт-за пунктом открывайте чеклист ниже и проверьте себя. Красным флагом 🚩помечены вопросы, на которых можно "засыпаться" и оставить плохое впечатление о себе :)

ps. Составлял сам и не претендую на полноту пунктов, поэтому если что пропустил, пишите в комментах 😉 Идёт по возрастанию сложности/экспертности для реализации. Каждый следующий пункт/уровень должен включать все пункты выше.

Опустим визуальную ui часть, допустим её предоставили. И так ... поехали!

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

Junior level

1) 🚩Нужно ли скрывать вводимый пароль на странице?
Это очевидно, но это и первый пункт! :) У input есть специальный аттрибут password для этого.

2) Должны ли вадидироваться поля для ввода на ui?
Как минимум на то, что поля не пустые - должно. Отправлять пустую формочку на сервер не комильфо, т.к. нагружает сервер почём зря 😉

3) Запрос идёт GET или POST'ом? Правильнее делать POST'ом.
Ничего вам не мешает сделать это любым другим методом, однако принято данные формы слать всегда POST'ом. Как минимум данные не шлются в URL, что может сыграть злую шутку при логировании. Плюс после POST запроса если у вас отвалится интернет соединение - браузер переспросит вас хотите ли вы заново отослать эту форму? - вы наверняка видели такую. Все GET запросы перепосылаются браузерами без подтверждения.

4) Сохраните ли вы в пароль при регистрации "как есть" в текстовом виде?
Если да - это очень плохо и непрофессионально. Пароли должны быть в идеале зашифрованы стойким алгоритмом по ключу, а в идеале хэшированы - без возможности их "восстановить" даже админами. И Base64 тут не подойдёт :) Не говоря уже о том, что если вашу базу сольют - у злоумышленника окажутся все пароли ваших пользователей.

5) Нужно ли проверять вводимые данные не только на UI стороне, но и на сервере? Двойная работа?
Главное правило веб разработчика - не доверяй клиенту (браузеру) - все данные/поля могут быть отосланы или подменены другими средствами, вам нужно обязательно делать полный цикл проверки на сервере.

6) Нужна ли валидация на сложность пароля или можно не париться?
Заставлять пользователя придумать пароль в соответствии с правилами - маст хэв. Но тут важна грань, т.к. знаю реальный пример, когда правила пароля настолько сложные, что пользователи потом хранят эти пароли в текстовых файлах на рабочих столах, т.к. запомнить их нереально. А это еще хуже :) Получается, заботились о безопасности, а по факту родили новый вектор атаки

Middle level

1) Соединение защищено по https?
Если нет, то у меня для вас плохие новости - ваш логин и пароль может быть легко перехвачен между браузером и сервером. Публичными вайфаями, на уровне провайдера или даже на уровне уязвимого роутера, которым вы пользуетесь. Весь сайт в теории может быть по http (лучше бы нет), но форма логина и регистрации - только https. Но даже в таком случае - токен аутентификации сможет быть перехвачен (но не логин и пароль). Весь сайт обязан быть https.

2) 🚩Нужно ли при неудачной попытке регистрации писать, что такой пароль уже существует в системе?
Конечно нет, это может говорить хакеру о том, что пароли хранятся в plain text и уже какой-то пользователь точно существует с таким паролем. Вы должны выдавать МИНИМУМ информации всего, что касается безопасности. Есть шуточная версия в виде сообщения "такой пароль уже используется пользователем %username%". Шутки шутками, но возможно где-то и написали.
На aws к слову максимальный уровень - после ввода логина, сразу же запрашивают пароль И второй фактор, т.е. злоумышленни даже может узнать что именно не подошло.

3) Если попытка входа была неудачная - нужно ли логировать данные формы для дальнейшего изучения проблемы?
Нельзя. Максимум - логин. Пароль - нельзя. Был уже ни один и не два инцидента, когда у крупных сервисов ломали системы логов и вытаскивали пароли, которые логировались в plain text (лог шёл всего реквеста).

4) Если хэшировать пароль, то как? Каким алгоритмом? Хорошо, если мидл назовёт парочку, допустим md5 или sha-1.
Вопрос чем они плохи - уже скорее сеньорский левел. Но для мидла и такой ответ ок. Так же плюсом в карму будет рассказ о том, что хэшировать нужно с солью. SALT - это что-то, что добавляется к паролю чтобы уменьшить риск его обратного преобразования в случае утечки данных. Многие популярные пароли уже находятся в базах (так называемые Rainbow tables и хеши к ним подобраны, поэтому реверснуть какой-нибудь md5 без соли - дело несложное.

Senior level

1) Каким еще способом нужно обезопасить форму? CSRF имеет смысл добавлять?
Это вопрос на самом деле в целом на понимание CSRF вида уязвимости, сеньор должен знать и понимать как это работает. Безусловно, запрос должен быть посылаться с CSRF токеном. Это гарантирует отправку формы тем же клиентом, что её и отобразил.

2) 🚩Что такое 2fa и нужна ли?
Вопрос для сеньора, но мидловский, т.к. 2fa уже прочно вошла в обиход. И будет плохим признаком, если вы ответите wtf. Для серьёзных сервисов - 2fa is a must, даёт серьёзный буст к возможности зайти в вашу учётку даже зная логин и пароль. 2fa - это "второй фактор" = токен - обычно, ваш телефон (апп или смс), но не ограничивается им. Могут быть usb флешки, блютуз девайсы, биометрические сканеры и тп.

3) Храните пароль в базе? Хешированным? Солёным?
Пароль должен быть захеширован, притом важен алгоритм. md5, sha-1 - уже не подходят в текущих реалиях. Используйте bcrypt, PBKDF2 или sha-256. Соль к паролю может быть одна для в всех - не худший вариант. Однако идеально, если соль состоит частично из данных самого пользователя. Плюсом будет, если упомянете о rainbow tables.

4) 🚩Сможете ли сами написать алгоритм для хранения пароля?
Правильный ответ тут - не нужно изобретать криптовелосипеды, если вы не бородатый математик! Слишком просто допустить критическую ошибку в алгоритме и снизить стойкость. Хорошо, если вы сможете привести пример несложного шифрования через XOR, но не более :)

Senior+ level

1) Что делать в случае коллизий паролей при хэшировании?
Избежать этого невозможно, однако шанс стремится к нулю. Но если уж вопрос задан - чем длиннее хэш, тем меньше шанс этой коллизии. Именно md5 и sha-1 не обеспечивают этой длины в сегодняшнем мире. Так же можно упомянуть про двойное хеширование и метод цепочек - внутрянку знать не обязательно, просто знать, что методы есть.

2) Если принято решение шифровать пароль, то какой тип шифрования выберете? Почему?
Вопрос на знание отличий симметричного vs ассиметричного типа. Вы должны понимать разницу. Ответ на самом деле - it depends, зависит от системы взаимодействия. Обычно, используют симметричное, т.к. ассиметричное подразумевает валидацию второй стороной, которой скорее всего не будет. Нужно так же дополнить, что шифрование не замена хэшированию и должно применяться только в крайних случаях в нашем кейсе.

3) В связи с пунктом два - одинаков ли по стойкости 128-битный ключ для симметричного и ассиметричного способа?
Нет, не одинаков. Природа ассиметричного шифрования подразумевает, что ключ должен быть намного длиннее. Эквивалент 128 битного симм. ключа = 2048 ассим. Хорошо бы еще рассказать про плюсы и минусы каждого из подходов.

4) Хорошая ли идея вынести авторизацию на openid?
Безусловно да, если на сайте множество поддоменов и сервисов - это позволит упростить коммуникацию разных бэкендов/сервисов, а так же фрагментирует точки отказа в случае их возникновения - если ляжет авторизация, всё остальное скорее всего будет работать независимо. Т.е. функция не размана по множеству бэкендов. Плюс это более скейлбл решение и добавляет изолированности этой важной функции. Если на авторизацию будет один из векторов атаки - это не затронет остальные компоненты системы. К слову это частая точка для ддоса, т.к. обычно грамотная аутентификация кушает и память и cpu и может легко положить всю систему, если она гвоздями прибита к основной группе сервисов. Хорошо бы еще упомянуть и про oauth 2.0 - это второй по популярности протокол.

5) Rate Limit?
Да, штука отличная. В случае брутфорса или же ддоса - позволит отсекать вредных клиентов и не аффектать "хороших". Все большие ребята следят за этим. Часто авторизацию прячут (как и весь сайт) за cloudflare, который берёт это на себя эту функцию.

Пожалуй, это основные моменты, которые известны мне. Если что-то пропустил или где-то не прав, вэлкам в комменты ;) Всем, кто дочитал - респектушка и похлопывание по плечу ^^ Раскидайте знакомым и проверьте их 😉

и правда кек

#habr

🔐 Что такое SSL/TLS и как он работает? И немного про асимметричное шифрование на пальцах.

Друг тут на днях провёл ликбез и расставил точки над i на эту тему (были определенные чёрные дыры в понимании), за что ему большое спасибо ^^ Делюсь закаточкой с вами.

SSL (secure sockets layer) - это криптографический протокол, обеспечивающий безопасное общение пользователя и сервера по небезопасной сети. Он работает между транспортным уровнем (TCP) и уровнем программы/клиента (http/ftp и тд).

Если на пальцах - TCP это такой "автобус", который везёт ваши данные от вокзала (сервера) до вашего дома (браузер) и назад. И всё бы неплохо, если бы не одно но - все вокруг могут видеть кто и куда едет в автобусе. Зеваки, камеры на дороге, полиция, государственные чины, воры и жулики - любой, кто находится на пути автобуса может просканировать весь автобус. Неприятно, правда же.

SSL - это силовое поле вокруг автобуса, через которое видно только куда "примерно" автобус едет и ... само силовое поле. Извне автобуса непонятно кто едет и едет ли вообще хоть кто-то. Не видно какие инструкции у водителя и к какой именно подстанции он подъедет на самом вокзале. Все мы иногда ездим по подстанциям, которые не хотелось бы афишировать, правда? 😉 Это наше личное дело - касается только нас и вокзала. Всем незнакомым личностям по пути следования знать детали совсем не обязательно. А часто - и опасно. Для нас.

Протокол TLS (transport layer security) основан на протоколе SSL (Secure Sockets Layer) и является его улучшенной версией. От SSL уже почти отказались, но название прижилось, поэтому если вы сегодня слышите SSL - подразумевается скорее всего TLS.

Итак. Как же это работает?

В основе протокола лежат асимметричное шифрование (для аутентификации) и симметричное (для сохранения конфиденциальности). Первый тип шифрования более ресурсоемкий/медленный, поэтому его комбинация с симметричным алгоритмом помогает делать всё красиво быстро.

Симметричное шифрование - это преобразование данных по какому-то алгоритму с одним ключом. Вы показываете ключ при шифровании и его же при расшифровке. Всё. Быстро и надёжно. Главная ценность тут - ключ, т.к. если его знает кто-то другой - он легко сможет так же расшифровать то что вы зашифровали. Логично, не правда ли?

Какая тут проблема в контексте интернета? А проблема в том, что а как передать этот секретный ключ из дома на вокзал чтобы никто по пути не перехватил его? Ответ : Асимметричное шифрование. Именно оно и нужно нам чтобы обменяться ключами между вашим браузером и сервером так, чтобы злоумышленники по пути не перехватили его. Как это сделать? Тут и начинается магия. Магия математики.

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

Круто, не правда ли? Т.е. то, что шифруется публичным ключом - расшифровать может только сервер с приватным. Именно этот публичный ключ и "зашивается" в специальный сертификат сервера, который скачивается при попытке установления соединения вашим браузером.

#security #библиотека_знаний