Все это выглядит очень забавно, и мне хотелось бы присоединиться к зубоскальству над простодушными юзерами, которых ломают все кому не лень, если бы не один простой вопрос:
почему в яндекс-списке оказались не активно используемые мною ежедневно ящики, а тот, в который захожу пару раз в год и с которого вообще не веду переписку? Он мне нужен был только для яндекс-вебмастера. Пароли совсем не простыми, с разными регистрами, работаю чаще всего из-под линуксов.. странно все это.
Там в списке есть и яндейкс, и мейл.ру, и еще много кто. Как я понимаю логику этого специалиста: если у сайта имеется необоснованное ограничение на максимальную длину пароля => следовательно в БД предусмотрено поле под этот пароль определенной длины.
Я, кстати, тоже не вижу никакой причины ограничивать максимальную длину пароля - хешированию по-барабану, какого размера пароль.
SHoKKiNG: Такой вот вопрос: сейчас почти на всех хостингах нет необходимости выставлять chmod 666/777 для некоторых файлов, как бы и при 644/755 все нормально работает.
А как такое на вдс (centos) себе сделать?
Только после этого возникнет небольшой гимор при заливке файлов на хостинг, ибо как правило коннектится к серверу совсем другой (не апачевский) юзер.
В такой ситуации лучше всего создать на сервере специального пользователя с группой, из-под него и запускать апач, и логиниться к серверу, и больше ничего этот юзер на сервере делать не должен.
Проверьте (чем черт не шутит), что параметр client_max_body_size находится внутри одной из секций: http или server, или location
Загляните (на всякий случай) в логи апача. Если апач говорит 413, то nginx честно оттранслирует этот ответ. Если да, то возможно нужно настроить какой-нибудь mod_security
Ms-Dred: Ну я просто еще ток разбираюсь со всем этим. Доку по regex читал, но с моими знаниями, составление правильной регулярки займет много времени, вот и интересуюсь, к тому же думаю что regex в данном случае не поможет:
Суть такая, есть коллекция в которой поле массив
tags: ["slovo1","slovo2","slovo3","slovo4"]
Думаю как сделать чтобы при поиске "slovo1 slovo4" найти все записи в которых присутствует и то и другое слово.
Ms-Dred: Подскажите если что что то подобное в mongodb для поиска по словам. В mysql использовал RLIKE слово|слово|слово
Как можно реализовать в mongodb такой поиск или быть может есть альтернатива?
Белый Ум: А зачем поисковику показывать в выдаче ссылку на страницу, которую с вероятностью 99.7% человек открыть и прочитать не сможет? С таким же успехом поисковик вместо ссылки может давать номер полки в ленинской библиотеке, где лежит этот материал - кому нужно, тот дойдет и прочитает)
вы бы, чем теоретизировать, зашли бы на открытую статистику liveinternet и убедились, что 99.7% читателей этих сайтов блокировки не заметили 🍿
Не совсем так, можно нарваться на коллизии. Собственно потому у яндекса до сих пор макс длинна пароля 16 символов, но обещали убрать.
Не очень понимаю - ну у двух разных юзеров окажется одинаковый хеш, или у двух юзеров одинаковый пароль - в чем беда?
Все это выглядит очень забавно, и мне хотелось бы присоединиться к зубоскальству над простодушными юзерами, которых ломают все кому не лень, если бы не один простой вопрос:
почему в яндекс-списке оказались не активно используемые мною ежедневно ящики, а тот, в который захожу пару раз в год и с которого вообще не веду переписку? Он мне нужен был только для яндекс-вебмастера. Пароли совсем не простыми, с разными регистрами, работаю чаще всего из-под линуксов.. странно все это.
Наткнулся на забавное исследование одного иностранца. Он выискивает сайты из ТОПа Alexa, которые подозреваются в хранении юзерских паролей в plaintext: https://defuse.ca/password-policy-hall-of-shame.htm
Там в списке есть и яндейкс, и мейл.ру, и еще много кто. Как я понимаю логику этого специалиста: если у сайта имеется необоснованное ограничение на максимальную длину пароля => следовательно в БД предусмотрено поле под этот пароль определенной длины.
Я, кстати, тоже не вижу никакой причины ограничивать максимальную длину пароля - хешированию по-барабану, какого размера пароль.
[забито........]
вы уж формулируйте корректно, а то можно много советов получить..
Такой вот вопрос: сейчас почти на всех хостингах нет необходимости выставлять chmod 666/777 для некоторых файлов, как бы и при 644/755 все нормально работает.
А как такое на вдс (centos) себе сделать?
Сделать-то такое несложно:
Только после этого возникнет небольшой гимор при заливке файлов на хостинг, ибо как правило коннектится к серверу совсем другой (не апачевский) юзер.
В такой ситуации лучше всего создать на сервере специального пользователя с группой, из-под него и запускать апач, и логиниться к серверу, и больше ничего этот юзер на сервере делать не должен.
Ну я просто еще ток разбираюсь со всем этим. Доку по regex читал, но с моими знаниями, составление правильной регулярки займет много времени, вот и интересуюсь, к тому же думаю что regex в данном случае не поможет:
Суть такая, есть коллекция в которой поле массив
tags: ["slovo1","slovo2","slovo3","slovo4"]
Думаю как сделать чтобы при поиске "slovo1 slovo4" найти все записи в которых присутствует и то и другое слово.
db.collection.find({ $and: [{ field: /slovo1/i },{ field: /slovo4/i }] });- как-то так, либо:db.collection.find({ field: /slovo1.*slovo4|slovo4.*slovo1/i });- поэкспериментировать надо, что лучшеПодскажите если что что то подобное в mongodb для поиска по словам. В mysql использовал RLIKE слово|слово|слово
Как можно реализовать в mongodb такой поиск или быть может есть альтернатива?
странный вопрос.. ну, например там полноценные регэкспы есть http://docs.mongodb.org/manual/reference/operator/query/regex/ - а что, бывает, что в базе данных не бывает поиска по словам? 😕
Я что-то недопонял? Просвятите, пожалуйста. Я знал что роботы ходят по закрытым директориям, но я был уверен что в индекс они не попадают.
Вы действительно недопоняли. Приводите robots.txt для домена второго уровня, а в выдаче по вашей ссылке домены третьего.. там свои роботсы.
А зачем поисковику показывать в выдаче ссылку на страницу, которую с вероятностью 99.7% человек открыть и прочитать не сможет? С таким же успехом поисковик вместо ссылки может давать номер полки в ленинской библиотеке, где лежит этот материал - кому нужно, тот дойдет и прочитает)
вы бы, чем теоретизировать, зашли бы на открытую статистику liveinternet и убедились, что 99.7% читателей этих сайтов блокировки не заметили 🍿
А Гугл? Ему на наши законы плевать ...
гуглу и наши блокировки плевать 🙄