- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
/**
* formHostnameRule: правило, проверяющее имя хоста
*
* @package system
* @subpackage forms
* @version 0.1.1
*/
class formHostnameRule extends formAbstractRule
{
private $validTlds = array(
'ac', 'ad', 'ae', 'aero', 'af', 'ag', 'ai', 'al', 'am', 'an', 'ao',
'aq', 'ar', 'arpa', 'as', 'at', 'au', 'aw', 'ax', 'az', 'ba', 'bb',
'bd', 'be', 'bf', 'bg', 'bh', 'bi', 'biz', 'bj', 'bm', 'bn', 'bo',
'br', 'bs', 'bt', 'bv', 'bw', 'by', 'bz', 'ca', 'cat', 'cc', 'cd',
'cf', 'cg', 'ch', 'ci', 'ck', 'cl', 'cm', 'cn', 'co', 'com', 'coop',
'cr', 'cu', 'cv', 'cx', 'cy', 'cz', 'de', 'dj', 'dk', 'dm', 'do',
'dz', 'ec', 'edu', 'ee', 'eg', 'er', 'es', 'et', 'eu', 'fi', 'fj',
'fk', 'fm', 'fo', 'fr', 'ga', 'gb', 'gd', 'ge', 'gf', 'gg', 'gh',
'gi', 'gl', 'gm', 'gn', 'gov', 'gp', 'gq', 'gr', 'gs', 'gt', 'gu',
'gw', 'gy', 'hk', 'hm', 'hn', 'hr', 'ht', 'hu', 'id', 'ie', 'il',
'im', 'in', 'info', 'int', 'io', 'iq', 'ir', 'is', 'it', 'je', 'jm',
'jo', 'jobs', 'jp', 'ke', 'kg', 'kh', 'ki', 'km', 'kn', 'kr', 'kw',
'ky', 'kz', 'la', 'lb', 'lc', 'li', 'lk', 'lr', 'ls', 'lt', 'lu',
'lv', 'ly', 'ma', 'mc', 'md', 'me', 'mg', 'mh', 'mil', 'mk', 'ml', 'mm',
'mn', 'mo', 'mobi', 'mp', 'mq', 'mr', 'ms', 'mt', 'mu', 'museum', 'mv',
'mw', 'mx', 'my', 'mz', 'na', 'name', 'nc', 'ne', 'net', 'nf', 'ng',
'ni', 'nl', 'no', 'np', 'nr', 'nu', 'nz', 'om', 'org', 'pa', 'pe',
'pf', 'pg', 'ph', 'pk', 'pl', 'pm', 'pn', 'pr', 'pro', 'ps', 'pt',
'pw', 'py', 'qa', 're', 'ro', 'ru', 'rw', 'sa', 'sb', 'sc', 'sd',
'se', 'sg', 'sh', 'si', 'sj', 'sk', 'sl', 'sm', 'sn', 'so', 'sr',
'st', 'su', 'sv', 'sy', 'sz', 'tc', 'td', 'tf', 'tg', 'th', 'tj',
'tk', 'tl', 'tm', 'tn', 'to', 'tp', 'tr', 'travel', 'tt', 'tv', 'tw',
'tz', 'ua', 'ug', 'uk', 'um', 'us', 'uy', 'uz', 'va', 'vc', 've',
'vg', 'vi', 'vn', 'vu', 'wf', 'ws', 'ye', 'yt', 'yu', 'za', 'zm',
'zw'
);
http://govnokod.ru/25607
https://pypi.org/project/tld/
Единственный правильный способ валидировать домен — рагуляркой «.+». Единственный гарантированный — попробовать его отрезольвить (только это тоже сложно:надо ещё уметь отличать отсутствие A-записи от NXDOMAIN, например).
Это как с «e-mail»: там правильный способ — это рагулярка «.+@.+», а гарантированный — послать на заданный адрес письмо с подтверждением.
есть https://tools.ietf.org/html/rfc3696 в котором написано каким домен не может быть, все остальное приемлемо считать валидным доменом
Как это противоречит рагулярке госта?
«Public Suffix List — проект Mozilla Foundation по созданию каталога публичных суффиксов доменов, используемых в сети Интернет. Ранее публичные суффиксы называли эффективными доменами верхнего уровня (effective top-level domain, effective TLD, eTLD). Список был создан в 2007 году Jo Hermans как дополнение к списку TLD от IANA. В настоящее время поддержкой каталога занимается Mozilla Foundation для целей повышения безопасности браузера Firefox. Сам список доступен под открытой лицензией Mozilla Public License и используется браузерами Chrome и Opera»
И, в отличие от пхп-макаки, мозилла будет этот лист исправно обновлять. Или тебе не нравится сам подход, что нужно этот лист переодически обновлять и у себя?
Так там это удобно сделано, можно сразу из питухона позвать update_tld_names(). Так что это решение более точное, чем регулярка.
Именно так.
> update_tld_names
А где он их хранит?
> Именно так.
Нужен https://api.mysql-real-public-suffix-list.xyz
Я понимаю зачем проверять доступность какого-то протокола на этом домене. Или работоспособность ссылки. Или вхождение домена в некий вайтлист. А название домена то нахуя?
Бигдатобляди должны страдать.
- как определять, какие куки кому могут принадлежать (с классическим .co.uk это не так очевидно)
- как определить/вычислить поддомен (если, например, клиент со своего адреса сделал пару CNAME на твой SaaS, а тебе нужно админку для этого лопуха держать на поддомене)
накаркал, блядь
Видимо, хранит в каком-то файлике локальном, а обновляет с сайта. Всё гениальное просто )))
> хранить лист
А чем это лучше чем резолвить на каждый чих?
А, NAMES_LOCAL_PATH.
Короче либа говно, но всё равно лучше чем пхп-решения.
> Последняя версия: 2.7.2 (21 марта 2020)
Он даже круче котлина и всяких других штук, если тоже работает с жвм и интегрируется с джавой.
> даже круче котлина и вся
чем круче? тем, что не имеет статической типизации и не компилируеься?
Такой красивый код получится, если намешать скриптушню и вербозную джаву, ммммммм делишес.
Что компилируется? Питон?
>а отсутствие статической типизации – это плюс,
Такой плюс, что гнидо аж mypy напили
>сли намешать скриптушню и вербозную джаву, ммммммм делишес.
Именно потому я за "Груви": там можно мешать компиляцию и инвокдайнемик
зы: еще раз напоминаю, что писать на py27 в 2020 существует -1 причина, или может чуть больше
Питон тоже можно компилировать, да.
https://www.jython.org/jython-old-sites/archive/21/docs/jythonc.html
А «груви» я не знаю, но он очень прикольно выглядит, я тоже за него как за скриптушню для джавы.
офигеть:) А груви можно налету
«Public Suffix List» предназначен для другого. Он для политики передачи кук в браузере.
Например, если я поставлю куку для «ru», то она будет валидна и для «mail.ru», и для «yandex.ru». Чтобы этого не произошло, в «Public Suffix List» добавляют домен «ru». Это означает: «Не применять куки для «ru» к поддоменам». А вот к «disk.yandex.ru» браузер может применить куку от «yandex.ru», потому что «yandex.ru» нет в «Public Suffix List».
Т. е. в «Public Suffix List» могут отсутствовать валидные домены первого уровня (потому что их админ разрешил передавать куки поддоменам), но могут присутствовать домены второго и более высоких уровней. Для проверки почтовых ящиков на валидность такой список бесполезен.
Для проверки корневых доменов в почтовых ящиках на валидность нужен другой список, а именно этот:
ftp://ftp.internic.net/domain/root.zone
***
Author
Artur Barseghyan <artur.barseghyan@gmail.com>
Блядь, какое же всё-таки дерьмо этот веб...
Сука, ну почему нельзя было просто явно указывать для каких доменов эта кука? И явно указывать, от каких доменов я согласен принимать куки. А не делать какие-то ебанутые эвристики.
З.Ы. Видимо из-за этого гитхабу и пришлось унести все недоверенные юзерские данные на левый домен вообще в другой зоне.
1) foo.com публикует куку для bar.com.
2) При запросе на bar.com браузер отдаёт ему эту куку вместе с именем домена, который её ставил.
3) bar.com видит, что кука от foo.com и принимает её.
Никакой магии, никаких списков TLD, никаких проблем с кросс-доменностью...
З.Ы. Хотя криворукие макаки конечно же обосрутся и опубликуют куку на все *.com, а потом ещё и примут куки от всех *.com
Жопа в том, что технически нет границы между "мой домен и поддоменами" и "чужой домен"
От этого страдают многие, и hsts preload, и вот это говно с куками тоже.
Кстати да, чтобы сделать «hsts preload» на домен example.com, сервер обязательно должен отвечать «includeSubDomains» с соответствующими последствиями. «Narod.ru» негодует.
а чтобы отличать поддомен и домен им пришлось захардкотить корневые домены..
у меня на работе в одном проекте был такой отсос: у меня был домен myproject.mycompany.com, и я не мог его preload, потому что можно только целиком mycompany.com, а им управляют другие люди, и не хотят прелоад, потому что есть всякие питухи в поддоменах, котрые не асилили https
на самом деле там лимит есть на размер вроде
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cookie2
https://tools.ietf.org/html/rfc2965
Но больше никто этот проект не поддержал, и его отменили.
А потом вместо исправления недостатков протокола обмена куками налепили кучу новых: localStorage, globalStorage, sessionStorage, indexedDB, Web SQL Database...
Это ты еще не смотрел как в браузере новую куку объявить!
А вот и биндинг к «РНР». Надеюсь, это не то же самое, что в говнокоде, потому что, вроде бы, эта штука выглядит очень даже солидно.
Блядь, ну почему пхпшники — такое говно?
http://web.archive.org/web/20120111154409/data.iana.org/TLD/tlds-alpha-by-domain.txt
А потом бабахнуло, и список TLD стал расти, как снежный ком.
any other TLDs will be created.
https://tools.ietf.org/rfc/rfc1591.txt
но жадность победила
hosts.txt же, как в 1982-м году.
В твоей схеме не очень понятно, кто будет поддерживать всё это многообразие. Корневые сервера не резиновые, чтобы каждый питух мог в них TLD регистрировать.
У них и так высокая нагрузка, и пришлось делать эникаст, а так они вообще лягут.
Да и не понятно как то реализовать с точки зрения бизнеса: придется делать каких-то регистраторов отдельных, ведь не будут же авторы кулинарных блогов покупать домены прямо у корня
а все эти IANA изначально некоммерческие. У них нет столько денег.
А если им становиться коммерческими, то сразу встает вопрос: а какого хуя бабло будет идти именно им?
> есть какая-то затычка на уровне сети с одним адресом,
это как раз эникастом они решили
Ты в курсе что только подать заявку на новый TLD стоит 185k баксов? И что они с каждого домена гребут что-то порядка двадцти центов?
схубяы?
>185k
ну вот цена за поддержку записи у них. И это делегирование, без RR.
Кто за такие деньги купит домен?
а пусть ICANN ебется, я ж не говорю "раздайте народу бесплатно", пусть покупают себе домены, как и сейчас
Сейчас понятно, что так уже не сделать, но если бы в пору "нахуй ваш интернет нам не нужон" всё так организовали - деваться было бы некуда, и роскомнадзор наконец-то бы соснул как следует.
Чем больше сервисов предлагают домены, тем выше конкуренция и ниже цены
На самом деле должна быть как минимум одна точка у публичного домена, и не должно быть пробелов. Но если ты делаешь ресурс для интранета, то точки может и не быть.
>рагулярка «.+@.+»,
Кажется, перед собачкой может ничего и не быть: это locally interpreted name вроде, но надо курнуть рфц.
ты прав
https://serverfault.com/questions/154991/why-do-some-tld-have-an-mx-record-on-the-zone-root-e-g-ai
Емейл сервер Всея Украины
правда, их почтовик писем не принимает
554 Transaction failed (Or, in the case of a connection-opening
response, "No SMTP service here")
ну вот до сегодняшнего дня я думал, что и правально делают. Ан, нет!
matter of")
rfc5322
>russian-caravan.cloud9.net
оказываеца, russian caravan это чай