angover, нет. вы все-равно обязаны его валидировать, верифицировать откуда пришел запрос, ну и не забываем про SSL шифрование (https), ассиметричное шифрование в подписи токена и все такое. Это вообще минимальные требования к безопасной системе. И да, не забываем что у токена есть срок жизни
Sanes, во-первых кто сказал что там есть Линукс? Во-вторых я и про MySQL от автора не слышал. Это все догадки, не более. Ну и в третьих, без знания как это все устроено один чиз и пока весь сервер. И восстанавливать долго если ты не умеешь. С докером сломал один контейнер, а другой жив. Откатился на прошлую ревизию контейнера и все работает, а параллельно разбираешься что пошло не так
Sanes, успехов в этом направлении. Посмотри как крупные организации работают, например, и что им это позволяет. В частности, для таких вопросов. А что касается тючмсла точек отказа так ты на ровном месте проблема придумал. В точках отказа важно мне из количество, а их изоляция. В вопросе рассматривается классическая two-tier инфраструктура
Sanes, контейнеризация несёт много плюсов на дальнюю перспективу, а ты предлагаешь костыль. Без изоляции окружений, без возможности передать в работу другим лицам, с геморроем девопса, без поддержки, без шанса уйти в облака. Если нравится жрать кактус от хоть другим не предлагай
Евгений Шишмаков, ну, могу вам посоветовать. Может вы решили прыгнуть через через голову? Рано вам про long polling. А когда будет ок то эта технология умрет уже
Евгений Лавренов, я не силен в настройках апача, но знаю что на уровне сети примерно так оно и работает. В документации вы разберётесь и без сторонней помощи. Это же логично что раз вы не можете на один порт вешать 2 сервиса то вам придется разносить их на разные порты. А поскольку http только на одном порту то вам нужен ещё один контейнер для роутинга траффика
Евгений Лавренов, ссылочки не найду. Берете третий контейнер с апачем или нгинксом и настраиваете его чтобы определенные адреса смотрели на разные порты. Можете это всё собрать через docker-compose для простоты
