Проблемы в религиозных различиях :)
А те, у кого с толерантностью всё нормально, берут наиболее подходящий двиг/фрэймвёк под конкретную задачу, затачивают его и зарабатывают вечно зелёных президентов. И в холиварах типа "Джумла - гавно, ДЛЕ - круто" участвуют разве что поржать. :)
Аааа... Понятно.
Можно нескромный вопрос? :)
Что это за бесценная информация такая?
Жесть...
На Пентагон работаете? :)
Кстати, по поводу картинки... Это "заапргредженная версия" простой сессии которую я предлагал. И в принципе, если подобрать хороший алгоритм формирования капчи, то поломать её будет довольно трудоёмким делом. Если ещё и "хороший алгоритм" разбавить чем-то своим, чтобы его не смогли поломать готовые капча-парсеры, то вообще замечательно будет.
Santyago добавил 12.02.2010 в 19:01
Снифер не поможет, если капчу придётся раскалывать.
И исходя из этой архитектуры максимум что можно сделать - это защиту через сессии.
"Защиту от дурака" реализовать и в большинстве случаев этого будет достаточно.
Потому что 100% защиту ты не сделаешь никогда. Поставив перед собой цель, из твоего сайта всё равно можно будет вытянуть что-угодно через Curl + листинг анонимных проксиков.
Лично я недавеча парсил выдачу одного из сервисов Гугли, который, конечно же, очень неплохо защищён от этого. И ничего... Чихнул пару раз от возмущения и всё отдал. )))
Поэтому всегда должен быть разумный компромисс между затратами на защиту и стоимостью защищаемых данных. Это - главное. 100% защитить можно только выдернув из сервака сетевой кабель.
Нету. Мы все умрём.
))))))))))) Пять!
Люди, читавшие RFC1945, взломают что-угодно )))))
Судя по этому
$.ajax({ type: "POST", url: "2.php"+data, dataType: "xml", success: parseXml }); });
Таки вызывается из браузера и задача как раз в том, чтобы запретить прямые вызовы без захода на страницу сайта. Если не прав - тоже поправьте... :)
Гм... А кофе заварить?.. :D
Именно так. Рекомендация нулёвая.
Самый простой метод: сделать через сессии. При обращении к 1.php создаётся сессия, кук с её идентификатором попадает в браузер, где выполняется ajax-запрос. Вместе с этим запросом в 2.php уходит кук с айди открытой сессии. В 2.php необходимо сделать проверку на существование сессионного кука, на существование этой сессии и только тогда отдавать XML. Т.о. мы получаем _обязательную_ необходимость посещения 1.php перед тем как получить данные из 2.php.
Скажу честно, такую защиту я поломаю с помощью Curl примерно минут за 10. Но не зная методики защиты, для большинства это будет проблемой. Так что, лучше так, чем вообще никак. :)
Дальше уже можно навернуть ещё что-то сверху этого метода. Для начала, думаю, и этого хватит.
Santyago добавил 12.02.2010 в 18:24
Т.е. один ключик для всех? Смотришь исходник в браузере, копируешь ключик и используешь сколько влезет?
ППЦ... Ну точно тролль...
Apache::Session - A persistence framework for session data
Apache::Session is a persistence framework which is particularly useful for tracking session data between httpd requests. Apache::Session is designed to work with Apache and mod_perl, but it should work under CGI and other web servers, and it also works outside of a web server altogether.
_it also works outside of a web server altogether_
Перевести?
CGI::Session - persistent session data in CGI applications
CGI-Session is a Perl5 library that provides an easy, reliable and modular session management system across HTTP requests. Persistency is a key feature for such applications as shopping carts, login/authentication routines, and application that need to carry data accross HTTP requests. CGI::Session does that and many more
Всё. Это мой последний пост в данном топике в виду полной неадекватности главного оппонента.
Best regards!
