CityCat4, конечно! Но я уверен в двух вещах - 1) Как ты руки не мой, даже у хирурга во время операции на руках есть грязь, ну пусть пара бактерий, но остается. и 2) из первого не следует, что руки не надо мыть. Лучше иметь две бактерии на руках, чем 20 грамм бактерий. Лучше иметь средненькую анонимность, чем никакой.
Ну и правило Парето. Минимум усилий уже дают огромный эффект.
roswell, а откуда взялись те, кто предоставлял как раз то, что я ищу 25 лет назад? Откуда взялись те, кто предоставляют эту бесплатную услугу сегодня, с точно такими же высокими запросами к дисковому месту, просто делают это с SMS проверкой. Разве если человек верифицировал телефон - то в его ящике будет меньше писем что ли? :-)
Возможностей для монетизации бесплатной услуги - миллион, что мы и видим почти везде в интернете (который полон "бесплатными" сайтами, но при этом как-то зарабатывает. Мы сейчас с вами на одном таком сайте общаемся)
Да я знаю про эти сервисы SMSок и даже пользуюсь ими иногда но это для временных аккаунтов, именно для мусорных. Потому что через некоторое время этот номер окажется во владении кого-то и тут-то он и "восстановит доступ к почте через номер телефона". Зачем мне такая радость? Это прямо как почта как в 90/00-ые годы, но случайный человек на планете будет иметь возможность взломать твой ящик за 2 минуты. Что-то как-то не очень.
Почта в Узбекистане - вполне норм, если нажать на шамаскую кнопку "Я русскиййй!". Даже можно зарегистрироваться наполовину, но при попытке войти, просит номер телефона, куда вышлет SMS. Так что, нет, и в Узбекистане все не так, все не так как надо! :-)
Это немного другое.
На disposable нельзя ничего долговременного регать. Например, акк на хабре вряд ли стоит регать на mailinator.
Я же хочу почту, которая будет именно моя (как раньше на @mail.ru и везде), которую можно читать только с паролем, и никто другой не прочитает. Либо нужен вот такой вот сервис "почты из 90-ых", либо подошел бы (если вдруг есть) урезанный сервис, с которого нельзя отправлять почту.
Спасибо. Из Figma что выходит - уже HTML/CSS (для п.3) или просто картинки согласования и чтобы потом (в текстовом редакторе) повторить что-то похожее?
Владимир, вроде я это и написал. "Этого кода нет на клиентской части". Скажем (чуть наивный пример) - в целом бухгалтерия на PHP у клиента, а вот какой-то налог считается на сервере.
Можно выкусить это, написать локальную функцию расчета, но даже небольшой код для чужого проекта писать уже страшновато и сложновато. А что именно делать на сервере (в идеале, что-то, что локально реализовать было бы сложно) - это уже надо по каждому проекту отдельно решать. В общем, нужно увязать готовую программу с внешним сервисом.
А что значит "поиск начал тормозить", какие цифры? Просто у меня есть проект на python (то есть, относительно "медленный") и я тестировал на базе из 1 млн записей (все в памяти, с диска не подргружается ничего), при этом фильтрация идет по пайтоновскому выражению в запросе (скорее ближе к SELECT ... WHERE в SQL, а не быстрый-эффективный поиск по дереву, как в редисе на С).
Так вот, при всех этих замедляющих факторах, поиск всех продуктов, где "price<20" из миллиона:
четверть секунды. Это слишком много? И это на пайтоне и это фильтрация каждого из миллиона (а не поиск по ключу). Если у вас поиск по ключу, да еще и redis'ом больше занимает - что-то где-то как-то криво.
И еще вопрос - а как часто обновляются данные у вас? Потому что есть еще такая веселая идея (если обновления редки) - сделать все на статике (например, hugo) и раздавать HTMLки (или JSONки) просто как файлы с диска. Nginx найдет выплюнет статический файл с диска просто моментально. Но это уместно только если обновления редки.
CityCat4, так это LTSная версия, должна поддерживаться. Ну и для других версий, посвежее, тоже нету. Как-то это странненько... будто забили на уязвимость.
Everything_is_bad, не знаю. Пока что я вообще не уверен в ситуации - мне не верится, что большая дырка для которой есть патч может сверкать уже целый квартал. Думаю, что может быть это я что-то упускаю, путаю...
Adamos, ээммм... а сейчас ведь через GPT их легко генерировать! Только я что-то не нашел в интерфейсе ChatGPT где сид указывать - может быть это было в другой нейросети, но где-то можно. Если нейросеть по сиду сможет однозначно генерировать хокку - этот хокку-код тоже будет иногда удобен для использования! :-)
У меня нет проблем, чтобы изобрести свой алгоритм для этой задачи (сложность такой задачи - что-то для старших классов школы), но я не столь юн и глуп, чтобы по каждому поводу писать свой уникальный велосипед.
Мне интереснее какое-то более-менее стандартное и популярное решение. И если таких решений несколько, то важнее то, что наиболее популярно и совместимо и где решены все детские проблемы, которые с собственным велосипедом сразу даже и не видятся. Совместимость - это ведь тоже важно, разве нет?
Вариант выше про BIP39 - очень хорошо подходит под мой вопрос. Но xkcdpass тоже неплох, спасибо!
Там в обычной работе & не может встретиться. Ведь все ссылки делает сам сайт, и они имеют вид t=123. Так что разработчику сайта такой метод не мешает.
Мне интересно, почему все энкодят... ну то что это полезно - окей, но может быть есть какая-то RFC для этого. Я вот нашел RFC3986, но там это не требуется. И интересно, есть ли малопопулярные браузеры, которые, может быть не экнодят (чтобы показать в случае чего, вот браузер X, у него 0.1% рынка, значит 0.1% ваших пользователей уязвимы)... Вижу, что dillo не энкодит угловые скобки (больше/меньше) например. Но в нем и JS нет :-)
Минус вполне себе терпимый (все лучше, чем когда сайт лежит). Но вопрос - а можно ли сделать капчу чисто на фронтенте (HTML/JS) без бэкенда? Если нельзя и нужен бэк, который будет генерировать кастомную страничку каждый раз или проверять капчу, то не получится ли так что обработка капчи (неправильной, боты ее не могут пройти успешно, но могут делать попытки) будет по сложности-скорости сравнимой с генерацией обычной страницы?
Ну, слава Богу, у нас пока "не настоящий" DDoS, но хватает, чтобы положить виртуалку. Так что, пока что, нужна не панацея от всех болезней, включая чуму и рак, а просто удобное лекарство от перхоти.
zGzn1=Ar4lt1aB нигде не используется, но это случайная часть запроса. В этом - так, а в следующем будет 2bQQj=d3k2nnWs. Я сейчас скриптом и выгрепываю такое. Но проблема - логи большие (особенно, во время атак) и выгрепывать все это занимает ощутимое время, несколько секунд на IP. И за одну итерацию (проверку всех подключенных IP, получаю через lsof) - уходит пара минут. Потом новая итерация. Сервак успевают положить, потом я что-то баню, рестартую, но снова забивают запросами. Через какое-то время забаниваются все сегодняшние IP и атака прекращается.
Про JS страничку - спасибо, идея очень интересная! А можно ли как-то проверять в вебсервере (то есть - быстро проверять, а не через PHP/Python) какую-то правильность куки (чтобы любая кука не работала)? Чтобы куки для разных IP, User-Agent'ов требовались разными.
CORS может помочь даже от GET запроса? Нас GET'ами долбят, не POST'ами...
Про браузерный плагин - интересная идея. Не исключено. Хотя мне кажется, что (по юзер-агентам) запросы и с телефонов идут, так что, может это и не плагин.
А вот рамблер и seznam все-таки хотят номер телефона.