потому что session_id должен быть привязан к id пользователя, это как бы основы. По session_id сервер восстанавливает user_id. Ну и сразу не нужно гонять session_id по вебсокету, его достаточно использовать в самом начале, при создании коннекта.
Привязка на бэке есть. Ситуация в другом, в случае переподключения пользователя (закрыл-открыл, или refresh), сессия закрывает и открывается новая. Старая сессия на бэке удаляется, новая записывается. Даже если не будем всё время гонять по вебсокету id пользователя, как нам проверять валидность\легитимность данных от пользователя? По session_id, но это будет вторичный признак. Если произойдет закрытие\refresh
- session_id - меняется. В таком случае, предположим я злоумышленник - я делаю "event": "connect" и перебираю user_id.
небольшое отступление
Т.к. я допускаю что websocket сессия может зависнуть (ну отвалился интернет допустим), и не пришел "event":"disconnect", в таком случае лучше реализовать логику с перезаписью активной сессии. Пинг - понг реализован, чтобы закрывать неактивные сессии старше 2 минут. на самом деле немного сложнее, после подключения проверяем доступность по нарастающей - 10,15,20,40,60,120 сек
Получается что злоумышленник перебирая id сможет отключать пользователей, и переключать активную сессию на себя.
Просто смотрите, если я Вас правильно понял, то Вы имеете ввиду следующее:
После проверки initdata от ТГ и валидации user_id, создаем websocket соединения отправляя туда только user_id? Если я правильно понял Вашу задумку, в таком случае меня смущает что этот user_id ничем не защищен, и в случае перебора - пострадают пользователи, т.к. 1) их будет выкидывать из текущей сессии 2) данные от их аккаунта (в приложении) будут подгружаться туда, где их быть не должно. Или же Вы не дописали и подразумеваете дополнительные проверки?
а в jwt обычно прописывают user_id, поменять ты его не сможешь, токен будет невалидный
Да, я знаю про jwt, в моём случае используя собственные знания - я еще более упростил эту задачу и получаю результат, как если бы я использовать jwt. В моем случае - все данные находятся в зашифрованном виде, и расшифровывать их может только бэк. В случае невозможности расшифровки - запрос отбрасывается на страницу авторизации. В случае даже гипотетического перехвата этого ключа, при попытке открыть /app - перекидывает на /one, т.к. в зашифрованном виде есть некий reload, который не позволит второй раз открыть страницу.
Не совсем понял -
Ну и сразу не нужно гонять session_id по вебсокету, его достаточно использовать в самом начале, при создании коннекта.
session_id создается по умолчанию в event connect и далее всегда передается от пользователя к серверу, ну точнее у меня в nodejs во всяком случае, всегда передается session_id, хотя в js на фронте - вообще не прописано его передавать. Т.е. в дебаге я всегда по умолчанию вижу session_id при любом типе сообщения websocket от клиента. Если имели ввиду user_id - тогда понял о чем Вы и полностью согласен.
Everything_is_bad, Спасибо за Ваше мнение. Я не с точки зрения критики, а чтобы разобраться.
Предположим злоумышленник изучает как работает приложение и его внутренние механизмы. Очевидно что в консоли он не увидит POST/GET запросы, тогда начнет ковырять WS. Включит логирование сети, увидит события ws в котором передается session_id соединения, id пользователя . Что помешает поменять id пользователя на свой, таким образом закрыв сессию реальному пользователю и получив доступ к данным пользователя? Это можно будет сделать прямо в браузере в консоли, прописав небольшой js который будет осуществлять такую подмену. Или я чего то не понимаю?
Как основу я использовал статейку хабра, но вместо jwt использовал собственную реализацию access token.
Достаточно сразу коннетиться к вебсокет, а на сервере разрешить только один коннект от телеграм id
Мне не очень нравится эта идея, т.к. в случае с зломышленниками, достаточно не сложно будет заняться перебором аккаунтов по ID. Поэтому сделан дополнительный ключ авторизации, который подтверждает что пользователь это тот пользователь, который изначально открыл приложение, а не который подменил WS данные в результате шаловливых ручек
Разнесение серверов авторизации и серверов приложения на разные инстансы. В случае падения серверов авторизации - уже действующие клиенты останутся подключенными.
А зачем эти one, two, бессмысленное шифрование, какой-то непонятный набор действий
На втором шаге также запрашивается пароль установленный пользователем. Не описал, т.к. посчитал не нужным.
В случае такого разнесения - в случае ddos долбежки, не теряется производительно других шагов. Как следствие не страдают уже работающие пользователи.
rPman, как правило для конференций используют webrtc для прямой связи между участниками чтобы уменьшить нагрузку на канал сервера. В том числе и вотсап использует, относительно недавно появилась настройка которая принудительно отключается webrtc и пускает трафик через сервера меты, т.к. через webrtc можно раскрыть ip собеседника, но как правило это сказывается на качестве связи
Komrus, на боровой 7с10, но тоже тир3.
Да холодный контур с фальш пола
Мы уточняли у инженеров что за шкафы такие - нам сказали что:
1) они имеют свою систему охлаждения
2) доп защита
Из того что мы поняли, эти шкафы имею свою дополнительную систему охлаждения с выдувом в вентиляцию, я просто не особо интересовался, но может это как то поможет ТС - типа серверный холодильный шкаф.
Основная стойка потребляет 21кВт, по мониторингу.
То что ЦОДы к топику отношения не имеют - не спорю, просто наблюдение - видел какой то серверный шкаф, выглядящий как холодильник, только для серверов. В теме стоек не силен, лично мое мнение - должна быть профессионально оборудовано помещение для размещения серверов с резервированием всего (ввод, охлаждение, интернет, влажность, контроль доступа)
Историю про уборщицу, которая отключила розетку чтобы подключить пылесос - я видел вживую)
У нас есть профессионально спроектированное помещение в офисе, проектировали и строили его правда в 2015-х года - 4 стойки (не считая коммуникационных), и одной стойки с батареями, как раз устроен холодный коридор с подачей холодного воздуха из пола, рециркуляции воздуха нет, в качестве охладителя стоят промышленные кондиционеры 3шт. с контролем влажности. , так вот на 2015 год, стоимость проектирования и реализации такого помещения стоила порядка 15 млн рублей (для помещения в 20кв.м). Мы нужного опыта не имеем в проектировании таких помещений - поэтому нанимали спецов. Просто на тот момент это были просто гигантские деньги, а на текущий момент я боюсь представить сколько это будет стоить...
У нас один из цодов на авиамоторной, у нас там пара шкафов в аренде. В машинном зале где наши шкафы, есть ряд, там штук 5-6 стоят АРС шкафы, полностью закрытые (сзади не знаю), но вверх от них идет вент.гофра и входит в вентиляционный канал. Никогда не понимал смысла таких шкафов в цоде.
С учетом того что у нас там 2 стойки 47u, до отказа забитые оборудованием, самая нагруженная стойка -
20х2 юинтовых серваков - 2х1.5 квт б.п.
2 сфп коммутатора, 2 rj45 коммутатора, органайзеры. ПДУ вмонтированны в шкаф.
Потребление думаю понятно, проблем с перегревом нет. Холодный коридор
Если говорить что нужно как то учитывать и в дальнейшем анализировать - я еще как то соглашусь с црм чистемой. А если функционал црм не нужен - то для бота поддержки очень жирно выходит, что по деньгами, что по ресурсам (если говорим про коробку).
Я за 3 дня написал бота, который видит все сообщения клиента и которому можно написать - и все это через веб. Могу поделиться, но для работы потребуется бд на mysql
Искатель, у нас развернут стахановец - домен не требуется. Но если уже есть домен, это хорошо, в целом при росте компании - будет меньше гемора все на него переделывать. А так не слушайте, свыше 20 сотрудников домен упрощает администрирование, особенно при шаре и текучке кадров. Я бы рекомендовал обратить внимание на платформу от supermicro. Crazy_Cooler, HP и DELL ничего против не имею, но зачем переплачивать? Не знаю как сейчас у HP, но когда мы выбирали вендора 5 лет назад - у HP совместимость только с HP процами была, оперативку тоже абы какую не поставить, а переплачивать за intel platinum только с шильдиком HP 40% ой как не хотелось. В итоге взяли платформу intel и накатили туда нужные нам комплектующие.
Александр, если он не меняет тип загрузчика - при установке fedora например, она бы точно поставилась бы в uefi, тогда странно что система не видит. Другая проблема, что система в принципе не видит другой диск, отличный от usb hdd
Hulk_228, после смены boot mode другой диск не видеться?
Если представить ваш скриншот в теме, если допустим нажать 2 раза стрелку вниз (навести на диск) и нажать enter, случаем не откроется меню выбора дисков ?
Drno, вот видимо и вся разница у нас тоже серваки в РФ, конкретнее VPN шлюз в ЦОДе в Мск, у нас просто чуть пожирнее, 3 стойки со своим оборудованием и серверами под сорм. Может поэтому мы может быть в какой то доверенной зоне для впн. Просто еще знаю что в одном из банков (достаточно известный) для сотрудников используют openvpn для доступа в инфраструктуру банка, и в целом нареканий по работе нет. Поэтому мне удивительно слышать что есть какие сбои. С другой стороны - был небольшой период времени когда некоторые клиенты не могли подключиться и вероятно проблема была связана с ТСПУ, но небольшие перебои наблюдались у небольшого количества клиентов, да и сама проблема продлилась не больше месяца. Потом опять как работало стабильно так и работает. Я то не в коем случае не настаиваю на своем решении, просто всегда интересно поговорить человеком в теме, услышать его опыт и поделиться своим)
Hulk_228, если отключить usb hdd и зайти в биос в бут какая картинка будет?
Не знаю как на вашем ноуте, но судя по тому что я вижу - система видит только один диск и это внешний usb hdd
Возможно есть вкладка disk boot priority, и там нужно вверх выставить нужный диск
Drno, вот как раз с зарубежными впн у меня часто проблемы были с РТ и МТС, в итоге xray vles, но это не корп история. А так у нас стойки в ЦОДе у РТ и для каждой стойки мы декларировали сервисы которые крутятся, может в этом дело
Привязка на бэке есть. Ситуация в другом, в случае переподключения пользователя (закрыл-открыл, или refresh), сессия закрывает и открывается новая. Старая сессия на бэке удаляется, новая записывается. Даже если не будем всё время гонять по вебсокету id пользователя, как нам проверять валидность\легитимность данных от пользователя? По session_id, но это будет вторичный признак. Если произойдет закрытие\refresh
- session_id - меняется. В таком случае, предположим я злоумышленник - я делаю "event": "connect" и перебираю user_id.
Просто смотрите, если я Вас правильно понял, то Вы имеете ввиду следующее:
После проверки initdata от ТГ и валидации user_id, создаем websocket соединения отправляя туда только user_id? Если я правильно понял Вашу задумку, в таком случае меня смущает что этот user_id ничем не защищен, и в случае перебора - пострадают пользователи, т.к. 1) их будет выкидывать из текущей сессии 2) данные от их аккаунта (в приложении) будут подгружаться туда, где их быть не должно. Или же Вы не дописали и подразумеваете дополнительные проверки?
Да, я знаю про jwt, в моём случае используя собственные знания - я еще более упростил эту задачу и получаю результат, как если бы я использовать jwt. В моем случае - все данные находятся в зашифрованном виде, и расшифровывать их может только бэк. В случае невозможности расшифровки - запрос отбрасывается на страницу авторизации. В случае даже гипотетического перехвата этого ключа, при попытке открыть /app - перекидывает на /one, т.к. в зашифрованном виде есть некий reload, который не позволит второй раз открыть страницу.
Не совсем понял -
session_id создается по умолчанию в event connect и далее всегда передается от пользователя к серверу, ну точнее у меня в nodejs во всяком случае, всегда передается session_id, хотя в js на фронте - вообще не прописано его передавать. Т.е. в дебаге я всегда по умолчанию вижу session_id при любом типе сообщения websocket от клиента. Если имели ввиду user_id - тогда понял о чем Вы и полностью согласен.