Именно — назван не правильно. «Защита от CSRF атак»" — и вопросов бы не было никаких. Потому что сразу понятно что это и зачем. А для кого не понятно — можно было грамотно разъяснить в описании плагина. С примерами. С объяснением почему это может против спама помогать.
А в таком виде это — подмена понятий. Почему плагин и вызвал столько вопросов, и не только у меня, судя по количеству плюсов у моего первого комментария.
Да знаю я что такое CSRF. И как от него защищаться тоже знаю. Но речь здесь не о том.
Речь о том, что надо назвать вещи своими именами. Защита от CSRF это не защита от спама. Это не одно и тоже. Просто уязвимость этого типа может в частности использоваться и для спама, да. В частности. А спам в частности может появятся и другими путями а не через дыры такого типа.
Что не отменяет того факта что сам по себе плагин — полезен. Если сделан правильно.
Ну здрасте. Я не буду ставить себе на сайт нечто, что я не понимаю как работает. Хотя бы какая там идея. И никто в здравом уме не будет. Уж простите. В чем и вопрос.
Если суть плагина защита от CSRF — то это не защита от спама. Это зашита от CSRF. Что не плохо. Но не то.
Эта проблема, к стати, не только для связки Nginx+Apache актуальна. Всё глубже. Та же проблема есть когда у вас многосерверные конфигурации, т.е. вы балансируется нагрузку между несколькими серверами.
Ну так о чём и речь. Т.е. всё что вам нужно сделать — ввести поддержку определенного заголовка (назвать его как-то, например, X-Secure-Connection) и документировать что нужно сделать администратору в конфигурации nginx и в каком случае. С примерами. :)
Самое веселое, что если заменить в БД полные пути на относительные — все очень даже отображается.
Само собой. :) Ибо браузер замечательно резолвит относительные пути доменом. Почему я и не понимаю с какой целью вообще абсолютные пути в базу сохраняются. Смысл какой-то в этом был наверняка, но какой я не понял :)
Ну так я вам и говорю — от NGINX к апачу придет HTTP. Apache не увидит что там вообще был HTTPS, потому что кодирование/декодирование SSL это работа nginx и апач вообще не в теме. Обычно это решается путем ввода специального хедера в заголовок запроса. Техника аналогичная X-Forwarded-For для IP адресов. Т.е. по уму вам нужно проверять ещё и специфический заголовок.
С любых доменов. если браузер грузит страницу по HTTPS, то все ресурсы которые грузятся вместе со страницей (картинки, CSS, JS — всё) тоже должны приходить по HTTPS, иначе будет WARNING от браузера.
Подумайте ещё вот о чём. SSL-eм при правильном подходе будет заниматься NGINX. Т.е. back-end, будет всегда получать уже декодированный запрос и по HTTP Без всяких «S». И тогда ваш плагин, насколько я понял, работать не сможет :)
Разумеется. Любой браузер будет ругаться на обращение по HTTP из HTTPS сессии. Это нарушение безопасности.
Вообще корень проблемы в том как LS работает с изображениями. Хранить, конечно, нужно относительные пути — это бы сняло целую пачку проблем. И с CDN, и с переходом на другой домен и с вот с HTTPS. в Alto вроде продвинулись в этом направлении дальше.
Всё тоже самое можно и сделать на уровне HTTP сервера. И работать будет намного быстрее, ибо не PHP. Но за инициативу — плюс. :) Продолжайте в том еж духе :)
А в таком виде это — подмена понятий. Почему плагин и вызвал столько вопросов, и не только у меня, судя по количеству плюсов у моего первого комментария.
Речь о том, что надо назвать вещи своими именами. Защита от CSRF это не защита от спама. Это не одно и тоже. Просто уязвимость этого типа может в частности использоваться и для спама, да. В частности. А спам в частности может появятся и другими путями а не через дыры такого типа.
Что не отменяет того факта что сам по себе плагин — полезен. Если сделан правильно.
Но почему это зашита от спама? Ну точнее, частный случай — да. Редкий. Но от спам ботов — которые и есть основная беда — это никак не поможет.
Если суть плагина защита от CSRF — то это не защита от спама. Это зашита от CSRF. Что не плохо. Но не то.
Вообще корень проблемы в том как LS работает с изображениями. Хранить, конечно, нужно относительные пути — это бы сняло целую пачку проблем. И с CDN, и с переходом на другой домен и с вот с HTTPS. в Alto вроде продвинулись в этом направлении дальше.