rPman

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

Переделывайте на как минимум 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

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

Так же добавить к ссылке хеш 'от нее плюс секретную соль', или используй ассиметричное ее шифрование, чтобы не дать ее взломать

у telegram есть api метод answerCallbackQuery для получения url по которому был вызов бота

соответственно идентификатор пользователя зашиваешь в параметрах ссылки https://t.me/your_bot?start=XXXX

Исходный сайт должен инициировать обновления цен в базах остальных в момент изменения (чтобы не делать наоборот, другие сайты периодически бездумно стучатся в базу основного с вопросом - изменились ли цены), т.е. буквально в момент когда в коде сайта идут обновления базы, дублировать вызов этих же запросов на подчиненных сайтах (тогда таблицы с товарами будут идентичны) - это фактически репликация базы данных в формате master -> slave но в 'ручном' режиме. Кода для этого понадобится совсем немного, понадобится разработкать какой то минимальный api для взаимодействия с подчиненными сайтами (буквально отсылка sql запроса, обязательно с авторизацией).

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

Даже если база данных не умеет реплицировать выбранные таблицы, можно настроить master->slave репликацию на новосозданную копию основной базы на подчиненных веб сайтах, и на них уже делать запросы в соседнюю базу (все базы данных позволяют обращаться в запросах к соседней базе данных, но могут не работать транзакции)

Незаметно - только на своей странице (мало того, даже iframe доступен только со своего домена).

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

Смотря что именно хочешь тестировать

В большинстве случаев (верстка от размера экрана и скорость загрузки на медленном интернете) можно проверить на любом десктопном браузере основанном на chromium (наверное теперь все на нем основаны) или firefox в отладочной консоли (нажми f12 и ищи кнопочку в виде смартфона, на firefox это responsive design mode ctrl+shift+m)

полное тестирование вместе с юзабилити нужно проводить на реальном железе, иначе бессмысленно

Измени подход к разработке, к имени скрипта добавляй версию, время последнего изменения или хешсумму например так main.js?3a7b (все веб сервера корректно это обрабатывают со статикой)

Делать это лучше простым скриптом, который запускать каждый раз перед тестами и при публикации релиза, так как эта проблема с кешем вылезет там ещё больнее