BrowserContext.new_cdp_session | Playwright Python
Уточнює межу raw CDP access у Playwright.
Як Playwright взаємодіє з браузером через протокол → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
Database authorization у PostgREST
PostgREST автентифікує request, перемикається на PostgreSQL role і залишає authorization базі даних. JWT claims, grants і Row-Level Security стають перевірюваними частинами API access control.
Прихована складність бекенд-тестування →Застереження
Відео демонструє historical product state. Поточні назви, download URLs, pricing, access limits і platform support потребують окремого підтвердження автором перед публікацією.
Корисні застосунки та їхнє призначення →Спроєктувати runner для одного UI-suite
Намалювати маршрут від runner до application і залежностей.
Зафіксувати потрібні credentials та мінімальні network rules.
Запустити suite з обраною concurrency й записати peak CPU/RAM.
Обґрунтувати hosted або self-hosted варіант фактичними даними.
Короткий capacity та access worksheet без універсальних припущень про RAM або вартість.
OAuth roles і місце в архітектурі
Authorization server видає/validates tokens і може масштабуватися окремо. Client — application, яка просить access; resource owner дає consent; resource server приймає access token і захищає API. Відео розрізняє user authorization і service-to-service access. Токен має представляти конкретного subject/client і не давати більше privileges, ніж потрібно.
Access token, refresh token і application registration
Access token короткоживучий; refresh token дає можливість отримати новий без повторної interactive authorization. Lifetime є server configuration, а не універсальні «дві години». На developer portal демонструється registration application/client, вибір scopes і redirect/callback URL. Client secret не можна вбудовувати в public mobile/browser client; там потрібен Authorization Code + PKCE.
Коли прямий DB access справді прискорює тести
Створення або читання сутності через API проходить routing, application logic, database access і serialization, тому сотні setup-запитів накопичують час. Прямий запит до database інколи виконується за кілька мілісекунд і може бути корисним для підготовки або пошуку test data. У Java типовим низькорівневим контрактом є JDBC; у Python — драйвер конкретної СУБД, який зазвичай підтримує Python DB-API. Для підключення потрібні host/URL, database/schema, credentials і driver. Секрети не мають бути в коді, а тестовий користувач БД повинен мати мінімальні права. Прямий insert не завжди еквівалентний product operation: він може обійти validation, events, audit, caches та синхронізацію. Тому DB setup доречний лише для сутностей, де команда явно приймає такий контракт.
GitHub-акаунт і авторизація в JetBrains IDE
Спочатку потрібно створити та підтвердити GitHub-акаунт. У settings JetBrains IDE знаходиться розділ GitHub, де можна увійти через browser authorization. У відео також згадується personal access token як альтернатива. Ця авторизація дає IDE можливість створювати, клонувати та оновлювати repositories.
Перша задача повинна перевірити потрібну сильну сторону
Базовий onboarding для всіх рівнів включає documentation, доступи, checkout репозиторію та перевірку Jira/CI. Наступну невелику задачу варто обрати за конкретним плюсом, заради якого людину наймали: fintech, maps, CAPTCHA, OTP чи інша domain expertise. Від senior очікується ширше дослідження infrastructure, access, environments і rate limits; middle може зосередитися на локальній реалізації.
Non-public API у Python
Один underscore, наприклад `_locator`, — домовленість «внутрішня деталь, не використовуй без потреби». Інтерпретатор не забороняє доступ. Подвійний початковий underscore запускає name mangling, щоб зменшити випадкові конфлікти в нащадках, але теж не створює security boundary. На відміну від `private` або `protected` у статично типізованих мовах, Python більше покладається на дисципліну автора й користувача класу. IDE може попередити про звернення до non-public member, але виконання зазвичай можливе.
Доступ і межі демонстрації
Наприкінці показано account flow Diduny через email і one-time password та згадано тимчасовий розширений доступ для учасників курсу. Також наголошено на правильному виборі microphone і transcription mode в settings. Усі продемонстровані продукти на той момент перебували в активній розробці: частина функцій, pricing і platform support могла змінитися після запису.
User flow і server-to-server flow
User flow емулює дії людини і consent, service flow представляє machine client. Якщо test завжди бере admin/service token, він не перевіряє real user authorization boundaries. Потрібні positive/negative checks для scopes, audience, client type і resource access. Token exchange чи внутрішні service tokens не слід вигадувати за Network tab — їх contract має дати backend/security team.
AI як помічник для конкретного selector
HTML конкретного елемента можна передати моделі й попросити locator для Playwright або Selenium, уточнивши правила про allowed attributes і partial match. Це швидше за вивчення синтаксису складного XPath, але результат треба перевірити на сторінці. Ще надійніше — мати read access до frontend source, знайти компонент і додати стабільний атрибут у тому самому delivery process.
Дані, GDPR і прямий REST-доступ до PostgreSQL
[Дивитися з 22:13](https://www.youtube.com/watch?v=GwmAB4IvQUk&t=1333s). Backend testing охоплює не тільки response body, а й правила зберігання, видалення та повідомлення користувача про персональні дані. Навіть архітектура без окремих controllers — наприклад, REST-інтерфейс поверх PostgreSQL через PostgREST — не скасовує перевірок access control, фільтрації та дозволених операцій. Прямі CRUD-запити можуть бути простими синтаксично, але безпека й видимість rows усе одно залежать від правил у шарі даних.