Nwton

Код кладем в базу как есть, меньше читаем про загадочный код который может "повредить базу", больше про PDO и prepared statement. Все косяки могут всплыть только при выводе, если там будет какой-то кривой код - вся хрень произойдет на клиентсайде.

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

Вариантов 2:
1) API удаленного сайта с возможностью принимать запросы с данными(если не в курсе - гуглить API)
2) Настроить доступ к базе удаленного сервера извне, конектиться к нему напрямую и вносить данные прямо в бд.

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

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

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

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

Давайте поставим теперь себя на место злоумышленника. Располагая всем этим, как бы мы взламывали пароль?
1. Радужные таблицы (заранее сгенерированные таблицы "хэш -> значение").
2. Атака по словарю (сначала делается перебор по наиболее вероятным значениям).
3. Полный перебор.
Полный перебор хоть и решит задачу 100%, но это крайняя мера, крайне неэффективная, и, как правило, не рабочая, потому что пусть пароль и можно подобрать за десятки тысяч лет, злоумышленник столько не проживет (как и сама взламываемая система, и сам пользователь). Потому если мы обезопасились от пунктов 1 и 2 кое-как, то задачу, считай, решили.

Если мы просто возьмем какую-то хэш-функцию (например, sha256) и захэшируем пароль, то сделаем очень плохо. Почему? Потому что злоумышленник, видя это, просто возьмет хэш и подставит в радужную таблицу, и, если пользователь не заморачивался с паролем (а как правило так и есть), то пароль будет получен практически сразу.

Что нужно сделать, дабы исключить вариант использования радужных таблиц?
Сделать так, чтобы значения, подаваемые на вход хэш-функции, гарантированно в них отсутствовали. Для этого и придумали соль. В связи с этим к соли есть одно простое требование: соль должна быть сложно угадываемой.
То есть, если у нас есть пароль "password" и соль "111", то вероятность попадания строки "password111" в радужную таблицу все ещё очень высока, а значит подобная соль плохая. А вот соль "t%Lp-,DU4=w],9c7F.N$" хороша, потому что строку "passwordt%Lp-,DU4=w],9c7F.N$" в радужную таблицу никто записывать не будет.
Вывод: нам нужна соль для того, чтобы исключить поиск по хэшу в радужных таблицах.

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

Далее в арсенале злоумышленника остается атака по словарю.
Увы, полностью исключить данный вариант может только пользователь, если будет использовать стойкие и сложные к угадыванию пароли, у которых вероятность попадания в словари "крайне мала"(с).
Но на благоразумие всех пользователей надеятся не стоит, а обезопасить их как-то надо. И здесь у нас остается возможность "вставить палку в колесо" злоумышленнику, увеличив время выполнения алгоритма. То есть просто берем и хэшируем результат повторно надцать раз, пока время выполнения алгоритма не станет достаточно длинным, например, 500ms. Нам при аутентификации пользователя (да и самому пользователю) 500ms ждать не проблема, а вот злоумышленнику делать подбор пароля со скоростью 2 пароля за секунду, уже "ой-какая-головная-боль".
Вывод: повторяем хэширование много раз, дабы увеличить время выполнения алгоритма, что замедлит подбор паролей.

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

Дабы реализовать все вышесказанное, к велосипеду ручонки тянуть не нужно, именно из-за вышеуказанных "заморочек" в деталях алгоритмов. Криптография дилетанства не прощает. Тем более, что уже есть де-факто промышленные стандарты.
Например, bcrypt алгоритм (спасибо kpa6uu за упоминание). В PHP он реализован посредством стандартной password_hash() функции. В других языках тоже хватает реализаций.

Ну и наконец-то отвечая на Ваш вопрос "как лучше всего?", то на данный момент это алгоритм Argon2, победитель последнего Password Hashing Competition. С реализациями в языках, к сожалению, пока что не так все радужно как у bcrypt.

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

frontender.info/es6-in-depth-arrow-functions/#chto...

https://jsfiddle.net/space2pacman/yL1cffct/4/

document.getElementById - самый быстрый
querySelector & querySelectorAll - самые медленные из нативных

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

querySelector используй
document.querySelector('.class')
Получаешь сразу уникальный элемент, т.к. он выберет первый попавшийся

Для такого используйте querySelector
var el = document.querySelector(".myclass");

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

Банальный запрос socket.emit('register');уронит ваш сервер с ошибкой, так как data будет undefined (null и undefined не могут иметь свойств)
Аналогично для data.login
Метод replace есть только у строк, вызов не функции так же выкинет ошибку

Правильно как то так:

const LOGIN_REGEX = /[^a-zA-Z0-9]/; //скомпилим регулярку заранее, дабы не компилить при каждом запросе
socket.on('register', function(data){
  if(!data || typeof data.login !== 'string') { return; } //проверка на наличие и правильный тип
  if(data.login.length < 4 || data.login.length > 12) { return; } //проверка на допустимую длину, числа ставьте свои
  if(LOGIN_REGEX.test(data.login)) { return; } // такая проверка в 18 раз быстрее чем у Вас
  new User({login: data.login}).save();
});

1. Что если login - не строка, буль на пример?
2. Допустим ли логин 0000000?
3. Допустим ли логин из одного символа?
4. Что если в data логина в принципе нет? Emit может быть вызван где угодно.

Вообще в целом это же не sql, где можно нагадить изменив строку.

Но могут быть проблемы если допустим login в дальнейшем где-то выводится без использования шаблонизаторов и т.п.
Там может быть банальный <script>
Т.е. xss.

Ну с таким фильтром вроде не пролезет.
Больше я не вижу вариантов для каких-то уязвимостей.

Единственное что здесь можно сделать это заспамить.
Наemitить в этот кусок >9000 фреймов и будет создано столько же пользователей.

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