Технологии рядом

Зачастую, чтобы освободить свой разум и получить силы двигаться дальше. Необходимо принимать кардинальные решения. Сделать паузу и перестроить жизненную философию. Стадии, во время длительного отпуска (саббатикала): 1. ломка 2. принятие 3. раскрытие творческой личности 4. приоритизация и выбор, того чем действительно хочешь заниматься Полезный и мотивирующий доклад Антона Назарова по теме - "Тебе нужен отпуск. Как перестать жить по накатанной" https://www.youtube.com/watch?v=sJpzMpERa_U

MongoDB — краткий конспект Небольшой краткий конспект по теме. MongoDB — относится к категории NoSQL баз данных. Хранит данные в формате BSON Внутри себя представляет следующую структуру: Server Database — Collection1 — Document1 — Document2 … — Collection2 — Document Пример документа: { "_id": 1, "name": { "first" : "John", "last" : "Backus" }, "contribs": [ "Fortran", "ALGOL", "Backus-Naur Form", "FP" ], "awards": [ { "award": "W.W. McDowell Award", "year": 1967, "by": "IEEE Computer Society" }, { "award": "Draper Prize", "year": 1993, "by": "National Academy of Engineering" } ] } JSON vs BSON Кодировка: JSON использует UTF-8 String, BSON — бинарные данные Типы данных: JSON (String, Boolean, Number, Array, Object, null), BSON (String, Boolean, Number (Integer, Float, Long, Decimal128…), Array, null, Date, BinData) Читабельность: JSON (Понятен человеку), BSON (хранит закодированные данные в бинарном формате) ObjectId — для хранения айди документов, генерится автоматически, вшита временная метка (удобно для сортировки по дате создания) Schema-less — особенность MongoDB. В отличии от реляционной базы (где есть строгая схема данных), в монге в коллекцию можно записать что угодно (любой объект). По-умолчанию ограничений на тип данных нет. На практике, часто все-таки используют схему, чтобы исключить хаос (можно определить строго определенные поля, которые должны быть обязательно). mongosh — утилита для работы в терминале с монгой show dbs — вывод всех баз данных на сервере use shop — переключиться или создать базу данных CRUD: insertOne — вставляет 1 объект в коллекцию insertMany — вставляет массив объектов в коллекцию db.products.insertOne({ name: "Тестовая футболка", type: "Футболка", color: "белый", sizes: ["L", "M"], number: 8, reviews: [{ author: "Roma", text: "Great stuff" }] }) db.products.insertMany([{ name: "Тестовая вещь", type: "Футболка", color: "белый", sizes: ["L"], number: 9, reviews: [{ author: "Roma2", text: "Great stuff" }] }, { name: "Тестовая вещь2", type: "Футболка", color: "белый", sizes: ["L"], number: 123, reviews: [{ author: "Roma2", text: "Great stuff" }] }]) Курсор — указатель на документ, возвращает null — если документа нет. const cur = db.products.find() cur.next() Полезные методы: db.products.find().limit(1) — означает, что мы можем получить только 1 документ db.products.find().skip(1) — означает с какого документа начинать выводить данные db.products.find().sort({number : 1}) — сортирует документы по ключу number от меньшего к большему db.products.find().sort({number : -1}) — сортирует документы по ключу number по убыванию

Cookie Пришло время узнать, как сайты понимают, что я это я и не просят вводить каждый раз логин и пароль при открытии веб-страницы. Например: Открывая сайт vk.com в первый раз, мы вводим логин и пароль. После успешной аутентификации сервер отправлят браузеру файлик со специальными данными (например, ssid сессии) с авторизацией. Cookie - это небольшой фрагмент данных, она хранится на компьютере и автоматически передается браузером при последующих открытиях страницы. У куки есть разные атрибуты и срок жизни. Вот некоторые из них: Secure - атрибут означает, что кука будет отсылается если запрос идет через HTTPS HTTPOnly - позволяет запретить доступ к куки из JS Expire - хранит срок жизни куки Domain - хранит домен, к которому относится кука Path - путь к ресуру, для которого нужна кука

Безопасная работа с паролями Давайте разберемся, а как на стороне бекенда правильно работать с паролями. В первую очередь, нужно: 1. Использовать правильную длину пароля - минимально от 8 символов и больше. Короткие пароли очень легко подбираются. 2. Не хранить пароли в открытом виде в БД - никогда (!), никогда нельзя хранить пароли в открытом виде. Они обязательно должны быть захешированы и лежать в захешированом виде. Если БД попадет в чужие руки, то пароли улетят, а вместе с ними и аккаунты. 3. Пароли хешируются, но не шифруются. В чем разница? Если пароль зашифрован и кто-то "слил" ключ шифрования, то пароли можно будет легко расшифровать. При аутентификации тот пароль, который мы ввели в форму логина, хешируется и мы сравниваем полученный хеш с хешей, который лежит в БД 4. Использовать "соль" - в интеренете существуют специальные таблицы. Их называют "радужные таблицы" - они уже содержат расшифрованный хеш дял самых популярных паролей. Поэтому, если при сохранении хеша к паролю мы будем добавлять "соль", то злоумышленнику будет труднее расшифровать хеш, даже если пользователь использовал популярный пароль вида "12345678"

Уязвимости аутентификации Сейчас, немного расскажу о том, что можно сделать, чтобы "взломать" аутентификацию и какие проблемы могут возникнуть. В первую очередь, это: 1. получение идентификатора - злоумышленник может получить список логинов \ имейлов, которые используются в системе. Как? Если на сайте используются ошибки вида "Логин или имейл не существует" - таким образом можно понять, существует или нет логин в системе. Для защиты лучше использовать ошибки общего характера, вида: "Неверный логин или пароль" - таким образом невозможно понять, существует или нет идентификатор в системе. Credential stuffing - использование одного и того же логина\пароля на различных сервисах. Password Spraying - подбор пароля на основе баз публичных паролей, которые слиты и выложены в открытый доступ на специализированных ресурсах. 2. взлом пароля - здесь, как бы не был совершенен процесс, есть уязвимости. Такие как: - брутфорс (brute force) - подбор пароля методом перебора, который называют "метод грубой силы". Пароли в прямом смысле подбираются, пока не подойдет нужный. Способы защиты? Например, такие: - использование MFA (многофакторной аутентификации) - использовать капчу (после определенного числа попыток неудачного входа) - временно блокировать аккаунт (также после например 5 неудачных попыток входа) - задавать "секретные вопросы" - использовать сервисы вида oAuth (аутентификация через гугл) - блокировать запросы с одного и того же IP

Идентификация vs Аутентификация vs Авторизация Пришло время узнать, какие процессы происходят после того как обычный человек вводит свой логин и пароль, чтобы купить что-то в интернет-магазине. Для начала разберем что такое Идентификация. Идентификация - это процесс, целью которого является определить "идентификатор" пользователя в системе. Здесь можно представить, что при вводе логина, например "vasya_pupkin" - сервер пытается в своей базе найти пользователя с данным логином. Т.е. идентифицировать среди множества других нужного. Идем дальше. А дальше у нас процесс Аутентификации. Аутентификация - это процесс проверки подлинности. В результате которого сервер проверят, что vasya_pupkin и его пароль (хранящийся на сервере) совпадают с тем, что ввел пользователь на форме логина. Как пример, на этом этапе каждый встречал ошибку "Неверный пароль" случайно введя неверные данные. В качестве дополнительной меры защиты, пользователь может включить и пройти дополнительный этап: ввести код из СМС или одноразовый код MFA. Такой процесс называется "Многофакторная аутентификация" или "Двухфакторная аутентификация". Возможно, кто-то встречал такую аббревиатуру: "2FA". Здесь важно понять, что это дополнительный уровень защиты на тот случай, если у злоумышленника появится ваш логин\пароль. (Всем рекомендую использовать и включать там, где это важно или возможно) После прохождения аутентификации происходит процесс авторизации. Авторизация - процесс предоставления доступа пользователю к определенным ресурсам. Во время данного процесса, сервер уже знает, что я - и есть Вася Пупкин, что я ввел правильный логин\пароль. Теперь, сервер должен дать доступ Васе к нужной и доступной только для него информации. Например, доступ к личным сообщениям, фоткам котиков и прочей важной информации, к которой имеет доступ только он. Эти вопросы часто любят спрашивать на собеседованиях у QA да и разработчиков.

А когда HTTPS не нужен? Когда идет соединение клиента и сервера всегда тратятся дополнительные ресурсы на установку соединения и шифрование данных. Только вдумайтесь: 1. Происходит установка соединения 2. Происходит проверка сертификата 3. Выбирается подходящий алгоритм шифрования 4. Происходит непосредственно шифрование \ дешифрование данных Много лишних операций, не так ли? И иногда, когда у нас организована передача данных между своими сервисами (особенно высоконагруженными) внутри изолированного кластера - данным шифрованием можно пренебречь.

Всем привет! Оказывается, это непросто взять и начать что-то писать, делиться своими мыслями и красиво их выражать. Приняв вчера волевое решение начать что-то писать на дзене сразу же впал в ступор. Попробую для начала написать несколько постов про тестирование (самых-самых базовых).

Всем привет. Меня зовут Рома, мне 31 год и я из Минска. Здесь буду делиться своими мыслями об айтишке, QA и многом другом.