Ответ на 'Слона то я и не приметил, или почему важно своевременно защищать данные'
До поста про слона, которого Оля якобы не приметила (в коде зеркала) я старался хоть как-то пытаться найти рациональное зерно во всех её постах на тему последних событий (даже несмотря на то, что мой аккаунт почему-то оказался выпилен - только сейчас это понял, когда новый пришлось делать). Но тут уже точно не смог мимо пройти, т.к. в своей основной деятельности я очень часто использую Laravel. И сразу захотелось ответить и на пост, и на комменты...
Самый главный основной тезис поста Пост: Слона то я и не приметил, или почему важно своевременно защищать данные - там есть миграция (т.е. файл для создания таблиц) с названием 0001_01_01_000000_create_users_table.php
Абсолютной любой laravel-разработчик знает, что это стандартная миграция из фреймворка, которую никто не будет в здравом уме выпиливать (может пригодиться например для создания админки какой-то импровизированной). Вот она в официальном репозитории ларавел - https://github.com/laravel/laravel/blob/12.x/database/migrations/0001_01_01_000000_create_users_table.php
Миграция эта по умолчанию создаёт 3 таблицы - users, password_reset_tokens и sessions. И, как уже несколько раз написали в комментах к изначальному посту используются они в связке с моделькой User (которая тоже идёт в комплекте с фреймворком сразу - https://github.com/laravel/laravel/blob/12.x/app/Models/User.php).
Дальше была претензия к несчастной фабрике UserFactory (тоже являющейся частью laravel по умолчанию - https://github.com/laravel/laravel/blob/12.x/database/factories/UserFactory.php). Всё её предназначение - это генерирование тестовых данных для модели User. Т.е. наполнение тестовыми данными базы данных для тестов. Оно вообще не предназначено для того, чтобы сохранять реальные данные проекта. Даже в коде это видно - fake() возвращает инстанс faker со случайными данными. А пароль ставится по умолчанию 'password'. При этом хэшируется, кстати.
public function definition(): array
{
return [
'name' => fake()->name(),
'email' => fake()->unique()->safeEmail(),
'email_verified_at' => now(),
'password' => static::$password ??= Hash::make('password'),
'remember_token' => Str::random(10),
];
}
Можно ли это всё притянуть за уши к вопросу о том, что раз есть таблица - то планировали её использовать? Можно, конечно. Из разряда - есть хер, значит планировал изнасилование. Почему так? А потому что весь код проекта можно изучить вдоль и поперёк примерно за 15 минут (для знакомого с PHP и Laravel человека). Для незнакомого, но умеюшего программировать хоть на чём-то на среднем уровне - час совместно с ChatGPT. Там вообще ни слова или намёка о сохранении каких-то пользовательских данных.
Если хочется подробностей - пожалуйста.
Есть app/Services/ProxyCacheService.php
Сервис занимается только тем, что получает из HTTP-запроса все заголовки (там нет пароля, если кому-то интересно) вместе с полной ссылкой при запросах /api/, собирает всё это в ключ для кэша (обернув дополнительно в md5, который необратим, его нельзя "расшифровать", т.е. даже эти данные обезличены) и кладёт то, что вернул оригинальный сервер (сам контент страницы) к себе в кэш (Redis) для быстрого доступа.
Я не берусь обсуждать сам код (видно, что делалось на коленке и без учёта многих факторов), но это никак не влияет на то, что текущий сервис ни к каким паролям доступ не получит. Его задача простая - получили контент страницы, сохранили в кэш (чтобы потом отдавать из кэша, а не лезть на оригинальный сервер).
И есть единственный класс контроллера
app/Http/Controllers/ProxyController.php
Он как раз используется сервис кэширования плюс имеет некоторую логику, а именно
proxy() - всё, что попадает в /api/ идёт в кэш. В самом методе пересобирается json с данными для замены внутренних ссылок на лету
proxyMedia() - вообще ничего не делает сейчас, только логи пишет.
upload() - собирает картиночки всякие к себе на сервер, чтобы тоже их проксировать, а не тянуть с digital ocean, который заблочен в РФ.
и auth() - единственное место, где теоретически можно поймать пароль юзера. Метод ничего никуда не сохраняет, только перенаправляет запрос целиком на оригинальный https://auth.alpha.kapi.bar/v1/. В итоге пользователь в ответ получает авторизационный токен, который потом используется для остальных запросов.
Итого - код абсолютно прозрачен, любые изменения которые могли бы скомпрометировать данные пользователей отслеживаются моментально при merge request (не верю, что в команде нет ни одного человека, который может прочитать PHP-код). Уровень паранойи про ключевым словам (migrations, user, token) - запредельный (и безосновательный, как по мне).
И да, если кто-то может кинуть ссылку на телегу, где идёт хоть какое-то обсуждение проекта (в основной группе все топики закрыты) - киньте в меня плиз в телеге @maximus_mad
