Проблема может быть даже при доступе с одного устройства. Если бы все было так просто, можно было хранить различающиеся IP для каждого устройства пользователя, с которого он входил.
Время сеанса автоматически продлевается при каждом запросе или при приближении к expired. Если пользователь отошел попить чайку, это его проблемы. Все делается для безопасности его данных, финансовых средств и т.п.
Можно использовать код "возобновления сеанса". Как с недавних пор делает Сбербанк.
Даже при использовании JWT обычно нет необходимости хранить данные прямо в токене. Достаточно идентификатора пользователя. Если не хотите его "опубличивать" (здесь речь уже не про JWT), можете "солить" в индивидуальном порядке и динамически менять соль между сеансами.
С IP могут быть определенные проблемы. Иногда встречаются провайдеры, которые могут менять IP в течение одного (по крайней мере с точки зрения пользователя) Интернет-сеанса. Не знаю, с чем это связано. Плохая связь или что-то другое.
Вот это хорошо. В основном так и защищаются. Конечно, токен должен быть достаточно длинным.
Я тоже не согласен с "проблем не будет", но зачем так резко выражаться? 😊
И я не понял. Зачем-то подняли 10-летнюю тему со своим вопросом и к вечеру уже стали знатоком в этом вопросе 😀 В SPF домена нужно перечислить все источники, с которых могут отправляться письма с адресами отправителя на этом домене. Способ обозначения источника выбирается такой, какой удобнее для конкретного источника (или группы источников).
Тема 2014 года.
Все-таки лучше указывать "имя сервера", а не почтовый домен. Обычно в качестве имени сервера используют домен третьего уровня. Но это не требование, а просто распространенная практика. Можно и второго. В этом случае вероятность совпадения имени сервера с одним из почтовых доменов выше.
Даже так? )
Тогда нам с вами не о чем говорить. Хотя формально MVC != единая точка входа 😉
Ну, чисто теоретически, можно что-нибудь придумать и для множества точек входа. Но из реального опыта ничего не подскажу. Это было очень давно.
От ВКонтакте не нужна. Ее заменяет обычная ссылка на страницу ВКонтакте.
Люди перешли на общение в чатах социальных сетей, мессенджеров и т.п. Можете "забрасывать крючки" наподобие "отвечаю только у себя в комментариях (ссылка)". Если кому-то интересны именно ваши комментарии, люди подтянутся.
Да. Основные "базы" обычно определяются прямо в единой точке входа (фронт-контроллере) через __DIR__ (или __FILE__), чтобы уже на их основе подключать конфигурационные файлы. Только корневой каталог - это не основное в профессиональных проектах. В них в качестве основной базы определяется либо целиком каталог проекта, либо его подкаталог с программными файлами (исключением может быть единая точка входа и другие точки входа наподобие cron.php или cli.php, которые могут располагаться прямо в каталоге проекта; из-за ограничений хостинга единая точка входа может располагаться и в корневом каталоге).
Если у вас взаимоположение единой точки входа и конфигурационного файла с определениями "баз" всегда фиксировано, можете подключить этот конфигурационный файл непосредственно при помощи __DIR__.
Это правильно. На одном хосте может быть несколько почтовых доменов.
Укажите в качестве имени хоста нормальный домен (зону vds я не нашел) и пропишите его в PTR.
Если сами не сможете разобраться, обратитесь к тому, кто сможет.
Я тут не понял. Речь о клиентских шаблонах?
Сначала рассмотрим серверные шаблоны. В них добавляется содержимое из трех мест:
* обычно я использую программные файлы (PHP), но можно, наверное, и разбираемые программно; и точно можно SQL/NoSQL.
Клиентские многоязычные шаблоны генерируются из одного серверного с пропуском основного содержимого (т.е. за вычетом пункта 1). В итоге получается ваш вариант 1. Здесь используется обычное серверное кэширование.
Всю тему не читал.
