а по поводу записей доменной зоны У меня они такие: A @ root-ip (как правило там сайт)
A mail "IP сервера почты"
MX mail.maindomain.ru. 10
TXT-SFP vspf1=1 ipv4:192.192.192.192 mx ~all - для главного почтового домена, для IP которого есть PTR
TXT-SFP vspf1=1 ipv4:192.192.192.192 mx mx:mail.maindomain.ru ~all - для всех второстепенных доменов, юзающих тот же сервер
Я бы так активно (или вовсе) не использовал mx в SPF. Свои серверы и сети ты обозначаешь при помощи ip4 (не уверен, что допустимо ipv4), а сторонние - при помощи include. Если используешь только сторонние одного провайдера, тогда просто redirect= 😉
ferinra#: Ну, скажем так, я кажется понял, что майл ру просто противопоставляют себя остальному интернету, и являются самым архаичным, самым громоздким и неповоротливым монопольным проектом, ассоциирующим себя со всем рунетом.
А по-моему этот сервис вполне лоялен, если следовать простым, уже практически стандартным на сегодняшний день, правилам. Gmail построже будет. В нем без "стадии обучения" на "не спам" практически не обходится. А в Mail обычно достаточно заглянуть в postmaster, чтобы в очередной раз убедиться, что все в порядке.
ArbNet#: так делают только начинающие, которые потом сталкиваются с ограничением доступа к сайту с разных устройств.
Проблема может быть даже при доступе с одного устройства. Если бы все было так просто, можно было хранить различающиеся IP для каждого устройства пользователя, с которого он входил.
ArbNet#: Это тоже плохо, вы заставляете пользователя постоянно авторизоваться.
Время сеанса автоматически продлевается при каждом запросе или при приближении к expired. Если пользователь отошел попить чайку, это его проблемы. Все делается для безопасности его данных, финансовых средств и т.п.
Можно использовать код "возобновления сеанса". Как с недавних пор делает Сбербанк.
Sly32 : который содержит необходимые данные/права пользователя
Даже при использовании JWT обычно нет необходимости хранить данные прямо в токене. Достаточно идентификатора пользователя. Если не хотите его "опубличивать" (здесь речь уже не про JWT), можете "солить" в индивидуальном порядке и динамически менять соль между сеансами.
С IP могут быть определенные проблемы. Иногда встречаются провайдеры, которые могут менять IP в течение одного (по крайней мере с точки зрения пользователя) Интернет-сеанса. Не знаю, с чем это связано. Плохая связь или что-то другое.
Sly32#: Это само собой, даже меньше у меня будет. Активная сессия - не более получаса.
Вот это хорошо. В основном так и защищаются. Конечно, токен должен быть достаточно длинным.
ferinra#: Есть большое количество других нюансов, про которые вы, вероятно, понятия не имеете.
Я тоже не согласен с "проблем не будет", но зачем так резко выражаться? 😊
И я не понял. Зачем-то подняли 10-летнюю тему со своим вопросом и к вечеру уже стали знатоком в этом вопросе 😀 В SPF домена нужно перечислить все источники, с которых могут отправляться письма с адресами отправителя на этом домене. Способ обозначения источника выбирается такой, какой удобнее для конкретного источника (или группы источников).
Все-таки лучше указывать "имя сервера", а не почтовый домен. Обычно в качестве имени сервера используют домен третьего уровня. Но это не требование, а просто распространенная практика. Можно и второго. В этом случае вероятность совпадения имени сервера с одним из почтовых доменов выше.
От ВКонтакте не нужна. Ее заменяет обычная ссылка на страницу ВКонтакте.
Люди перешли на общение в чатах социальных сетей, мессенджеров и т.п. Можете "забрасывать крючки" наподобие "отвечаю только у себя в комментариях (ссылка)". Если кому-то интересны именно ваши комментарии, люди подтянутся.
Leema : как мне зафиксировать BASE_DIR так, чтобы она была определена еще до всяких инклюдов? это реально вообще?
Да. Основные "базы" обычно определяются прямо в единой точке входа (фронт-контроллере) через __DIR__ (или __FILE__), чтобы уже на их основе подключать конфигурационные файлы. Только корневой каталог - это не основное в профессиональных проектах. В них в качестве основной базы определяется либо целиком каталог проекта, либо его подкаталог с программными файлами (исключением может быть единая точка входа и другие точки входа наподобие cron.php или cli.php, которые могут располагаться прямо в каталоге проекта; из-за ограничений хостинга единая точка входа может располагаться и в корневом каталоге).
Если у вас взаимоположение единой точки входа и конфигурационного файла с определениями "баз" всегда фиксировано, можете подключить этот конфигурационный файл непосредственно при помощи __DIR__.
как они это делают – в смысле цифры разгадывают?!
Могут и не разгадывать (каждый раз), а просто нужные куки подставлять. "Самодельные, простенькие" капчи этим часто страдают.
а по поводу записей доменной зоны
У меня они такие:
A @ root-ip (как правило там сайт)
A mail "IP сервера почты"
MX mail.maindomain.ru. 10
TXT-SFP vspf1=1 ipv4:192.192.192.192 mx ~all - для главного почтового домена, для IP которого есть PTR
TXT-SFP vspf1=1 ipv4:192.192.192.192 mx mx:mail.maindomain.ru ~all - для всех второстепенных доменов, юзающих тот же сервер
Я бы так активно (или вовсе) не использовал mx в SPF. Свои серверы и сети ты обозначаешь при помощи ip4 (не уверен, что допустимо ipv4), а сторонние - при помощи include. Если используешь только сторонние одного провайдера, тогда просто redirect= 😉
Вот это тоже перепроверьте: vspf1=1 😉
Ну, скажем так, я кажется понял, что майл ру просто противопоставляют себя остальному интернету, и являются самым архаичным, самым громоздким и неповоротливым монопольным проектом, ассоциирующим себя со всем рунетом.
так делают только начинающие, которые потом сталкиваются с ограничением доступа к сайту с разных устройств.
Проблема может быть даже при доступе с одного устройства. Если бы все было так просто, можно было хранить различающиеся IP для каждого устройства пользователя, с которого он входил.
Это тоже плохо, вы заставляете пользователя постоянно авторизоваться.
Время сеанса автоматически продлевается при каждом запросе или при приближении к expired. Если пользователь отошел попить чайку, это его проблемы. Все делается для безопасности его данных, финансовых средств и т.п.
Можно использовать код "возобновления сеанса". Как с недавних пор делает Сбербанк.
который содержит необходимые данные/права пользователя
Даже при использовании JWT обычно нет необходимости хранить данные прямо в токене. Достаточно идентификатора пользователя. Если не хотите его "опубличивать" (здесь речь уже не про JWT), можете "солить" в индивидуальном порядке и динамически менять соль между сеансами.
С IP могут быть определенные проблемы. Иногда встречаются провайдеры, которые могут менять IP в течение одного (по крайней мере с точки зрения пользователя) Интернет-сеанса. Не знаю, с чем это связано. Плохая связь или что-то другое.
Это само собой, даже меньше у меня будет. Активная сессия - не более получаса.
Вот это хорошо. В основном так и защищаются. Конечно, токен должен быть достаточно длинным.
Есть большое количество других нюансов, про которые вы, вероятно, понятия не имеете.
Я тоже не согласен с "проблем не будет", но зачем так резко выражаться? 😊
И я не понял. Зачем-то подняли 10-летнюю тему со своим вопросом и к вечеру уже стали знатоком в этом вопросе 😀 В SPF домена нужно перечислить все источники, с которых могут отправляться письма с адресами отправителя на этом домене. Способ обозначения источника выбирается такой, какой удобнее для конкретного источника (или группы источников).
Выбери любой, его и укажи.
Тема 2014 года.
Все-таки лучше указывать "имя сервера", а не почтовый домен. Обычно в качестве имени сервера используют домен третьего уровня. Но это не требование, а просто распространенная практика. Можно и второго. В этом случае вероятность совпадения имени сервера с одним из почтовых доменов выше.
да не зашел мне ваш этот mvc)
Даже так? )
Тогда нам с вами не о чем говорить. Хотя формально MVC != единая точка входа 😉
Ну, чисто теоретически, можно что-нибудь придумать и для множества точек входа. Но из реального опыта ничего не подскажу. Это было очень давно.
Нужна ли она тогда вообще?
От ВКонтакте не нужна. Ее заменяет обычная ссылка на страницу ВКонтакте.
Люди перешли на общение в чатах социальных сетей, мессенджеров и т.п. Можете "забрасывать крючки" наподобие "отвечаю только у себя в комментариях (ссылка)". Если кому-то интересны именно ваши комментарии, люди подтянутся.
как мне зафиксировать BASE_DIR так, чтобы она была определена еще до всяких инклюдов? это реально вообще?
Да. Основные "базы" обычно определяются прямо в единой точке входа (фронт-контроллере) через __DIR__ (или __FILE__), чтобы уже на их основе подключать конфигурационные файлы. Только корневой каталог - это не основное в профессиональных проектах. В них в качестве основной базы определяется либо целиком каталог проекта, либо его подкаталог с программными файлами (исключением может быть единая точка входа и другие точки входа наподобие cron.php или cli.php, которые могут располагаться прямо в каталоге проекта; из-за ограничений хостинга единая точка входа может располагаться и в корневом каталоге).
Если у вас взаимоположение единой точки входа и конфигурационного файла с определениями "баз" всегда фиксировано, можете подключить этот конфигурационный файл непосредственно при помощи __DIR__.