FanatPHP

1. Правильно. В инете есть куча статей (как и ответов на тостере), которые преподносят эту фигню как панацею.
2. Я бы и сам был не против посмотреть, как это обойти. Возможно, она обходится не в лоб. зачем-то ведь есть строчка list ($foo,$ext) = getnameUpload($myFile["name"]); при том что результат нигде не используется. Возможно, дальше проверяется именно $ext, и надо смотреть код getnameUpload

Какой-то странный вопрос. "новая php страница" заведомо означает перезагрузку.
То есть либо новая страница не РНР, либо у автора, скорее всего, какая-то другая кривизна и ему нужно совсем другое решение.

select login, count(*) cnt from таблица group by login having cnt > 1 order by cnt desc

Очередная жертва видеокурсов.

Всем задающим вопрос про тухлую фасоль надо насильно отключать Ютуб, давать книгу Котерова, и не включать пока не прочитают.

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

Потому что случайные.
Кому-то здесь надо уяснить для себя смысл этого слова. И явно не одному автору.

Случайно тут могут оказаться не то что "близкие" а вообще одинаковые значения.

Как-то неказисто, но ничего кроме strrev в голову вечером не приходит

strrev(chunk_split(strrev(11223344556677), 4, ' '));

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

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

По поводу капчи.
На сайт надо ставить только то, что нужно.
Тебе сейчас капча не нужна? Вот и не ставь.

1) Почему данные в малой таблице читается медленнее, чем в большой?
2) Скорость чтения бд в маленькой таблице. Она гораздо выше скорости работы с большой

Это всё что вам надо знать про многочисленных любителей тестировать производительность на пустом месте вообще и про этот вопрос в частности.

Я так и не понял вопроса.
Если верить тем формулировкам, которые осилил родить автор - "в бд ничего не меняется." и "строки не создаются" - то проблема совсем другая и поля автоинкремент тут не при чем. Но ответ принят. Получается проблема была в том что автор был не в состоянии посмотреть что у него лежит в БД?

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

Отличная идея писать вопрос не приводя никакого кода.

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

например так https://symfonycasts.com/screencast/symfony2-ep2/a... или так
https://stackoverflow.com/questions/9550079/how-to... ну и далее по ссылкам.

Даже не заходя в вопрос сразу можно догадаться, что будет внутри.

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

Функции, которая берет IP адрес... из НТТР заголовков. Из запроса. То есть, чтобы подделать айпи, не нужно даже прокси - достаточно добавить к НТТР запросу заголовок CLIENT_IP с рандомным айпишником.
Гениальное решение для защиты.

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

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

О господи, опять этот вопрос.

Запрос никак не защищать.
Если пользователь может видеть запись 666, то пусть смотрит что хочет.
Если пользователь не имеет права видеть запись 666, то получив любой запрос проверять его на наличие прав. А изменение запроса оставить в покое. Клиент по определению может отправить любой.

К CSRF это абсолютно безобидное ковыряние в хтмлочке никакого отношения не имеет.