Александр Ме

канешна. куча.
закидываешь на смартфон - устанавливаешь. в последних андроидах у приложения должно разрешение устанавливать приложения из сторонних источников.
гуглплей это репозиторий приложений, причем не единственный. ставишь другой репозиторий.
еще есть Android Debug Dridge - интерфейс управления андроидом с компухтера.
изучай литературу, а не ролики в ютубе смотри....

Я развернул новый проект лары и скопировал туда твой код, все работает

1. Проверь что путь файла CheckAdminMiddleware.php соответствует неймспейсу

App\Http\Middleware

2. Попробуй сбросить кэш

php artisan cache:clear
composer dump-autoload

3. Если запускаешь проект в докере то убедись что изменения с локали ушли в контейнер

UPD
Не сразу обратил внимание что у меня не 11 лара, установилась Laravel 10

В ларавель 11 больше нет App\Http\Kernel::class (ну наверное его можно притащить туда и какими-то костылями заставить работать, но речь не об этом)

Все конфигурации теперь в bootstrap/app.php
Добавь в bootstrap/app.php

->withMiddleware(function (Middleware $middleware) {
...
        $middleware->alias([
            'admin' => App\Http\Middleware\CheckAdminMiddleware::class
        ]);
    })

https://laravel.com/docs/11.x/releases#structure

Либо делать реверс-инжиниринг, разбираться, что там в JS и WASM накручено, либо просто сделать скриншоты и отправить в распознавалку.
Второе, IMHO, на пару порядков быстрее, даже с учётом того, что скриншоты надо делать с увеличением.

Ты всё правильно рассуждаешь.
Исходить из принципа: все клиенты - мошенники.
0% доверия клиенту.
Не хранить у клиента никакой информации.
Клиент - это только рендеринг данных.
Вся логика - на сервере.

Вся логика на сервере. Клиенту отдаются только соевые данные для рендеринга.

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

Защита от подмены данных делается простым старым дедовским способом - подписью.
На сервере и на клиенте есть одинаковый временный ключ для подписи - signKey - длинная строка.
Клиент отправляет тебе POST-запрос со всеми данными: тип монеты, количество монет, ID юзера,...+ sign=HASH(тип_монеты+количество+userId+...+signKey)
HASH - это хэш-функция. Лучше использовать Bcrypt вместо слабого MD5.
Во-первых, всё делается через HTTPS.
Во-вторых, все операции - через сессии или аутентификацию по JWT.
На сервере ты делашь следующее:
- проверяешь соответствие переданных данных ожидаемым: userId (из JWT), тип монеты и прочее. От клиента ты ожидаешь МИНИМУМ изменяемых данных (количество фишек, например)
- проверяешь все поля на типы данных и ОЧЕНЬ ВАЖНО! - на длину передаваемых значений. Не допускается в строковом поле передавать больше, скажем, 20 символов. Это очень сильно ограничивает брутфорс для поиска коллизии хэша. Количество фишек должно быть целым положительным числом в определённых допустимых пределах (от 0 до 1000, напримр. Чем меньше диапазон, тем лучше)
- делаешь хэш по переданным значениям и сравниваешь его с переданным хэшем от клиента. Если не совпадают - юзер подменил количество монет.
На сервере у тебя должна быть защита от брутфорса: от одного userId, IP-адреса должно приходить не более 1-3 запросов в секунду. Если больше - банить на некоторое время, например, на 1 минуту.

Это то, что касается систем, где данные передаются ОТ пользователя серверу.

В твоём же случае - это просто игра.
И здесь поступают проще.
Всю логику делают на сервере. Юзер кликнул на монету - передаём серверу инфу: click(userId, x,y)
И вот тут включается логика сервера: он смотрит что за юзер кликнул, куда кликнул, как часто, разрешено ли ему это делать... Если всё в порядке, то сервер отправляет клиенту - Ок, вот тебе заработанные 10 монет. Клиент отрисовывает монетки, юзер радуется.
В этом случае полностью исключается подмена юзером количество монет, потому что всё решает сервер. Клиент - это просто терминал для отображения данных и отправки кликов на сервер.

Как масштаб в браузере – колесом мыши с зажатым контролом

На каждом уровне проверять, что значение не string и не number. Иначе никак, ты сам задал такой тип, и ts не даст тебе совершить ошибку.

Если у тебя только 2 уровня, то не надо рекурсии:

interface CSS {
    [k: string]: {
        [k: string]: string | number 
    }
}

Если ты хочешь сузить тип при создании констатны, можно сделать так:

const css = {
    default: {
        color: '#676767',
        border: '1px solid',
        border_color: '#C4C4C4',
        border_radius: '110px',

        padding: '16px 21px',
    }
} satisfies CSS;

paths в tsconfig - это чисто справочная информация для подсветки, добавленная из расчёта, что вы уже используете какой-то сборщик который такие пути умеет.
Сам по себе он влияет точно и исключительно на подсветку, нужны сторонние сборщики и\или модули.
Это by design и wont fix.

Предполагаемое разработчиками решение: взять какой-ниь vite или webpack и настроить там руками точно такие же алиасы.
Популярный костыль, который сделает это за тебя для любых вариантов, в том числе и ts-node: tsconfig-paths

Navigation bar

Waste::whereHas('components', static fn($q) => $q->whereIn('id', [1,2,3]))

If you need even more power, you may use the whereHas and orWhereHas methods to define additional query constraints on your has queries, such as inspecting the content of a comment:

use Illuminate\Database\Eloquent\Builder;
 
// Retrieve posts with at least one comment containing words like code%...
$posts = Post::whereHas('comments', function (Builder $query) {
    $query->where('content', 'like', 'code%');
})->get();
 
// Retrieve posts with at least ten comments containing words like code%...
$posts = Post::whereHas('comments', function (Builder $query) {
    $query->where('content', 'like', 'code%');
}, '>=', 10)->get();

https://laravel.com/docs/11.x/eloquent-relationshi...

["useVerificationToken", "getUserByEmail"].filter((method) => !adapter[method])

Этот твой массив ["useVerificationToken", "getUserByEmail"] автоматически определяется как массив строк.

Сделай так:

(["useVerificationToken",  "getUserByEmail"] as const).filter((method) => !adapter[method])

-----
в dev-режиме скорее всего выставлен конфиг suppressImplicitAnyIndexErrors=true, который подавляет ошибку. Посмотри конфиги, если найдешь эту содомию, выпиливай сразу.

https://www.raspberrypi.com/products/raspberry-pi-5/
Стявят VPN прокси сервер (выходную TOR-ноду)
Чтобы потом "товарищи" приходили к Вам, а не к ним или их клиентам

Ну потому, что ты запускаешь композер... И все, это весь твой ENTRYPOINT, который отработав отдает код 1. Ты же не запускаешь свой условный php-fpm и правда этому удивляешься?

> что бы при старте контейнера в нем сразу загружались все перечисленные зависимости из файла composer.json

В этом не то, чтобы много смысла, Dockerfile это не про старт контейнера, а его сборку. Если тебе нужно будет обновить зависимости - ты будешь пересобирать весь образ? Это не очень логично.

Можно запустить любой готовый образ композера с командой install, чтобы у тебя приехали все зависимости.
Можно зайти в шелл запущенного контейнера php и сделать composer i.
Можно конечно написать рабочий Dockerfile, который делает RUN composer i, а в ENTRYPOINT'е имеет запуск демона php-fpm...