Доработка веб-приложения php+mysql

Есть маленькое веб-приложение php+mysqli mysql. Пользователь авторизуется, после чего просматривает единственную табличку с данными. Черновик приложения сделан, есть некоторое количество пожеланий по доработке. 

Текущий объем кода 4 кб php в форме логина (107 строк), 10.7 кб php кода в основной форме (255 строк). 

Таблица с данными в основной форме довольно сложная, но ее переделывать не надо.

Будет дан FTP доступ и доступ к PHP My Admin. Программист сдает работу на проверку, и финальную версию работы, заливая код на ФТП.

Оплата - Сбер, или ЯД, или обсуждается. Желательна постоплата без безопасной сделки. Аванс возможен, если у Вас много хороших отзывов. Если хотите, возможно разбиение работы на этапы, с отдельной оплатой каждого этапа.

Предполагаю объем работ 1-3 дня, стоимость от 5 до 20 тыс. руб., зависит от предложений.

Предполагается использование чистого php + js. jQuery _не_ используем. При желании, можно использовать реакт, но лучше без него. Для подключения в проект сторонних библиотек обязательно согласовать это с заказчиком, т.к. проект является частью корпоративной среды, и когда в каждом проекте фирмы свой набор библиотек/компонентов, это неправильно. 

Доработки

1.1. В основной форме скролл влево-вправо должен менять дату ($_SESSION['current_dd']) на единицу. Сейчас скролл есть, но работает глючно. Надо или исправить существующий, или сделать новый, а старый удалить. Дата может меняться от $_SESSION['min_dd'] до $_SESSION['min_dd']+13 дней. При этом алгоритм формирования таблицы с данными в основной форме менять не надо.

2. Авторизация должна работать так: пользователь вводит email, нажимает кнопку, получает на указанный емэйл случайный числовой пароль, вводит полученный пароль, нажимает кнопку, авторизация завершается.

Сейчас авторизация работает, но есть ряд недоработок:

2.1. Форма ввода email и форма ввода пароля сейчас совмещены, а должны быть раздельными формами.

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

2.3. Сейчас срок действия авторизации никак не проверяется. Надо, чтобы пароль, который пользователь получил на почту, действовал 1 месяц (если пароль с тех пор не обновлялся). 

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

2.5. Ограничение на кол-во попыток ввода пароля ("Допускается не более трех неудачных попыток ввода пароля. Вы будете возвращены к вводу email").

2.6. Ограничение на частоту отправки email ("Посылать себе новый пароль можно не чаще, чем раз в 5 минут. Следующая попытка будет доступна через **:**"). Не уверен, что этот пункт вообще нужен, но давайте сделаем

2.7. Крякозябры в письме. Сейчас письмо с паролем приходит ОК, тема письма при этом отображается по русски ОК, а в теле письма русские буквы отображаются крякозябрами. Надо исправить.

3. Натянуть верстку. Дизайнер нарисовал формы, верстальщик сверстал, надо все это дело натянуть на формы. Перечисляю формы: форма ввода логина, форма ввода пароля, диалоговые окна, шапка основной формы (логотип и надписи в шапке). Таблица в основной форме полностью сделана, в ней ничего менять не надо.

4. В основной форме отрабатывать двойной клик на заголовке (Текст "Выберите действие", кнопки "Отключиться" и "Обновить экран (аналогично скроллу вверх/вниз)")

5.1. Автообновление. В основной форме раз в 15 минут (частоту берем "SELECT const_val FROM constants where const_id=1") проверять наличие новых данных на сервере. Т.е. при выводе основной формы, сохраняем на фронт-энде хэш-сумму таблички. Раз в 15 минут фронт-энд посылает на сервер хэш-сумму, если она изменилась, то сервер возвращает табличку с новыми данными, если хэш-сумма не изменилась, то рефреш не делаем. Если браузер открыт в фоне (т.е. пользователь сейчас смотрит что-то другое, и не видит основную форму), то, наверное, имеет смысл проверку наличия новых данных отложить до того момента, когда пользователь в браузере вернется к закладке с основной формой.

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

5.3. Если при авторефреше основной формы если текущая дата ($_SESSION['current_dd']) меньше чем сегодняшнее число, задаем $_SESSION['current_dd']=Сегодня. Если при авторефреше минимальная дата $_SESSION['min_dd'] меньше чем сегодняшнее число, задаем $_SESSION['min_dd']=Сегодня. 

6. В основной форме во второй строчке шапки выводится время последнего обновления данных. Надо сделать его разными цветами: 1) зеленый = данные обновлены менее 30 мин назад 2) желтый = данные обновлены от 30 мин до 24 часов назад 3) красный = данные обновлены более 24 часов назад.

7. Добавить параметр $_SESSION['inner_width'], равный внутренней ширине окна браузера в пикселях. Обеспечить его актуальность при логине и ресайзе. При ресайзе делать рефреш основной формы. При этом как-либо менять алгоритм вывода таблички не надо, я потом поменяю (будет меняться кол-во отображаемых колонок).

8. При необходимости, разбить index.php на несколько файлов. Например, можно js вынести из index.php в отдельный файл, и т.п. Этот пункт делать не обязательно, посмотреть, обсудить, если решим что надо, то сделать.

9. Проверить код на устойчивость к атакам. sql injection, и т.п. Минут 30 помедитировать над кодом на тему "можно ли это взломать". Если найдете уязвимости, и их можно легко исправить, то исправить. Если найдете уязвимости, которые исправить сложно, то обсудить стоимость доработки.

10. Авторизация через смс, вместо email. https://www.epochta.ru/products/sms/sms-api . Добавить в проект функцию, которая будет посылать заданную смс на заданный номер. function send_sms($phone_to, $sms_text); Переделать авторизацию, исходя из предположения, что пользователь может ввести или мэйл, или телефон. Если пользователь ввел мэйл, посылаем пароль письмом, если телефон, посылаем пароль в смс. Логин-пароль от epochta предоставляется после выбора исполнителя.

11. Дополнение: я спросил поставщика, они сказали, что если я хочу много одновременных пхп сессий поддерживать, то мне нужно на более дорогой аккаунт переходить. Т.е. желательно сессии использовать только для авторизации (получения токена), а после этого хранить кукис с токеном у клиента, без сессии