Разница между типами токенов JWT и PASETO, используемых при аутентификации
(продолжение предыдущего поста)
1. Определение и назначение
- JWT (JSON Web Token) — стандарт для передачи информации между двумя сторонами в формате JSON. Используется для аутентификации и передачи данных о пользователе.
- PASETO (Platform-Agnostic Security Tokens) — современная альтернатива JWT, разработанная для устранения уязвимостей JWT. Ориентирована на обеспечение безопасных по умолчанию настроек и чётких инструкций по реализации.
2. Структура токена
- JWT состоит из трёх частей:
- Header (заголовок) — указывает тип токена («JWT») и алгоритм подписи (например, «HS256»).
- Payload (полезная нагрузка) — содержит утверждения (claims) о пользователе и метаданные (например,
- Signature (подпись) — обеспечивает целостность токена с помощью секретного ключа.
- PASETO имеет следующую структуру:
- Version (версия) — V1 или V2.
- Purpose (назначение) — локальный (local) или публичный (public) токен.
- Payload (полезная нагрузка) — может быть зашифрованной или в виде открытого текста.
- Footer (опционально) — содержит аутентифицированные метаданные для контекста.
3. Типы токенов
- JWT не разделяет токены по типам — все JWT подписываются и могут быть проверены с использованием одного и того же механизма.
- PASETO предлагает два типа токенов:
- Public Token (подписанный) — для безгосударственных систем, использует криптографию с открытым ключом.
- Local Token (зашифрованный) — для серверных сессий с состоянием, использует симметричное шифрование.
4. Механизмы безопасности
- JWT:
- безопасность зависит от реализации разработчиком (нет «безопасных по умолчанию» настроек);
- уязвимости: путаница с алгоритмами, управление ключами, отсутствие встроенных механизмов отзыва токенов;
- проверка подписи выполняется с использованием общего секретного ключа.
- PASETO:
- «безопасные по умолчанию» настройки — предотвращают путаницу с алгоритмами и обеспечивают надёжные криптографические практики;
- криптографические алгоритмы фиксированы и зависят от версии токена;
- для локальных токенов используется симметричное шифрование, для публичных — асимметричное (с открытым ключом).
5. Механизмы отзыва токенов
- JWT: отзыв токенов сложен без внешних механизмов (например, чёрных списков, привязки токенов или специальных сервисов отзыва).
- PASETO: отзыв локальных токенов упрощён, так как сервер поддерживает состояние токенов.
6. Гибкость и сложность реализации
- JWT:
- высокая гибкость — подходит для различных архитектур;
- простая реализация, но подвержена неправильной настройке.
- PASETO:
- чётко определённые сценарии использования (локальные/публичные токены);
- чуть более сложная реализация, но обеспечивает большую безопасность.
7. Поддержка экосистемы
- JWT: широко распространён, имеет обширную библиотеку инструментов и поддержку.
- PASETO: поддержка растёт, но пока менее зрелая по сравнению с JWT.
8. Сценарии использования
- JWT подходит, если:
- нужна широкая поддержка библиотек;
- разработчики знакомы с нюансами JWT;
- безопасность не является приоритетом или есть возможность инвестировать в правильную реализацию.
- PASETO предпочтительнее, если:
- безопасность — главный приоритет;
- нужны чёткие указания по криптографическим практикам;
- необходимо избежать уязвимостей, связанных с путаницей алгоритмов.
(продолжение предыдущего поста)
1. Определение и назначение
- JWT (JSON Web Token) — стандарт для передачи информации между двумя сторонами в формате JSON. Используется для аутентификации и передачи данных о пользователе.
- PASETO (Platform-Agnostic Security Tokens) — современная альтернатива JWT, разработанная для устранения уязвимостей JWT. Ориентирована на обеспечение безопасных по умолчанию настроек и чётких инструкций по реализации.
2. Структура токена
- JWT состоит из трёх частей:
- Header (заголовок) — указывает тип токена («JWT») и алгоритм подписи (например, «HS256»).
- Payload (полезная нагрузка) — содержит утверждения (claims) о пользователе и метаданные (например,
userid, email, exp — время истечения).- Signature (подпись) — обеспечивает целостность токена с помощью секретного ключа.
- PASETO имеет следующую структуру:
- Version (версия) — V1 или V2.
- Purpose (назначение) — локальный (local) или публичный (public) токен.
- Payload (полезная нагрузка) — может быть зашифрованной или в виде открытого текста.
- Footer (опционально) — содержит аутентифицированные метаданные для контекста.
3. Типы токенов
- JWT не разделяет токены по типам — все JWT подписываются и могут быть проверены с использованием одного и того же механизма.
- PASETO предлагает два типа токенов:
- Public Token (подписанный) — для безгосударственных систем, использует криптографию с открытым ключом.
- Local Token (зашифрованный) — для серверных сессий с состоянием, использует симметричное шифрование.
4. Механизмы безопасности
- JWT:
- безопасность зависит от реализации разработчиком (нет «безопасных по умолчанию» настроек);
- уязвимости: путаница с алгоритмами, управление ключами, отсутствие встроенных механизмов отзыва токенов;
- проверка подписи выполняется с использованием общего секретного ключа.
- PASETO:
- «безопасные по умолчанию» настройки — предотвращают путаницу с алгоритмами и обеспечивают надёжные криптографические практики;
- криптографические алгоритмы фиксированы и зависят от версии токена;
- для локальных токенов используется симметричное шифрование, для публичных — асимметричное (с открытым ключом).
5. Механизмы отзыва токенов
- JWT: отзыв токенов сложен без внешних механизмов (например, чёрных списков, привязки токенов или специальных сервисов отзыва).
- PASETO: отзыв локальных токенов упрощён, так как сервер поддерживает состояние токенов.
6. Гибкость и сложность реализации
- JWT:
- высокая гибкость — подходит для различных архитектур;
- простая реализация, но подвержена неправильной настройке.
- PASETO:
- чётко определённые сценарии использования (локальные/публичные токены);
- чуть более сложная реализация, но обеспечивает большую безопасность.
7. Поддержка экосистемы
- JWT: широко распространён, имеет обширную библиотеку инструментов и поддержку.
- PASETO: поддержка растёт, но пока менее зрелая по сравнению с JWT.
8. Сценарии использования
- JWT подходит, если:
- нужна широкая поддержка библиотек;
- разработчики знакомы с нюансами JWT;
- безопасность не является приоритетом или есть возможность инвестировать в правильную реализацию.
- PASETO предпочтительнее, если:
- безопасность — главный приоритет;
- нужны чёткие указания по криптографическим практикам;
- необходимо избежать уязвимостей, связанных с путаницей алгоритмов.
Telegram
METANIT.COM
Разница между типами токенов JWT и PASETO, используемых при аутентификации
(продолжение в следующем посте)
(продолжение в следующем посте)
❤5👍3👀2👏1
McKinsey Global Institute опубликовал доклад, в котором озвучено, что уже сегодня ИИ-агенты и роботы могли бы автоматизировать до 57% всех рабочих часов в США, если компании радикально перестроят процессы. По расчетам аналитиков, под ударом в таком сценарии оказывается около 40% рабочих мест. При этом примерно треть нынешних профессий в США McKinsey относит к труднозаменимым: там критичны физическое присутствие, эмпатия, гибкое мышление и работа в непредсказуемой среде, а главным барьером масштабной автоматизации становятся не технологии, а политика, инвестиции и готовность бизнеса полностью переформатировать рабочие процессы.
Наибольший риск, по оценке исследователей, несут роли, где много формализуемой работы с информацией: подготовка документов, обработка данных, делопроизводство и "шаблонное" рассуждение. В докладе и сопутствующих материалах отдельно упоминаются юристы начального уровня, административный и офисный персонал, часть программистов — именно там McKinsey уже фиксирует замедление найма на фоне активного внедрения ИИ-инструментов. Вторая большая зона риска — физический труд на складах, в логистике и при работе с оборудованием: все, что можно описать как повторяемые операции в контролируемой среде, относительно легко отдать робототехнике.
Зато медсестры, сиделки, персонал по уходу, учителя, а также специалисты по обслуживанию и ремонту выглядят гораздо устойчивее. В таких профессиях значительная доля задач требует (не всегда сразу) физического труда, развитой моторики, эмпатии, наблюдательности и контекстного мышления — то, что современные системы имитируют хуже всего.
https://www.mckinsey.com/mgi/our-research/agents-robots-and-us-skill-partnerships-in-the-age-of-ai
Наибольший риск, по оценке исследователей, несут роли, где много формализуемой работы с информацией: подготовка документов, обработка данных, делопроизводство и "шаблонное" рассуждение. В докладе и сопутствующих материалах отдельно упоминаются юристы начального уровня, административный и офисный персонал, часть программистов — именно там McKinsey уже фиксирует замедление найма на фоне активного внедрения ИИ-инструментов. Вторая большая зона риска — физический труд на складах, в логистике и при работе с оборудованием: все, что можно описать как повторяемые операции в контролируемой среде, относительно легко отдать робототехнике.
Зато медсестры, сиделки, персонал по уходу, учителя, а также специалисты по обслуживанию и ремонту выглядят гораздо устойчивее. В таких профессиях значительная доля задач требует (не всегда сразу) физического труда, развитой моторики, эмпатии, наблюдательности и контекстного мышления — то, что современные системы имитируют хуже всего.
https://www.mckinsey.com/mgi/our-research/agents-robots-and-us-skill-partnerships-in-the-age-of-ai
McKinsey & Company
Agents, robots, and us: Skill partnerships in the age of AI
Learn how AI is transforming work, focusing on the collaboration between humans, agents, and robots.
🥱6🤯3🤬2💩2🌚2
Работа балансировщика нагрузки
(продолжение предыдущего поста)
Балансировщик нагрузки - один из неотъемлимых компонентов высоконагруженного приложения. Он обеспечивает:
* Распределение нагрузки между серверами для предотвращения перегрузки.
* Высокую доступность за счёт исключения неработающих серверов из обработки запросов.
* Гибкость в маршрутизации запросов (разные пути направляются к разным группам серверов).
* Улучшение пользовательского опыта за счёт быстрого и надёжного обслуживания запросов.
Рассмотрим, как работает балансировщик нагрузки
1. Приём запросов от клиентов (Listener)
Процесс начинается с того, что клиенты (устройства, подключённые к интернету) отправляют запросы на балансировщик нагрузки. Запросы поступают на Listener (прослушиватель), который настроен на определённый порт и протокол (например, HTTP:80). Listener служит «точкой входа» для входящих запросов.
2. Маршрутизация запросов (Routing Rules & Policies)
После приёма запроса балансировщик определяет, куда его направить, используя правила маршрутизации (Routing Rules). Эти правила основаны на различных параметрах:
* путь (Path) в URL (например,
* хост (Host);
* заголовки (Header) HTTP-запроса.
На изображении показаны два основных правила:
* Rule 1: /api/\*** — направляет запросы, начинающиеся с `/api/`, в **Target Group 1 (API Servers).
* Rule 2: /images/\*** — направляет запросы, начинающиеся с `/images/`, в **Target Group 2 (Image Servers).
3. Распределение нагрузки по целевым группам (Target Groups)
Целевые группы (Target Groups) — это наборы серверов или ресурсов, которые обрабатывают запросы. На изображении есть две целевые группы:
* Target Group 1: API Servers — включает EC2 Instance A, EC2 Instance B и Container C. Обрабатывает API-запросы.
* Target Group 2: Image Servers — включает S3 Bucket и EC2 Instance D. Обрабатывает запросы к изображениям.
Когда запрос соответствует определённому правилу маршрутизации, он перенаправляется в соответствующую целевую группу.
4. Выбор конкретного сервера (алгоритмы балансировки)
Внутри целевой группы балансировщик выбирает конкретный сервер для обработки запроса, используя алгоритмы балансировки нагрузки. Пример алгоритма — Round Robin (циклическое распределение запросов между серверами).
Например, если клиент отправил запрос
1. Listener принимает запрос на порту 80.
2. Routing Rule определяет, что путь
3. Запрос перенаправляется в Target Group 1 (API Servers).
4. Балансировщик выбирает, например, EC2 Instance A для обработки запроса (на основе алгоритма Round Robin).
5. EC2 Instance A обрабатывает запрос и возвращает ответ клиенту.
5. Политики (Policies) для повышения надёжности и удобства
Для эффективной работы балансировщика используются политики (Policies):
* Health Checks (проверки работоспособности) — балансировщик регулярно проверяет состояние серверов в целевых группах (например, каждые 30 секунд, Threshold: 2). Если сервер не проходит проверку, он временно исключается из обработки запросов.
* Sticky Sessions (прилипающие сессии) — политика, которая привязывает клиента к одному серверу на время сессии. Это полезно для приложений, где важна непрерывность взаимодействия (например, корзины покупок). На изображении эта политика включена для Target Group 2.
6. Обработка различных типов ресурсов
Балансировщик нагрузки может работать не только с EC2-инстансами, но и с другими ресурсами:
* EC2 Instance — виртуальные машины в облаке.
* Container — контейнеры (например, Docker), которые могут быстро масштабироваться.
* S3 Bucket — хранилище объектов (например, для статических файлов, изображений).
(продолжение предыдущего поста)
Балансировщик нагрузки - один из неотъемлимых компонентов высоконагруженного приложения. Он обеспечивает:
* Распределение нагрузки между серверами для предотвращения перегрузки.
* Высокую доступность за счёт исключения неработающих серверов из обработки запросов.
* Гибкость в маршрутизации запросов (разные пути направляются к разным группам серверов).
* Улучшение пользовательского опыта за счёт быстрого и надёжного обслуживания запросов.
Рассмотрим, как работает балансировщик нагрузки
1. Приём запросов от клиентов (Listener)
Процесс начинается с того, что клиенты (устройства, подключённые к интернету) отправляют запросы на балансировщик нагрузки. Запросы поступают на Listener (прослушиватель), который настроен на определённый порт и протокол (например, HTTP:80). Listener служит «точкой входа» для входящих запросов.
2. Маршрутизация запросов (Routing Rules & Policies)
После приёма запроса балансировщик определяет, куда его направить, используя правила маршрутизации (Routing Rules). Эти правила основаны на различных параметрах:
* путь (Path) в URL (например,
/api/* или /images/*);* хост (Host);
* заголовки (Header) HTTP-запроса.
На изображении показаны два основных правила:
* Rule 1: /api/\*** — направляет запросы, начинающиеся с `/api/`, в **Target Group 1 (API Servers).
* Rule 2: /images/\*** — направляет запросы, начинающиеся с `/images/`, в **Target Group 2 (Image Servers).
3. Распределение нагрузки по целевым группам (Target Groups)
Целевые группы (Target Groups) — это наборы серверов или ресурсов, которые обрабатывают запросы. На изображении есть две целевые группы:
* Target Group 1: API Servers — включает EC2 Instance A, EC2 Instance B и Container C. Обрабатывает API-запросы.
* Target Group 2: Image Servers — включает S3 Bucket и EC2 Instance D. Обрабатывает запросы к изображениям.
Когда запрос соответствует определённому правилу маршрутизации, он перенаправляется в соответствующую целевую группу.
4. Выбор конкретного сервера (алгоритмы балансировки)
Внутри целевой группы балансировщик выбирает конкретный сервер для обработки запроса, используя алгоритмы балансировки нагрузки. Пример алгоритма — Round Robin (циклическое распределение запросов между серверами).
Например, если клиент отправил запрос
GET /api/users, процесс будет следующим:1. Listener принимает запрос на порту 80.
2. Routing Rule определяет, что путь
/api/users соответствует правилу /api/*.3. Запрос перенаправляется в Target Group 1 (API Servers).
4. Балансировщик выбирает, например, EC2 Instance A для обработки запроса (на основе алгоритма Round Robin).
5. EC2 Instance A обрабатывает запрос и возвращает ответ клиенту.
5. Политики (Policies) для повышения надёжности и удобства
Для эффективной работы балансировщика используются политики (Policies):
* Health Checks (проверки работоспособности) — балансировщик регулярно проверяет состояние серверов в целевых группах (например, каждые 30 секунд, Threshold: 2). Если сервер не проходит проверку, он временно исключается из обработки запросов.
* Sticky Sessions (прилипающие сессии) — политика, которая привязывает клиента к одному серверу на время сессии. Это полезно для приложений, где важна непрерывность взаимодействия (например, корзины покупок). На изображении эта политика включена для Target Group 2.
6. Обработка различных типов ресурсов
Балансировщик нагрузки может работать не только с EC2-инстансами, но и с другими ресурсами:
* EC2 Instance — виртуальные машины в облаке.
* Container — контейнеры (например, Docker), которые могут быстро масштабироваться.
* S3 Bucket — хранилище объектов (например, для статических файлов, изображений).
Telegram
METANIT.COM
Работа балансировщика нагрузки
(описание в следующем посте)
(описание в следующем посте)
❤6👍5💯2
Microsoft представляет будущее, в котором ИИ управляет всем на компьютере. Более того, компания сама активно внедряет ИИ в производственные процессы: ранее в этом году генеральный директор Microsoft Сатья Наделла заявил, что до 30% кода "некоторых проектов" написано ИИ. Однако сами сотрудники Microsoft относятся к внедрению ИИ не столь однозначно.
Некоторые сотрудники, пожелавшие остаться анонимными, считают, что руководители Microsoft недовольны тем, как часто разработчики используют ИИ в настоящее время. Внутри компании существует стремление к тому, чтобы разработчики в первую очередь использовали ИИ для всего, но внедрение не всегда происходит естественным образом.
Microsoft заявляет, что 91% её команд разработчиков используют GitHub Copilot, но источники поделились данными, которые свидетельствуют о том, что в некоторых подразделениях компании общий уровень внедрения инструментов ИИ гораздо ниже — ближе к 51% разработчиков, которые сообщили Stack Overflow, что теперь профессионально используют инструменты ИИ каждый день.
Некоторые сотрудники признались, что скептически относятся к идее того, что агенты ИИ смогут полностью заменить работу людей, оставив разработчикам исправлять ошибки автоматизированных агентов.
Один источник в Microsoft рассказал, что некоторые инструменты не так хороши, как их представляют. "ES Chat экономит мне время, потому что я им не пользуюсь", — пошутил собеседник.
Агрессивное продвижение Microsoft в отношении написания ИИ-агентов для разработчиков также вызывает беспокойство у некоторых сотрудников компании. Так, инженеры подразделения CoreAI компании Microsoft обеспокоены использованием автономных ИИ-агентов, особенно в связи с тем, что им приходится брать на себя те проекты, которые могли бы быть поручены младшим разработчикам. В отрасли, и внутри самой Microsoft, существуют серьёзные опасения, что роли младших разработчиков исчезают, и опытным разработчикам приходится нянчиться с результатами работы инструментов ИИ.
https://www.theverge.com/tech/831379/microsoft-developer-ai-usage-stats-notepad
Некоторые сотрудники, пожелавшие остаться анонимными, считают, что руководители Microsoft недовольны тем, как часто разработчики используют ИИ в настоящее время. Внутри компании существует стремление к тому, чтобы разработчики в первую очередь использовали ИИ для всего, но внедрение не всегда происходит естественным образом.
Microsoft заявляет, что 91% её команд разработчиков используют GitHub Copilot, но источники поделились данными, которые свидетельствуют о том, что в некоторых подразделениях компании общий уровень внедрения инструментов ИИ гораздо ниже — ближе к 51% разработчиков, которые сообщили Stack Overflow, что теперь профессионально используют инструменты ИИ каждый день.
Некоторые сотрудники признались, что скептически относятся к идее того, что агенты ИИ смогут полностью заменить работу людей, оставив разработчикам исправлять ошибки автоматизированных агентов.
Один источник в Microsoft рассказал, что некоторые инструменты не так хороши, как их представляют. "ES Chat экономит мне время, потому что я им не пользуюсь", — пошутил собеседник.
Агрессивное продвижение Microsoft в отношении написания ИИ-агентов для разработчиков также вызывает беспокойство у некоторых сотрудников компании. Так, инженеры подразделения CoreAI компании Microsoft обеспокоены использованием автономных ИИ-агентов, особенно в связи с тем, что им приходится брать на себя те проекты, которые могли бы быть поручены младшим разработчикам. В отрасли, и внутри самой Microsoft, существуют серьёзные опасения, что роли младших разработчиков исчезают, и опытным разработчикам приходится нянчиться с результатами работы инструментов ИИ.
https://www.theverge.com/tech/831379/microsoft-developer-ai-usage-stats-notepad
The Verge
How Microsoft’s developers are using AI
AI might not be transforming every job yet, but it’s having a big impact on developers.
🖕20🤮5🤡4🤔3💩2💯2👍1😭1
Сетевые протоколы, которые работают на разных уровнях сетевой модели OSI
(описание в следующем посте)
(описание в следующем посте)
❤7👍3👏1🤣1
Вкратце об уровнях сетевой модели OSI
(продолжение предыдущего поста)
🔌 Уровень 1 — Физический (Physical)
Передаёт необработанные биты по физическим каналам связи.
Протоколы: 10BASE‑T, DSL, ISDN, USB, RS‑232, SONET/SDH.
Устройства: кабели, концентраторы (hubs), повторители (repeaters).
🔗 Уровень 2 — Канальный (Data Link)
Обеспечивает передачу данных между узлами, MAC‑адресацию и формирование кадров.
Протоколы: Ethernet, PPP, STP, VLAN, LLDP.
Устройства: коммутаторы (switches), мосты (bridges).
🗺 Уровень 3 — Сетевой (Network)
Отвечает за маршрутизацию и логическую адресацию.
Протоколы: IPv4/IPv6, OSPF, EIGRP, RIP, MPLS, ICMP, NAT.
Устройства: маршрутизаторы (routers), коммутаторы L3 (L3 switches).
⚙️ Уровень 4 — Транспортный (Transport)
Гарантирует надёжную сквозную передачу данных.
Протоколы: TCP, UDP, SCTP, DCCP.
Ключевые элементы: порты, сегментация, управление потоком (flow control).
📊 Уровень 5 — Сеансовый (Session)
Устанавливает, поддерживает и завершает сеансы связи.
Протоколы: SIP, SMB, RPC, PPTP, TLS.
Ключевые элементы: аутентификация, управление сеансами.
🎛 Уровень 6 — Представительный (Presentation)
Форматирует и преобразует данные для приложений.
Функции: шифрование, сжатие, кодирование данных.
Примеры: шифрование SSL/TLS, JPEG, MP3, ASCII, JSON.
🎨 Уровень 7 — Прикладной (Application)
Предоставляет сервисы непосредственно пользовательским приложениям.
Протоколы: HTTP/S, DNS, DHCP, SSH, SMTP, FTP, SNMP.
Примеры использования: просмотр веб‑страниц, электронная почта, передача файлов.
(продолжение предыдущего поста)
🔌 Уровень 1 — Физический (Physical)
Передаёт необработанные биты по физическим каналам связи.
Протоколы: 10BASE‑T, DSL, ISDN, USB, RS‑232, SONET/SDH.
Устройства: кабели, концентраторы (hubs), повторители (repeaters).
🔗 Уровень 2 — Канальный (Data Link)
Обеспечивает передачу данных между узлами, MAC‑адресацию и формирование кадров.
Протоколы: Ethernet, PPP, STP, VLAN, LLDP.
Устройства: коммутаторы (switches), мосты (bridges).
🗺 Уровень 3 — Сетевой (Network)
Отвечает за маршрутизацию и логическую адресацию.
Протоколы: IPv4/IPv6, OSPF, EIGRP, RIP, MPLS, ICMP, NAT.
Устройства: маршрутизаторы (routers), коммутаторы L3 (L3 switches).
⚙️ Уровень 4 — Транспортный (Transport)
Гарантирует надёжную сквозную передачу данных.
Протоколы: TCP, UDP, SCTP, DCCP.
Ключевые элементы: порты, сегментация, управление потоком (flow control).
📊 Уровень 5 — Сеансовый (Session)
Устанавливает, поддерживает и завершает сеансы связи.
Протоколы: SIP, SMB, RPC, PPTP, TLS.
Ключевые элементы: аутентификация, управление сеансами.
🎛 Уровень 6 — Представительный (Presentation)
Форматирует и преобразует данные для приложений.
Функции: шифрование, сжатие, кодирование данных.
Примеры: шифрование SSL/TLS, JPEG, MP3, ASCII, JSON.
🎨 Уровень 7 — Прикладной (Application)
Предоставляет сервисы непосредственно пользовательским приложениям.
Протоколы: HTTP/S, DNS, DHCP, SSH, SMTP, FTP, SNMP.
Примеры использования: просмотр веб‑страниц, электронная почта, передача файлов.
Telegram
METANIT.COM
Сетевые протоколы, которые работают на разных уровнях сетевой модели OSI
(описание в следующем посте)
(описание в следующем посте)
👍16❤3🔥1
Паттерн Model-View-Controller (Модель‑Представление‑Контроллер или MVC)
(описание в следующем посте)
(описание в следующем посте)
❤2👍2💯2
Паттерн Model-View-Controller (Модель‑Представление‑Контроллер или MVC)
(продолжение предыдущего поста)
→ MVC разделяет приложение на три основных компонента для разграничения ответственностей и повышения удобства сопровождения: Модель, Представление и Контроллер.
→ Представление отвечает за отображение, Контроллер — за обработку ввода и управление потоком, Модель — за данные и бизнес‑правила.
Компоненты
→ Представление (UI) → Отображает данные и обрабатывает взаимодействия пользователя (веб‑страницы, экраны мобильных приложений).
→ Контроллер → Получает ввод от Представления, интерпретирует его, вызывает Модель или обновляет Представление.
→ Модель → Содержит данные приложения и бизнес‑логику; уведомляет Представление об изменениях состояния.
→ База данных / Хранилище → Постоянное хранилище, из которого Модель считывает данные и в которое записывает их.
Поток данных (упрощённо)
→ Представление —(ввод пользователя)→ Контроллер —(вызывает)→ Модель —(считывает/записывает)→ База данных
→ Модель —(уведомляет)→ Представление —(отображает обновлённые данные)→ Пользователь
Преимущества
→ Чёткое разделение ответственностей → упрощение тестирования и параллельной разработки.
→ Повторное использование компонентов — несколько Представлений могут использовать одну и ту же Модель.
→ Более чёткая организация логики интерфейса по сравнению с бизнес‑логикой.
Недостатки
→ Может стать избыточным при большом количестве контроллеров/представлений в крупных приложениях.
→ Возможна тесная связность, если ответственности не разделены чётко.
→ Не всегда оптимально подходит для высокоинтерактивных клиентских интерфейсов без адаптации (например, MVVM или Flux могут быть предпочтительнее).
Распространенные рекомендации по использованию
→ Делайте Контроллеры «лёгкими» — делегируйте бизнес‑логику Моделям или сервисам.
→ Представления без бизнес-логики только для отображения данных и передачи событий
→ Применение шаблона Наблюдатель (observer) или привязки данных, чтобы Представления автоматически обновлялись при изменении Модели.
→ Отедбные юнит‑тесты для Моделей и Контроллеров
→ В крупных проектах организуйте код по функциональным возможностям, а не только по уровням MVC.
(продолжение предыдущего поста)
→ MVC разделяет приложение на три основных компонента для разграничения ответственностей и повышения удобства сопровождения: Модель, Представление и Контроллер.
→ Представление отвечает за отображение, Контроллер — за обработку ввода и управление потоком, Модель — за данные и бизнес‑правила.
Компоненты
→ Представление (UI) → Отображает данные и обрабатывает взаимодействия пользователя (веб‑страницы, экраны мобильных приложений).
→ Контроллер → Получает ввод от Представления, интерпретирует его, вызывает Модель или обновляет Представление.
→ Модель → Содержит данные приложения и бизнес‑логику; уведомляет Представление об изменениях состояния.
→ База данных / Хранилище → Постоянное хранилище, из которого Модель считывает данные и в которое записывает их.
Поток данных (упрощённо)
→ Представление —(ввод пользователя)→ Контроллер —(вызывает)→ Модель —(считывает/записывает)→ База данных
→ Модель —(уведомляет)→ Представление —(отображает обновлённые данные)→ Пользователь
Преимущества
→ Чёткое разделение ответственностей → упрощение тестирования и параллельной разработки.
→ Повторное использование компонентов — несколько Представлений могут использовать одну и ту же Модель.
→ Более чёткая организация логики интерфейса по сравнению с бизнес‑логикой.
Недостатки
→ Может стать избыточным при большом количестве контроллеров/представлений в крупных приложениях.
→ Возможна тесная связность, если ответственности не разделены чётко.
→ Не всегда оптимально подходит для высокоинтерактивных клиентских интерфейсов без адаптации (например, MVVM или Flux могут быть предпочтительнее).
Распространенные рекомендации по использованию
→ Делайте Контроллеры «лёгкими» — делегируйте бизнес‑логику Моделям или сервисам.
→ Представления без бизнес-логики только для отображения данных и передачи событий
→ Применение шаблона Наблюдатель (observer) или привязки данных, чтобы Представления автоматически обновлялись при изменении Модели.
→ Отедбные юнит‑тесты для Моделей и Контроллеров
→ В крупных проектах организуйте код по функциональным возможностям, а не только по уровням MVC.
Telegram
METANIT.COM
Паттерн Model-View-Controller (Модель‑Представление‑Контроллер или MVC)
(описание в следующем посте)
(описание в следующем посте)
❤2👍2🔥2
Глава Alphabet (Google) Сундар Пичаи сравнил вайб-кодинг с ростом популярности блогов и YouTube, но предупредил, что явление не должно затрагивать критически важные системы.
Гендиректор Google рассказал о резком росте числа вайб-кодеров, но предупредил, что продукт их работы не подходит для крупных кодовых баз, критически важных с точки зрения безопасности.
Пичаи отметил, что инструменты, основанные на больших языковых моделях, делают программирование «более приятным» и «доступным», поскольку люди могут тестировать идеи для приложений и веб-сайтов, не разбираясь сначала в синтаксисе или фреймворках. По его словам, этот сдвиг уже заметен в репозиториях Google.
В то же время глава Google подчеркнул, что не применяет вайб-кодинг к обширным кодовым базам, «где действительно нужно сделать всё правильно».
https://www.techspot.com/news/110434-google-ceo-vibe-coding-reshaping-who-gets-write.html
Гендиректор Google рассказал о резком росте числа вайб-кодеров, но предупредил, что продукт их работы не подходит для крупных кодовых баз, критически важных с точки зрения безопасности.
Пичаи отметил, что инструменты, основанные на больших языковых моделях, делают программирование «более приятным» и «доступным», поскольку люди могут тестировать идеи для приложений и веб-сайтов, не разбираясь сначала в синтаксисе или фреймворках. По его словам, этот сдвиг уже заметен в репозиториях Google.
В то же время глава Google подчеркнул, что не применяет вайб-кодинг к обширным кодовым базам, «где действительно нужно сделать всё правильно».
https://www.techspot.com/news/110434-google-ceo-vibe-coding-reshaping-who-gets-write.html
TechSpot
Google's CEO says "vibe coding" is reshaping who gets to write code
Pichai made the comments on a Google for Developers podcast with Logan Kilpatrick, who runs Google's AI Studio. The CEO said tools built on large language models...
👍8❤6🤮3🤔2👏1
This media is not supported in your browser
VIEW IN TELEGRAM
Известный исследователь в области искуственного интеллекта Ян Лекун (Yann LeCun) утверждает, что модели LLM сами по себе не являются пузырем ни в плане стоимости, ни в плане инвестиций — они будут способствовать развитию множества реальных приложений и оправдывать текущие расходы на инфраструктуру.
Настоящий пузырь же кроется в предположении, что модели LLM смогут мыслить на уровне человека.
Настоящий пузырь же кроется в предположении, что модели LLM смогут мыслить на уровне человека.
😁24💯18🔥5👍4🖕4🤔2
Линус Торвальдс и Линус Себастьян из Linus Tech Tips провели сборку идеального ПК для Linux
Для создания мощной рабочей системы Линусы выбрали:
- процессор CPU AMD Ryzen Threadripper 9960X с 24 ядрами и 48 потоками;
- ОЗУ Kingston 16 ГБ DDR5 х4;
- видеокарту Intel Arc B580;
- материнскую плату GIGABYTE TRX50 AERO D;
- SSD-накопитель Samsung 9100 PRO 2TB;
- кулер Noctua NH-U14S TR5-SP6;
- блок питания Seasonic PRIME TX-1600 1600W 80+ Titanium;
- системный блок Fractal Design Torrent E-ATX Case;
- 31.5-дюймовый монитор Asus ProArt PA32QCV (6K HDR).
Всю сборку выполнил Линус Себастьян, а Торвальдс только пояснял, какие элементы ему больше нравятся (воздушное охлаждение, ECC-память).
https://youtu.be/mfv0V1SxbNA
https://linustechtips.com/topic/1627666-building-the-perfect-linux-pc-with-linus-torvalds/
Для создания мощной рабочей системы Линусы выбрали:
- процессор CPU AMD Ryzen Threadripper 9960X с 24 ядрами и 48 потоками;
- ОЗУ Kingston 16 ГБ DDR5 х4;
- видеокарту Intel Arc B580;
- материнскую плату GIGABYTE TRX50 AERO D;
- SSD-накопитель Samsung 9100 PRO 2TB;
- кулер Noctua NH-U14S TR5-SP6;
- блок питания Seasonic PRIME TX-1600 1600W 80+ Titanium;
- системный блок Fractal Design Torrent E-ATX Case;
- 31.5-дюймовый монитор Asus ProArt PA32QCV (6K HDR).
Всю сборку выполнил Линус Себастьян, а Торвальдс только пояснял, какие элементы ему больше нравятся (воздушное охлаждение, ECC-память).
https://youtu.be/mfv0V1SxbNA
https://linustechtips.com/topic/1627666-building-the-perfect-linux-pc-with-linus-torvalds/
YouTube
Building the PERFECT Linux PC with Linus Torvalds
Get a free 15-day trial of Odoo’s all-in-one business solution and see how it can make your life easier! Check it out at https://www.odoo.com/ltt
It is finally here, the computer build you have (and possibly the whole world) been waiting for. The Linus Tech…
It is finally here, the computer build you have (and possibly the whole world) been waiting for. The Linus Tech…
🤡24🐳17❤7🤣3🏆3😎3👀1
Механизмы авторизации API
(продолжение к предыдущему посту)
Контроль разрешений пользователей в современных API
1. Управление доступом на основе ролей (RBAC, Role‑Based Access Control)
→ Определение
✓ Назначает разрешения на основе роли пользователя (администратор, редактор, зритель).
→ Как это работает
✓ Пользователи → Назначенные роли → Роли → Предоставление разрешений.
→ Оптимально для
✓ Систем с чётко определёнными группами разрешений.
✓ Панелей управления, SaaS‑приложений, CMS‑платформ.
2. Управление доступом на основе атрибутов (ABAC, Attribute‑Based Access Control)
→ Определение
✓ Принимает решения об авторизации на основе атрибутов.
→ Атрибуты включают
✓ Атрибуты пользователя (возраст, отдел, подписка).
✓ Атрибуты ресурса (тип, владелец).
✓ Атрибуты среды (время, местоположение).
→ Оптимально для
✓ Предприятий с сложными и динамическими правилами доступа.
3. Фреймворк авторизации OAuth 2.0
→ Определение
✓ Делегированная авторизация, которая позволяет сторонним приложениям получать доступ к ресурсам без раскрытия паролей пользователей.
→ Как это работает
✓ Аутентификация через провайдера → Выдача токена доступа → API проверяет токен.
→ Распространённые потоки
✓ Код авторизации (Authorization Code).
✓ Учётные данные клиента (Client Credentials).
✓ Потолок для устройств (Device Flow).
→ Оптимально для
✓ Приложений, требующих входа через соцсети или безопасного делегированного доступа.
4. OpenID Connect (OIDC)
→ Определение
✓ Уровень идентификации, построенный на базе OAuth 2.0.
✓ Добавляет проверку личности пользователя с помощью ID‑токенов.
→ Что предоставляет
✓ Проверенную идентификацию.
✓ Единый вход (SSO, Single Sign‑On).
✓ Стандартные утверждения (имя, электронная почта и т. д.).
→ Оптимально для
✓ Систем аутентификации и авторизации.
5. Авторизация с помощью JSON‑веб‑токенов (JWT, JSON Web Token)
→ Определение
✓ Авторизация осуществляется с помощью подписанных JSON‑токенов.
→ Как это работает
✓ Пользователь входит в систему → Сервер выдаёт JWT, содержащий утверждения → Клиент отправляет токен с каждым запросом.
→ Преимущества
✓ Отсутствие состояния (stateless).
✓ Идеально для распределённых микросервисов.
→ Оптимально для
✓ Мобильных приложений, одностраничных приложений (SPA), современных REST API.
6. Управление доступом на основе политик (PBAC, Policy‑Based Access Control)
→ Определение
✓ Решения о доступе принимаются с использованием централизованных политик.
→ Как это работает
✓ Механизм политик проверяет правила → Разрешает или отклоняет запрос.
→ Оптимально для
✓ Государственных систем.
✓ Среды с жёсткими требованиями соответствия.
7. Списки контроля доступа (ACL, Access Control Lists)
→ Определение
✓ Разрешения настраиваются непосредственно для каждого ресурса.
→ Как это работает
✓ Ресурс содержит список разрешённых пользователей и действий.
→ Оптимально для
✓ Файловых систем.
✓ Моделей безопасности на уровне ресурсов.
Краткое резюме
✓ RBAC → На основе ролей.
✓ ABAC → На основе атрибутов.
✓ OAuth 2.0 → Делегированный доступ.
✓ OIDC → Уровень идентификации.
✓ JWT → Без состояния, на основе токенов.
✓ PBAC → На основе политик.
✓ ACL → На уровне ресурсов.
(продолжение к предыдущему посту)
Контроль разрешений пользователей в современных API
1. Управление доступом на основе ролей (RBAC, Role‑Based Access Control)
→ Определение
✓ Назначает разрешения на основе роли пользователя (администратор, редактор, зритель).
→ Как это работает
✓ Пользователи → Назначенные роли → Роли → Предоставление разрешений.
→ Оптимально для
✓ Систем с чётко определёнными группами разрешений.
✓ Панелей управления, SaaS‑приложений, CMS‑платформ.
2. Управление доступом на основе атрибутов (ABAC, Attribute‑Based Access Control)
→ Определение
✓ Принимает решения об авторизации на основе атрибутов.
→ Атрибуты включают
✓ Атрибуты пользователя (возраст, отдел, подписка).
✓ Атрибуты ресурса (тип, владелец).
✓ Атрибуты среды (время, местоположение).
→ Оптимально для
✓ Предприятий с сложными и динамическими правилами доступа.
3. Фреймворк авторизации OAuth 2.0
→ Определение
✓ Делегированная авторизация, которая позволяет сторонним приложениям получать доступ к ресурсам без раскрытия паролей пользователей.
→ Как это работает
✓ Аутентификация через провайдера → Выдача токена доступа → API проверяет токен.
→ Распространённые потоки
✓ Код авторизации (Authorization Code).
✓ Учётные данные клиента (Client Credentials).
✓ Потолок для устройств (Device Flow).
→ Оптимально для
✓ Приложений, требующих входа через соцсети или безопасного делегированного доступа.
4. OpenID Connect (OIDC)
→ Определение
✓ Уровень идентификации, построенный на базе OAuth 2.0.
✓ Добавляет проверку личности пользователя с помощью ID‑токенов.
→ Что предоставляет
✓ Проверенную идентификацию.
✓ Единый вход (SSO, Single Sign‑On).
✓ Стандартные утверждения (имя, электронная почта и т. д.).
→ Оптимально для
✓ Систем аутентификации и авторизации.
5. Авторизация с помощью JSON‑веб‑токенов (JWT, JSON Web Token)
→ Определение
✓ Авторизация осуществляется с помощью подписанных JSON‑токенов.
→ Как это работает
✓ Пользователь входит в систему → Сервер выдаёт JWT, содержащий утверждения → Клиент отправляет токен с каждым запросом.
→ Преимущества
✓ Отсутствие состояния (stateless).
✓ Идеально для распределённых микросервисов.
→ Оптимально для
✓ Мобильных приложений, одностраничных приложений (SPA), современных REST API.
6. Управление доступом на основе политик (PBAC, Policy‑Based Access Control)
→ Определение
✓ Решения о доступе принимаются с использованием централизованных политик.
→ Как это работает
✓ Механизм политик проверяет правила → Разрешает или отклоняет запрос.
→ Оптимально для
✓ Государственных систем.
✓ Среды с жёсткими требованиями соответствия.
7. Списки контроля доступа (ACL, Access Control Lists)
→ Определение
✓ Разрешения настраиваются непосредственно для каждого ресурса.
→ Как это работает
✓ Ресурс содержит список разрешённых пользователей и действий.
→ Оптимально для
✓ Файловых систем.
✓ Моделей безопасности на уровне ресурсов.
Краткое резюме
✓ RBAC → На основе ролей.
✓ ABAC → На основе атрибутов.
✓ OAuth 2.0 → Делегированный доступ.
✓ OIDC → Уровень идентификации.
✓ JWT → Без состояния, на основе токенов.
✓ PBAC → На основе политик.
✓ ACL → На уровне ресурсов.
Telegram
METANIT.COM
Механизмы авторизации API
(продолжение в следующем посте)
(продолжение в следующем посте)
❤3👍3👏1
This media is not supported in your browser
VIEW IN TELEGRAM
Линус Торвальдс о резервном копировании данных:
«Только слабаки используют резервное копирование на ленту: настоящие мужчины просто загружают свои важные данные на FTP, и пусть остальной мир их копирует" - Линус Торвальдс, 1996 г., LKML
(Оригинал: "Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it")
«Мой подход к хранению данных таков: я загружаю их в интернет, и если они стоят того, чтобы их сохранить, кто-то другой сохранит их для меня». — Линус Торвальдс, 2025 г., Linus Tech Tips
(Оригинал: "My data storage approach is: I upload it to the internet, and if it's worth saving, somebody else will save it for me.")
«Только слабаки используют резервное копирование на ленту: настоящие мужчины просто загружают свои важные данные на FTP, и пусть остальной мир их копирует" - Линус Торвальдс, 1996 г., LKML
(Оригинал: "Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it")
«Мой подход к хранению данных таков: я загружаю их в интернет, и если они стоят того, чтобы их сохранить, кто-то другой сохранит их для меня». — Линус Торвальдс, 2025 г., Linus Tech Tips
(Оригинал: "My data storage approach is: I upload it to the internet, and if it's worth saving, somebody else will save it for me.")
😁49🤡11🔥8❤4🥴3🦄3😱2💯1🤣1