Комментарии 26
НЛО прилетело и опубликовало эту надпись здесь
Для таких простых проектов вместо крона можно использовать таймеры systemd. Если скрипт в какой-то день не стартанёт, журнал systemd покажет в чём было дело.
preg_match('/Registry\sExpiry\sDate:\s(.*)\\r/', $date, $matches);Оххх, совсем не факт, что там будет именно эта строка, вариантов там десятки-сотни… в каждой зоне свой.
Согласен, но в свое оправдание скажу, вроде бы в РФ, в основном 2 агрегатора, reg.ru и nic.ru, у меня забито 2 регулярки на проверку именно 2 этих агрегаторов, таким образом, я думаю, получается покрыть до 90% сайтов.
К сожалению я не особо представляю, как отказаться от регулярок.
Код подробно не смотрел, но рассмотрите вариант динамического встроенного теста: когда известные домены проверяются на известное же окончание их срока действия. И уведомление если они требуют внимания (ведь их тоже могут продлить).
Это частично спасет от ситуации когда непонятно что с регуляркой (ибо регулярки зло, но очень заманчивое)
Это частично спасет от ситуации когда непонятно что с регуляркой (ибо регулярки зло, но очень заманчивое)
У меня реализовано это, как я понимаю.
Про что вы имеете ввиду, когда говорите "динамический встроенный текст", можно ссылку какую-нибудь :?)
Я имею в виду не теКСт, а теСт.
Т.е. есть известный домен и есть известная дата Expiration. Есть два провайдера, через которых вы проверяете. Оба должны выдать одну и ту же дату (причем с разной регуляркой для них). Так вот можно проверять соответствует ли реальная дата тому, что ожидается у обоих провайдеров. Если они поменяют формат (вряд ли одновременно), то вы это заметите до того как ваш домен истечет.
Еще можно использовать несколько разных (!) регулярок, которые должны поймать одно и то же… Но это меня понесло ))
Минус тут, разумеется, это требование по поддержанию актуальности дат экспирации этих тестовых доменов. Можно чуток схитрить, проверять еще и год — и если у вас ожидается дата 2020-01-29, то для даты 2021-01-29 или 2022-01-29 это будет не ошибка, а просто Warning с напоминанием что надо бы вручную проверить, что там на самом деле.
Для сертификатов это в лоб не подойдет, он может быть продлен заранее, но тут проблема не стоит остро т.к. проверка идет локально, через openssl, и нет зависимости от ответа от внешнего провайдера.
Вот примерно так.
Т.е. есть известный домен и есть известная дата Expiration. Есть два провайдера, через которых вы проверяете. Оба должны выдать одну и ту же дату (причем с разной регуляркой для них). Так вот можно проверять соответствует ли реальная дата тому, что ожидается у обоих провайдеров. Если они поменяют формат (вряд ли одновременно), то вы это заметите до того как ваш домен истечет.
Еще можно использовать несколько разных (!) регулярок, которые должны поймать одно и то же… Но это меня понесло ))
Минус тут, разумеется, это требование по поддержанию актуальности дат экспирации этих тестовых доменов. Можно чуток схитрить, проверять еще и год — и если у вас ожидается дата 2020-01-29, то для даты 2021-01-29 или 2022-01-29 это будет не ошибка, а просто Warning с напоминанием что надо бы вручную проверить, что там на самом деле.
Для сертификатов это в лоб не подойдет, он может быть продлен заранее, но тут проблема не стоит остро т.к. проверка идет локально, через openssl, и нет зависимости от ответа от внешнего провайдера.
Вот примерно так.
Доброе утро. Гляньте на этот проект.
github.com/io-developer/php-whois/blob/master/src/Iodev/Whois/Configs/module.tld.parser.block.json
github.com/io-developer/php-whois/blob/master/src/Iodev/Whois/Configs/module.tld.parser.block.json
Для всех gTLD это вполне даже факт — формат whois очень жёсткий и регламентирован ICANN, вариации могут быть только у ccTLD, но и их не так уж и много, может всего десяток и наберётся.
Другое дело что whois может уйти в прошлое в связи с появлением RDAP и планами ICANN перейти только на него, но там JSON так что дело упрощается.
Другое дело что whois может уйти в прошлое в связи с появлением RDAP и планами ICANN перейти только на него, но там JSON так что дело упрощается.
НЛО прилетело и опубликовало эту надпись здесь
Все очень и очень плохо. Про композер явно не слышали, проблему if/else не решили. Появится 100 команд, будете делать простыню из 100 if/else, switch/case? Одна статика во всех классах. Пытались решить полезную задачу, а код полезным не сделали.
В попытках изучения PHP и долгих раздумьях
Только не в попытках, а в процессе :) Пыха простая, вторых и третьих попыток вряд ли будет.
Извините, что докапываюсь, я по-доброму. Просто слова «попытка», «долгие раздумия» приминительно к пыхе немного режут глаз. Я из-за этого и на статью перешел )
Возможно стоило в проект внедрить паттерн «Комманда», все строковые сообщения убрать в отдельные темплейты, чтобы не засорять код контроллера и их рендеринг перенести в View-ы, где по сути им и место.
Спасибо за статью, что-то подобное пытаюсь реализовать на Python, может уже кто встречал, чтобы я не городил велосипед?
Есть проблема,
echo | openssl s_client -servername Notfound123dgdfhjjfg4dom.com -connect google.com:443 2>/dev/null | openssl x509 -noout -dates
и получаем для несуществующего домена якобы валидный сертификат
notBefore=Mar 24 06:27:26 2020 GMT
notAfter=Jun 16 06:27:26 2020 GMT
а на самом деле сертификат для указанного домена совершенно не валидный
ситуаций, когда вдруг на -connect ищется домен которого там не ждали, в жизни много — простой пример, домен в днс прописали робинбобином, а сертификат не положили, в итоге отдается первый попавшийся. и он получается «валидным» вместо получения алерта, что на данном айпи( сервере) лежит недействительный для данного домена сертификат.
я не нашел простейшего способа как это победить без писанины парсера ответа и ковыряния в поле DNS
echo | openssl s_client -servername Notfound123dgdfhjjfg4dom.com -connect google.com:443 2>/dev/null | openssl x509 -noout -dates
и получаем для несуществующего домена якобы валидный сертификат
notBefore=Mar 24 06:27:26 2020 GMT
notAfter=Jun 16 06:27:26 2020 GMT
а на самом деле сертификат для указанного домена совершенно не валидный
ситуаций, когда вдруг на -connect ищется домен которого там не ждали, в жизни много — простой пример, домен в днс прописали робинбобином, а сертификат не положили, в итоге отдается первый попавшийся. и он получается «валидным» вместо получения алерта, что на данном айпи( сервере) лежит недействительный для данного домена сертификат.
я не нашел простейшего способа как это победить без писанины парсера ответа и ковыряния в поле DNS
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Бот в telegram, который следит за доменом