Александр Кошеверов: из практической реализации - локальный (главный) гитсервер подключается (тут тоже масса вариантов/реализаций) к удаленному хосту (вебсервер) и на веб сервере выполняется pull (получаете последнюю версию)
Из плюсов можно перед пуллом проверить результат локально.
С базой все намного сложнее, проблемы вы видите. Я думаю это не входит в плоскость обновления, это скорее ведение оффлайн базы. С последующей догрузкой на сервер. Я бы с этой стороны подходил к решению проблемы. То что меняет структуру - апдейт скрипт, касательно данных - обновление оффлайн собранных данных.
rework: Вы упустили суть вопроса, Василий Петров: не спрашивал где взять готовое решение и у кого заказать разработку. Вопрос был
что с безопасностью? И какую программу, каков ее принцип? На каком языке и тд?
Во вторых, почему бы Вам не предложить другой вариант на другом языке программирования ?
И в третьих, а с чего вы взяли что это оверсложная задача для новичка ? это 2й и 3й шаги после "Hello World" тем более что он
Василий Петров: Добавлю: Как пример, обратите внимание, что получение контактной информации об отправителе в уведомлениях возможно только при использовании протокола HTTPS. При использовании протокола HTTP контактные данные в уведомлении передаваться не будут.
Василий Петров: Выбираете кошелек, читаете АПИ, выбираете приемлемый метод, реализуете. Для новичка сложностью будет HTTPS, так как там есть много подводных неявных камней, а отладка осложнена шифрованием. А так все достаточно просто, в некоторых системах (не смог сразу вспомнить конкретно какие) требуется криптоответ вашего принимающего сервера, но и с этим не должно возникать проблем, пара дней и у Вас готовое решение
Думаю что сложно ничего нет.
1) подключить базу данных и разобраться на PHP как добавлять и получать записи (для последующего вывода на странице)
2) Научится оперировать запросами POST/GET для простоты отладки и обучения использовать метод GET его можно корректировать прямо в адресной строке браузера. Прикрутить туда пару строк с добавлением в БД
3) переключить тип запроса на POST и потренироваться с API Яндекса.
С перерывам на чтение/изучение команд можно управиться за полдня
Для этого и добавляем доп информацию в куку. Теперь для авторизации такой кукой нужно не только ее значение но и совпадение IP, браузера, разрядности и всего того что вы можете определить и заложить туда. (например добавление только IP значительно осложняет подложную авторизацию) Повторюсь, выбор за вами разрешать или нет авторизацию кукой с разных IP/браузеров итд.. но суть не в этом. Вы создаете и храните необходимые данные на устройстве пользователя, в зашифрованном виде. Это альтернатива хранению копии куки в базе данных. Все тоже самое можно проделывать храня значение куки в базе данных. А чтобы это работало придется вести в бд таблицу авторизаций посетителя и делать из нее выборку
если сервер выделенный/виртуальный linux то /var/log/mail.log
если просто хостинг, то это задача хостера. Это если упростить.
Я же задал Вам лиш направление. Одна из целей взлома сайта/сервера - рассылка спама.
Вам обязательно надо отслеживать изменения на сайте, на предмет новых файлов. Не факт что вы излечились от заразы годовалой давности. А еще есть уязвимости, которые могут быть использованы для повторного заражения. Забирайте логи с сервера регулярно, чтобы в последствии попытаться выяснить путь, которым зараза проникнет на сайт.
У Вас ситуация проще, есть дизайнер который использовал некий шрифт, при некоторой настойчивости можно разобраться в проблеме. И Выяснить что это был за шрифт.
Антон: Благодарю за проявленную внимательность, но конкретно в этом случае Вы не правы. Назначить сначала пароль с помощью команд grant или set password не получится, так как в режиме skip-grant-tables их нельзя использовать.
SET @variable=last_insert_id() ;