Что-то не понятное здесь твориться, ребята 🙂 Авторизация по MAC внутри частной сети, в которой каждый участник может этот MAC узнать через таблицу ARP, это мало того что супер ненадежный инструмент, так как
- MAC адрес устройства, дело самого устройства и ему решать какой слать
- любой участник сети может узнать mac адрес другого участника через ARP
- не применим к веб-сервисам в интернете, так как не способен оперировать MAC адресами

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

я описал единственный случай когда эта авторизация допустима.
и это реально так было несколько лет назад, как сейчас я не знаю.

Система хостится в одной плоской сети вместе с пользователями?
Допустимо ли что любой юзер может логинится под другим, это не проблема?

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

я зашел в чат, все видят, юзер номер 23. если отправят на 23 номер сообщения, то получу я. сообщения сразу

а как разруливать проблемы от NAT? Условно говоря, целый бренч какой-нить крупной компании с офисом на тысячи человек, будет ходить к вам под одним IP

что говорить юзеру, который пытается зайти в тот же чат, с таким же IP?

в таких случаях мы расширяем код и учитываем айпи + часть номера порта связи

не очень понял что такое "номер порта связи"

а откуда у внешнего сервиса данные о порте?

в пакете не указано разве?

хорош рофлить, какой IP, фингерпринт и ник

тут даже думать не надо npm i

даже если нет, ток мак + айпи

если речь про Source Port в пакете, то там будет, что туда решил подставить NAT, и не факт что следующая TCP сессия будет с таким же портом

оу, да об этом. не знал

а я про про порт железки уже думала -_-

не)

😱 …