rPman

с примерами, максимально просто: https://www.w3schools.com/html/html5_audio.asp

p.s. платформы типа vk запрещают (в т.ч. техническими средствами) использование 'своих' мультимедиа данных на чужих платформах, что логично, с какой такой стати они должны тратить деньги на хранение и раздачу мультимедиа бесплатно?

поэтому сами файлы размещай на своем сервере или каким либо другим способом, подразумевающим это

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

т.е. у тебя УЖЕ есть сервер и тебе его просто запустить, открываешь документацию по этому серверу и работаешь (ее должны были написать те кто делал этот сервер), либо, если документации нет, изучаешь весь код

в документации по nodejs приведет сразу же пример простейшего веб сервера, ищи что то похожэее, смотри в каких файлах идет вызов и соответственно запускай этот код

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

npm install
npm build
npm run-script start

Т.е. install установит и обновит зависимости проекта, build запустит скрипты подготовки и оптимизации (например webpack), в общем что указано разработчиками, ну и запуск run-script start

И конечно, если это сделать в каталоге проекта в терминале, то закрытие терминала все закроет автоматически, поэтому это нужно будет прописать в виде сервиса systemd или каким то другим способом, принятом в твоей ОС

Куки - это механизм сохранения 'состояния' веб приложения, привязанное к пользователю, между сессиями его (приложения) использования.

Для собственно авторизации куки не обязательны, ведь это состояние можно передавать и через GET/POST запрос или #anchor ссылки или просто настройка кастомных заголовков (работает только для ajax запросов но не для обычных). Другой вопрос в том, что пользователи привыкли, что сайты сохраняют какое то время авторизацию и не требуют ввода логина и пароля уже для следующего посещения.

Да, это нормальная практика, если 'клиенты бд' (для веб это бакэнд) работают с ней не в монопольном режиме либо учитывают этот момент и самостоятельно отслеживают коллизии (такие ситуации редко бывают, обычно веб приложения сразу пишут правильно).

Отличный пример, если у тебя несколько веб серверов, являющиеся разным представлением одних и тех же данных, т.е. один из под форумов может быть блогом или галереей изображений на другом домене, с общей авторизацией (в этом случае для авторизации даже не надо заводить сущностей типа oauth, только шаблоны интерфейса менять). Подводных камней тут практически и нет, даже удобнее, единая админка и для модерации можно использовать готовые механизмы форума.

Естественно разработка этих проектов не может быть независимой, любые правки должны учитывать сразу все бакэнды и тестировать сразу все. Но очень часто, второй проект подчиненный, и правят в нем только шаблоны интерфейса.

Наличие в цепочке http означает что атакующий (к этому уязвима любая free wifi сетка или если пароль подобрать) может направить по следующему редиректу на любой свой домен, или исключить https на последнем звене и подменять содержимое сайта на свое. Само собой провайдеры тоже могут (и занимаются) чем то похожим, как минимум встраивая рекламу (привет ОпСоС-ы).

Чем опасен http - атакующий (и владелец веб сайта что в данном случае одно и то же) может атаковать локальную сеть пользователя сайта, сейчас это сложнее, в браузеры подкрутили по мелочи, но все есть ряд лазеек (например сделать запрос в админку на роутере, где сохранилась твоя сессия авторизации, в т.ч. к примеру изменять конфигурацию и добавлять свои правила, открывая еще более полный доступ злоумышленника в локальную сеть), так же атакующий может из браузера, в котором открыт http сделать DDOS-илку других сайтов в интернете (особенно если пользователей много), формально это можно сделать и с https но так проще. Ну и само собой, кража личных данных пользователя (пароль) к атакуемому сайту...

Осторожно, периодические опросы дают квадратичную нагрузку от количества пользователей.

Переделывайте на как минимум long pooling, тем более это проще чем городить полноценный websocket.

И да, не вздумайте в этом месте базу данных дергать, такая архитектура положит не слабый сервер уже с тысячами клиентов. Работайте с оперативной памятью или лучше, сделайте все же сервис, работающий не по принципу cgi (на каждый запрос запускает приложение) а по принципу демона с веб сервером. И уже тут в последствии можно на вебсокеты переделать

Всплывающее окошко использует iframe, этот тег 'надежно' защищает от доступа к данным со страницы, на которой этот iframe размещен от доступа.. т.е. ни какой информации вытащить из этого фрейма нельзя, но вот сам фрейм может вызывать методы на основной странице, это значит если их там подготовить, код из фрейма может выдавать то что необходимо основной странице. Т.е. страница во фрейме имеет доступ к кукам гугла, а значит авторизации, но вот основная странице нет... с оговорками:

Есть следующий вид атаки, например, ты заходишь на сайт злоумышленника, поиграть в игру, которая заключается в том что ты должен кликать в определенные области на экране (например быстро прокликать по появляющимся 'случайно' цветным кружкам), сайт злоумышленника в это время подсовывает в iframe атакуемый сайт, разместив его в полупрозрачном iframe (с прозрачностью 0.00000...) ровно в том месте, куда пользователь должен кликнуть мышкой. Пользователь думает что кликает на квадратик, но на самом деле кликает на страницу атакуемого сайта. Основной сайт не знает, что происходит на странице атакуемого, кликнул ли пользователь реально или нет, но может делать об этом предположение, заранее проверив, в каких местах атакуемого сайта находятся нужные атакующему элементы.

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

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

До нескольких терабайт, при условии что сайтом очень активно пользуются, сотни мегабайт трафика и т.п. - самое дешевое это использовать свое хранилище, на основе hdd (при большой нужде - ssd), настраивать raid1 или raid5, используя минимально возможное количество дисков на массив (т.е. если 10 дисков то делать либо 2 рейда по 5 дисков либо три по 3 диска, не делать один огромный рейд - особенно если это hdd, он будет медленный). Хранить в виде файлов как они должны отдаваться, метаинформацию - в базе данных.

Если дисков в своем хранилище больше 20, или если сетевой трафик очень маленький, условно за сутки один-два пользователя смотрят фоточек на десяток другой гб. либо если суммарно хранимый объем превышает десятки-сотни терабайт, то строить свое хранилище становится значительно дороже и лучше идти в облака. Самое популярное это амазон s3, в его формате такие услуги предлгают и российские провайдеры типа селектела или яндекса. Тарификация там двойная - за сетевой трафик (по разному на загрузку и выгрузку) и за хранение от объема.

В другом ответе все необходимое уже сказано, добавлю

- организационный, вы пускаете за один и тот же компьютер людей по очереди, определяя следующего человека вручную.
Развиваем идею:
* добавить удаленный доступ по rdp/vnc/rustdesk/... чтобы пользователям не требовалось физически подходить к компьютеру
* добавить автоматическое управление правами у пользователей (для rdp это штатные пользователи ОС, скрипты будут по нескольку строчек хоть на батниках), отбирая права у всех и выдавая право очередному пользователю по списку

Веб приложения максимально оптимизированы при работе с файлами на диске.
Никакой другой метод не позволит дать такую производительность.

Поэтому - авторизацию доступа делай на уровне веб сервера (вот пример с нормальным oauth)

Для удобства обслуживания всего архива, раскидывай файлы по подкаталогам таким образом, чтобы в одном каталоге было не больше десятков тысяч файлов (иначе получение списка файлов будет медленным).

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

Тупой пример - числовой идентификатор переводи в hex, дели на группы по 4 символа и создавай соответствующие каталоги: /images/0d4f/3b00/a841/0d88, тут 0d88 это файл, остальные части - каталоги. Идентификатор соответственно 64-битное число 0x0d4f3b00a8410d88

Недостаток подхода, так как хранилище не входит в транзакционную базу данных, за целостностью приходится следить самому, т.е. если удалили запись в базе, то запись на диске не удалять а перемещать во временное место, пока не завершится транзакция, при успешном завершении файл удаляется окончательно (на самом деле ОС будет его еще держать какое то время доступным, если файл открыт пользователем, т.е. в данном случае веб сервер но нужно еще проверить, не закрывает ли он его каждый раз как отсылает часть), ну а если транзакция сфейлится, то файл нужно будет вернуть назад. Само собой следить за этим местом при запуске сервиса после сбоя.

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

Мое мнение - абсолютно бесполезен (из-за особенностей реализации и избытка функционала).

Главная фича git и других систем контроля изменений - это контроль за изменениями, возможность быстро откатиться к нужной версии, мержить версии, переносить изменения из одной ветки в другую и т.п. и все заточено на работу с текстом. большие файлы - это про бинарные или не редактируемые данные. Даже sql дампы таким образом адекватно не будут обработаны (пример - добавлена колонка)

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

git-lfs работает очень не эффективно, банальный git clone репозитарием из 20-гигабайтовых файлов требует сравнимый объем оперативной памяти, потому что там на любой файл идет diff/patch, что бессмысленно для бинарных файлов в подавляющем большинстве случаев.

Все зависит от плеера, у каждого свои механизмы

Например у mpv (потомка mplayer) есть возможность управлять им, симулируя нажатия на кнопки (как я помню через stdin пайпом от своего приложения) и используя плейлист через пайп или тот же stdin, формируя его на лету своим приложением

по нормальному mpv поддерживает скриптовые плагины на lua, есть плагин mpv-network-commands так что любое поведение можно запрограммировать

Добавлю к отписавшимся, если приложение exe подписать ключом, выданным майкрософт ($100 кажется плюс заморочки) то на запуск такого приложения потребуется 1 клик подтверждения (без подписи 2 или 3, в зависимости от браузера), просто предложив этот .exe на загрузку, указав его файл в ссылке

10.xxx.xxx.xxx - это частные адреса и снаружи видеть их никто не может

на фаерволе нужно настроить перенаправление 3000 порта на твой локально установленный сервер либо настроить какой-нибудь прокс-веб-сервер, например nginx это умеет

Html map