Как я oauth proxy навайбокодил

Чем хорош TRMNL — так это возможностью выводить что-то своё за считанные минуты.

С помощью «Private Plugins» можно взять ссылку, что отдаёт JSON (недавно добавили поддержку XML и сырого текста), рисуем простой шаблон на HTML с Liquid, готово! Для пущей динамики возможе неще и javascript, что позволяет выводить графики.

Можно опубликовать для других пользователей, можно брать опубликованное другими и либо использовать как есть — либо подправить под себя. Раздолье!

График сахара — пять минут, используя приведённый в документации шаблон графиков и два взмаха жаваскриптом для конвертации данных.

График шагов… А вот тут сложнее. Сервер позволяет простые GET и POST запросы, можно сунуть что-то в заголовки, URL, тело запроса и т.п. — но вот хранить состояние между запросами нельзя, то есть в лоб OAuth2 не реализуешь. Оно и понятно: они не очень хотят хранить данные авторизации для всех.

Что же делать?

Что ж. Решим задачу.

Дано:

• есть платформа, которая может запрашивать урлы, но не хранит состояние;

• есть источники данных, которые отдают по REST что попросишь — но требуют OAuth2 авторизации;

• OAuth2 запросы авторизуется простыми ключами, но ключи требуют изначальной авторизации для выдачи прав, а потом постоянной ротации, чтоб поддерживать в актуальном состоянии;

• нет желания поднимать и обслуживать виртуалку где бы то ни было;

• нагрузка АЖ запрос раз в 15 минут. Может, если вдруг захочется, десяток запросов.

Решение:

• берём бесплатный CloudFlare;

• рисуем прокси, который будет проверять входящие запросы по статическому токену (без авторотации), и отсылать запросы дальше подписав динамическим токеном;

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

Так как задача простая как пробка, что справится кто угодно, почему бы не попытаться заставить это сделать машину?

Так что дополнительное развлечение: будем вайбокодить.

Подготовка к решению

Устанавливаем курсор. Запускаем. Пытаемся «перенести» плагины — получается нерабочий ужас.

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

Активируем триальную лицензию (заодно узнаем, стоит ли за неё платить). Создаём новый Git репозиторий, устанавливаем nodejs и npm внутри wsl и на винде.

В общем и целом, часть команд он запускать может, интеграция с Wsl сломана, интеграция через ssh внутрь wsl работает но как-то косо. Я просто открыл папку проекта и держу открытый отдельный terminator, благо монитор достаточно широкий.

Всё, более-менее всё дышит, можно начинать вайбокодить.

Процесс решения

Попытка «в лоб» сформулировать задачу как бы я её задавал человеку оказалась катастрофически провальной, но это я знал заранее, так как уже игрался с сеточками для поиска решений.

Дао «заставить одну сеть составить план, который скармливать потом курсору» я не постиг: я сломался на попытке получить план, с которым я был бы согласен. Этот навык набивать можно будет позднее, перейдём к практике.

Кодить будем по шагам, и план простой: создать админку => добавить oauth авторизацию и хранение => добавить прокси => добавить ротацию => деплоим.

Часть первая: админка

(1) Говорим агенту, что мы пишем под CloudFlare workers на Javascript и просим создать скелет c двумя endpoint’ами: для настройки и для админки, админке нужен логин-пароль который хранится в KV базе.

Он создаёт какой-то код, который оч похож на правду. Восторгаемся пассажу про

            <div class="credentials-info">               <p>Development credentials:</p>               <p>Username: admin</p>               <p>Password: password123</p>             </div>

Но игнорируем, так как нигде внутри кода это не захардкожено.

Спрашиваем как его запустить для пощупать (я ничего не знаю про CloudFlare), его ответ не работает (wrangler в лоб не запускается ни на винде ни в wsl), вопрос в gemini объяснил недостающее, ставлю пакеты, через npx wrangler dev запускаю, не работает копируют ошибку про KV курсору, он прави тnamespace на local, оно запускается.

Прошу создать .gitignore, он его создаёт, и вроде даже похоже на правду. Коммитим, первый шаг готов.

(2) Просим в админке создать форму создания нового приложения и список приложений, в котором есть кнопка удалить и отредактировать. Для каждого приложения задаются его название, client id, пути для авторизации и API. Client ID и название редактировать нельзя, пути — можно.

Тут я познакомился с его подходом «простите, что-то не получилось, я сейчас еще раз». Раза с третьего он смог интегрировать своё решение в редактор. Выглядит так, что он иногда пытается сгенерировать дифф, а иногда полный файл.

Очень внимательно полюбуйтесь на это. Пароль больше не надо вводить, да. Нужен только логин, который сохраняется в куку, очень удобно.

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

Спрашиваем «а не может ли KV проверять срок жизни?»… Может, говорит, и переделывает.

Уф, теперь ничего сходу страшного не обнаруживается, коммитим.

Часть вторая: oauth хранение и авторизация

(3) Пришла пора проверить его догадливость. Просим для каждого приложения добавить кнопку oauth авторизации, которую сохранять в базе приложения.

И он справляется! Сам добавляет хранение токенов, отдельный endpoint для callback’а при авторизации, генератор рандомного кода для верификации, причем реюзнул тот же что для сессий сделал на прошлом шаге. Ручные эксперименты с fitbit web api потребовали только прописать scope не «read write» а «activity».

Вот только редиректы — не работают. Несколько жалоб с копированием ошибки таки привели к кое-как рабочему решению.

Коммитим, пока не поломалось.

(4) Просим сделать scope параметром для приложения. Коммитим.

(5) Так как сервера часто проверяют callback url и требуют его ввести при настройке, просим вывести его на форму.

Он выводит и добавляет, как он сам сказал, для удобства, кнопочку копирования. Коммитим.

(6) Просим для приложений добавить уникальные прокси токены, с возможностью перегенерировать их если вдруг захочется — и вывести их для каждого приложения. Коммитим.

Часть третья: прокси

(7) Добрались до второй части нашего балета: GET прокси. Просим сделать так, чтоб /get/ эндпоинт брал первое слово после /get/ как имя приложения, а всё что дальше — использовал как путь для API. Проверял, что в запросе передали правильный proxyToken и если да — добавлял остаток ссылки у API адресу и пересылал подписав текущим OAuth ключом.

Неплохо справляется с первого раза. Вторым запросом просим сохранить любые GET параметры запроса (кроме proxyToken). Коммитим.

        // Construct the target URL with all query parameters except proxyToken         const targetUrl = new URL(path, app.apiPath);         // Copy all query parameters except proxyToken         for (const [key, value] of url.searchParams.entries()) {           if (key !== 'proxyToken') {             targetUrl.searchParams.set(key, value);           }         }

(Неплохо же для первого раза в жизни?)

Часть четвертая: свежевание ключей

(8) В смысле — просим создать workflow, который будет рефрешить ключи для всех приложений, у которых осталось меньше 3х часов свежести. И добавить крон, который раз в 2 часа будет запускать воркфлоу.

Он создаёт новый файл с новым кодом, который на мой неопытный глаз вообще выглядит не так, как документация говорит. Даём ему ссылку на документацию и просим сделать согласно актуальной спеки. Он переделывает, код похож, а вот техническая обёртка вокруг — нет. Просим еще раз переделать, сложив всё вместе. Переделывает, поломав и новый и старый код. А я не коммитил! К счастью, после известной истории, «откатить текущий шаг» доступен после каждой рекомендации (причем иногда при редактировании запроса — срабатывает, так как какой-то из хоткеев редактирования текста работает как «отменить всё»). Откатываем, сливаем файлы вручную. Просим еще раз привести к актуальному виду (дав ссылку). Приводит, поломав всего ничего по дороге. Чиним вручную.

Вручную локальный код работает, workflow локально тестировать невозможно. Фиг с ним, код на первый взгляд делает что просили — коммитим.

Часть пятая: деплоим и тестим на «проде»

(9) Поскольку нельзя нормально Workflow протестировать локально, несмотря на то, что документация говорит обратное (о чем разные сетки врут по-разному: те, что умеют искать в гугле — находят что нельзя, те, что не умеют — как только ни галлюцинируют) — деплоим.

Спрашиваем как, пробуем, не работает, гуглим, находим, побеждаем. Обновляем вранглер, просим еще раз обновить код (ранее вручную смерженный в один файл) согласно последней документации (даём ссылку на неё) и еще раз полируем после него вручную (он запутался выдал смесь TypeScript и JavaScript).

Просим как быть с реквизитами (созданные для key-value), после трёх итераций сдаёмся, нагугливаем ответ.

(Ответ, кстати, мне не нравится: надо wrangler.toml внести в .gitignore, и положить пример под другим именем. То есть мержить и держить их в актуальном состоянии — боль — но неважно, это делается на «раз поставил и забыл».)

Окей, как только деплой прошел на ура и приложение ожило — обновляем инструкции и коммитим.

Часть шестая: причесываем

(10) Первое, что бросилось в глаза на тестах: в процессе авторизации приложения слетает сессия админки. Курсор сломался решить проблему: предлагал пучок разных решений, но так и не догадался, что проблема в secure cookie, которые он сам же и проставил с самого начала. Но даже когда я ему объяснил в чем дело — не понял. Пришлось прямо сказать чтоб воткнул в середине процесса восстановление куки и редирект через HTML (то есть не через 302 Location а через 200 + meta-refresh). В процессе хоть вспомнил зачем HTML редирект делался :))).

(11) Пароли плейнтекстом.

Нет, я всё понимаю, но не надо так. Попросил его. Без обиняков. Просто, мол, сделай пароли солёными.

Он решил пойти простым путём, и если есть логин но нет пароля — первое же использование задаёт пароль. Что примечательно: он сам догадался поправить README, но форму, которая говорит про password123 не стал менять. А я тем более не буду: не барское это дело! Я уже за ним вручную линтеры прогонял и копипастил.

(12) Позже выяснилось, что если Fitbit пофиг, то вот Netatmo таки требует проверки clientSecret. Просим добавить clientSecret к приложениям — он добавляет. Просим пописать еще и к рефрешу. Добавляет, радуемся.

Что мы делаем? Выводы

Итого, за несколько присестов в выходные удалось создать желаемое: trmnl-oauth-proxy.

Приложение позволяет быстро развернуть на бесплатном cloudflare тарифе персональный oauth прокси, так что можно создавать и авторизовывать источники данных для своих нужд и легко выводить их в своём TRMNL терминале.

А что на счет вайб кодинга?

Задача решена? Да — плюс. Умеет читать документацию, если ему её показать. Тоже плюс.

Как средство решения задач — еще слишком юно. Требует постоянный глаз да глаз. Норовит пропустить что-то. Добавить от себя. Решить ну очень не правильным методом. Забывает, что попросили. Истории нет. Часто пытается перегенерировать всё заново, ломая по дороге то, что уже починил. Объём контекста ограничен. Путается в показаниях.

Короче очень юный джун. Но, к сожалению, джун, который не учится. Когда-нибудь, когда он станет лучше… Возможно. Но сейчас — нет. Работы по проверке за ним больше, чем экономия времени.

Основной плюс AI для программирования для себя: избавиться от чистого листа. Попросить скелет / набросок решения. Выкинуть потом оттуда всё и переписать под себя зачастую быстрее, чем пытаться совсем писать с нуля. Ну, так я уже могу — и тут курсор не единственное решение. Хоть они и были более-менее первыми — таки платить ему мне не за чем.

Но сколько сеток — столько мнений, так что у читателя может сложиться своё мнение. С удовольствием послушаю в комментария о другом личном опыте!