Иногда для внутренней задачи не нужен большой web-сервис. Нужен небольшой инструмент, который запускается на рабочей машине, хранит данные локально и делает одну конкретную операцию без лишней инфраструктуры. Так появился учебный валидатор API-ключей: desktop-приложение на Python и Tkinter для локального хранения тестируемых ключей и проверки их на явно указанном сервере.
Важная граница проекта: программа предназначена только для образовательных целей и работы с собственными ключами, тестовыми значениями и серверами, на проверку которых есть право. Это не инструмент для перебора чужих ключей и не сервис для массовой проверки неизвестных данных.
Какую задачу решает программа
Базовый сценарий простой: у пользователя есть набор собственных API-ключей или тестовых строк, и ему нужно проверить, как они обрабатываются конкретным сервером. Вручную это обычно превращается в набор curl-команд, заметки в текстовом файле и потерянную историю проверок.
Приложение закрывает этот сценарий в одном окне:
- ключи добавляются в локальную SQLite-базу;
- полные значения хранятся зашифрованными мастер-паролем;
- дубликаты отсекаются через SHA-256 хэш;
- результаты проверки сохраняются рядом с записью;
- URL сервера проверки и количество потоков вынесены в настройки;
- по таблице можно копировать, перепроверять и удалять отдельные записи.
Почему desktop, а не web
Для такой задачи desktop-формат оказался практичнее. Не нужно поднимать сервер, настраивать пользователей, думать о хостинге и сетевом доступе к базе. Данные остаются на машине пользователя, а приложение делает исходящие запросы только на тот URL, который указан в настройках.
| Подход | Плюс | Риск |
|---|---|---|
| Web-сервис | Удобно делиться доступом | Нужно отдельно защищать сервер, пользователей и хранение данных |
| CLI-скрипт | Быстро написать | Неудобно просматривать историю и работать с большим списком |
| Desktop-приложение | Локальное хранение и понятный интерфейс | Нужно настроить сборку и обновления |
Что внутри
Проект разделен на несколько небольших частей. Контроллер приложения связывает интерфейс, SQLite-хранилище, HTTP-клиент и фоновый сканер. UI вынесен отдельно, чтобы основной файл не превращался в один большой Tkinter-класс.
Основные модули выглядят так:
storage.pyотвечает за SQLite, шифрование записей, настройки и результаты проверки;openai_client.pyотправляет HTTP-запрос на указанный API URL;scanner.pyуправляет очередью и worker-потоками;key_generator.pyсоздает тестовые строки старого и нового формата;update_checker.pyпроверяет новые версии через GitHub Releases;ui/содержит основное окно, диалоги, настройки и мастер генерации.
Локальное хранение и мастер-пароль
Ключи не лежат в базе открытым текстом. При первом запуске пользователь вводит мастер-пароль, из него строится Fernet-ключ, и полные значения шифруются перед записью в SQLite.
Если при следующем запуске пароль не подходит, приложение не падает с технической ошибкой. Оно показывает понятный диалог: повторить ввод, удалить локальную базу или выйти. Это важная мелочь. Пользователь должен понимать, что произошло, а не видеть traceback из cryptography.
Для локального инструмента UX ошибок не менее важен, чем сама криптография: пользователь должен понимать последствия своих действий.
Настройки проверки
URL сервера проверки и количество потоков вынесены в меню Настройки. Эти значения сохраняются в той же SQLite-базе в таблице settings.
Такой подход лучше, чем держать параметры в коде или просить пользователя каждый раз вводить URL заново. При этом приложение не скрывает, куда отправляет запросы: адрес сервера задается явно.
Генерация тестовых строк
В приложении есть мастер генерации тестовых строк старого и нового формата. Перед открытием мастер показывает предупреждение: генерация предназначена только для проверки собственных серверов и учебных стендов.
Это сделано не для “подбора” ключей. Практический смысл другой: удобно проверить, как свой сервер реагирует на разные форматы входных данных, как пишет ошибки, не падает ли на длинных строках и корректно ли обрабатывает невалидные значения.
Релизы и обновления
Для распространения приложения настроен GitHub Actions workflow. При push тега вида v1.0.0 workflow собирает Windows exe через PyInstaller, упаковывает его в ZIP и загружает архив в GitHub Release.
В приложении есть проверка обновлений. Она смотрит последний GitHub Release, сравнивает версию и предлагает открыть страницу скачивания. Это не самозаменяющийся updater, и это осознанное решение. Для первого релизного контура безопаснее дать пользователю понятную ссылку, чем пытаться заменить запущенный exe.
Что получилось полезного
- данные остаются локально;
- ключи шифруются мастер-паролем;
- проверки можно останавливать и запускать заново;
- результаты сохраняются в таблице;
- настройки переживают перезапуск;
- релиз собирается автоматически по тегу;
- пользователь видит, когда вышла новая версия.
Итог
Этот проект получился небольшим, но в нем есть почти весь контур, который часто нужен внутренним desktop-инструментам: локальная база, шифрование, настройки, фоновая работа, тесты, документация, сборка exe и публикация релизов.
Главный вывод простой: даже маленький инструмент стоит делать так, чтобы им можно было пользоваться не только сегодня вечером, но и через несколько версий.