ммм тогда извольте сударь объяснится)
а почему по дальше от MVC вроде бы на ней стоят все фраемворки так что не таити зря откройте нам тайну по которой вы решили уйти от весьма сложной, и проверенной, и подтвержденной качеством фреимворков технологии.
логика MVC естественно остается не тронутой ) но а на счет что написано у Макконола по моему весьма разная точка зрения Макконоло предлагает делать узко направленные черные коробки с функционалом для одного объекта виджеты же делят этот функционал на очень узкие части заставляя так называемаю коробку зависеть и переносить логику в нее.
Приветствую всех вопрос такой передача из контроллера А в контроллер Б являетса допустимой или верный знак кривой архитектуры ..? как часто вам прихордитса это делать?
Здравствуйте, поговорим немножко о логике.
В общем, читаю одну занятную книгу "Совершенный код", думаю многие с ней знакомы. Для тех, кто не знаком, я немного опишу ситуацию, которая вызывает достаточно спорную точку зрения и хотелось бы, чтобы более опытные люди написали свою точку и так..
Идеология автора - сделать класс гибким и высококачественным.Не буду переписывать книгу, скажу в 2 словах, класс должен быть черной коробкой отвечающий логическим требованиям.
Я понимаю это так - есть контроллер Авторизации, он включает в себя методы по регистрации и авторизации пользователей очищать значения и ждать результата от модели.Мне вполне нравится идея взводить класс в объект реального мира,но недавно начал работать с Фреймворками и заметил, что разработчики некоторых Фреймворков склоняют использовать виджеты,что производит противоположность в логике.Тут весьма авторитетный автор,а с другой стороны много разработчиков и создателей данных Фреймворков.
Расхождение заключается в том, что мы перекладываем логику контроллера на очень узкопрофильный виджет и делаем контроллер просто юзабилити данных виджетов и моделей.Контроллер становится действительно еще более тоньше и гибче,но задача виджета становится настолько узкой, что мы теряем понятия одной коробки с инструментами.Автор книги "Совершенный код" говорит - у вас есть машина, а в ней будут методы ее управления.В данной же концепции у нас есть корпус машины в который мы пихаем детали.
Вопрос к опытным разработчикам, какой концепции стоит придерживаться при условии написания проектов с использованием MVC в приделах интернет разработки??
Спасибо.
Хорошо чем болие реально будет сломмать куку? по сути у 2 этих методов есть только одна дырка это трояны... Но в данной ситуации от нас это и правда не зависит..
Кука и правда хранитса у пользователя но что по факту может приодолеть данную защиту ?
а ведь я потхожу к проблеме на данный момент что данные не зашифрованны..
хотя вы безусловно правы ваш метод безопасние. Но перед созданием топика я ошибочно полагал что сессия нагружает сервер в разы больше кук. Сейчас я переосмыслил этот вопрос и действительно нет смысла такой экономии хотя действительно сессии имеют свойство зависания! Но и защита усиливается на достаточно слабое количество.
Думаю,данная тема будет позновательна не только новичкам!
Вопрос такой,в данный момент люди по поводу сессий разделились на 2 стороны.
Бытует мнение,что сессию лучше использовать в целях для которых она создана,а тоесть межстраничная память.
Другие же говорят что лучше все же использовать ее чаще.Например для хранения логина и пароля.Обосновывая это безопансостью.Решив задаться вопросом я пришел к очень спорному для себя мнению.Я не буду описывать здесь механизм работы сессий в надежде что читатели знакомы с данными механизмами.
Собственно давайте начнем!
Аргументы в сторону сессий:
1)Сессия хранится на сервере,а следственно безопасней.
2)Если смотреть на примере Аутентификации,то приходится более - менее колличество выборок т.к классическая аутентификация подразумевает,что будет просто установлен аргумент в тру (я не говорю о вас,гений,который делает както иначе!Я охватываю большенство и классичность.Доказывать что большенство делает иначе не вижу смысла,мы тут не вопрос аутентификации обсуждаем!)
Теперь поговорим о минусах:
1)Сессии могут подвиснуть.
2)Сессии загружают процессор.
3)Если украсть идентификатор сессии,то мы сможем также аутентифицироватся.
Собственно это пока все что я хотел бы сказать о сассиях.
Теперь поговорим о куках. В наше время их везде закидывают "какашками" крича об их не безопасности,но все же я хотел бы привести и их плюсы и минусы.
Начнем с плюсов:
1)Первый и самый главный - они не нагружают сервер т.к на нем не хранятся.
2)Они не зависают в отличии от сессий .
Больше пока что не могу придумать...=)
Перейдем к минусам:
1)Они хранятся на стороне клиента.
2)Их можно украсть и разумеется подставить что угодно т.к они на стороне клиента.
Казалось бы этих аргументов достаточно,чтобы практически отказатся от них.Однако теперь я бы хотел привести сравнение,увидеть вашу точку зрения по этому поводу.Мы живем в 21 веке и у нас давно есть придуманные за нас функции дабы обезопасить нашу жизнь.
И так поехали!!
1)Мы можем запретить обращение к кукам через ява скрипт,при условии что не используется функция eval() и фильтрация HTML тегов банальным Strip_tags().Согласитесь,мы убираем возможность кражи кук.Конечно есть трояны,но согласитесь трояны могут и сессию выкрасть.
XSS мы исключаем т.к я уже привел пример.У нас множество фильтров,но прошу вас показать мне спсоб внедрения XSS в strip_tags()
Людей говорящих что куку все равно можно украсть в отличиие от ид сессии прошу показать пример!
2)Вторая причина почему куки не безопасны это SQL инъекция и тут я тоже хочу сказать про 21век.Использование PRIPAREd запросов.Если вы не конструируете запрос,то вы получаете 100% гарантию от скюель инекци.Извените,но демогогию что они дольше обычных скюель запросов законьчу тем,что в следуйщей версии пхп модуля майскюель не будет !Следовательно застрствуй ПДО и MSQLI.Получаетса что и от инъекций мы защетились.Тех кто скажет нет - прошу пример инъекиции в припаер.
3)Крптография.Не думаю что ваше значение будет смысл открывать,имея ту защиту которую я описал выше.И все-таки если вам это надо есть масса способов с использованием соли и подфикса.
Вывод:
Если куки все-таки безопасны на данном этапе,почему не использовать их?Ведь они меньше нагружают серверную часть при условии должной защиты,которую я описал и она кстате не так уж и сложна.Я на данный момент склоняюсь к использованию кук,но сеть просто пестрит тем что нада работать с сессиями.Вобщем,не согласных с моими утверждениями я попрошу привести аргументы (почему вы не согласны),а согласных просто подтвердить мою точку зрения для подведения итогового мнения. =)
class HTTP_Exception_404 extends Kohana_HTTP_Exception_404{
publicfunction get_response()
{
if(Kohana::$environment>= Kohana::DEVELOPMENT){
return parent::get_response();
}else{
$view= View::factory('errors/404');
// Remembering that `$this` is an instance of HTTP_Exception_404
$view->message=$this->getMessage();
$response= Response::factory()
->status(404)
->body($view->render());
return$response;
}
}
}
вапрос как мне выводить 404 ттам где мне это нада ?
каким способом это зделат ?
и ваапще верный ли у меня потход если нет не могли бы вы подсказать верныцй
и если могли пожалойсто не поленитесь обяснить как у вас это реализуетса и почему такой потход будет лучше заранее всем благодарен !)
проблема элементарна но я помоему не сталкивался с такой )
var_dump($result[0]); это выборка и нужный мне элемент
array(1) { ["count(*)"]=> string(1) "0" } это то что приходит
нужно чтобы 0 приходил интом. Знаю есть в пхп функция каторая считает количество выбранных рядов но мы не исчим легких путей
может быть тот варинат что я сейчас исчу не совсем верен
по этому скажу пряма мне это нужно чтобы перемножать результаты.
Заранее благодарю за помощ. (Добавление)
все вапрос решен ) но если будет не трудно раскажити как делать алиасы на ключи массива
$query= DB::query(database::SELECT,'SELECT SQL_CALC_FOUND_ROWS, idnews, title, description, dataNews FROM news
WHERE delNews = 0
LIMIT :space, :delimetr')//озательно должно совпадать с 3 парметром фнкции погинатион невс
->bind(':space',$space)
->bind(':delimetr',$delimiter);
$query->execute();
}
коонечно метод еще не дописан и вот что меня терзает дабы его дописать...
Один мой знакомый предлогает до писатьм метод по такому принцепу.. Принемаем любую страницу и отпралвлять ее в лимит.Если запись вернет емпти слать нот фоунд. я же считаю очень расточительным слать пустые запросы, и решил я зделать вот таким способом. создать конфиг в котором будет число при каждом запросе юзера число будет достоватса из конфига и сравниватса, с результатом выборки если чило не равно числу выборки оно переписываетса, иначе остоетса таким же . Если юзер ввел число больше указанного в конфиге его кидает на 404 иначе происходит поиск и сравнения часла с результатом бд. Но вазникает вопрос, а не слишком ли данная конструкция будет ресурсаемка ваше мнение по этому поводу
Приветствую всех. Начал пробывать работать с каханой , ну и конечно куда без трудностей ). Вобщем мой вопрос будет наверно мего глупый! Пишу потому что незнаю как загуглить).
это получения параметра роута
при передачи 2 параметра в адресную строку мы получаем ошибку не найден роут
который мог бы это обработать.
Вопрос злоумышленик может послать 100 таких параметров и, что мне с ними делать ?
меня явно не устраевает вариант с выкинутой ошибкой и, куском кода.
Однако я незнаю как как можно написать роут который будет обрабатывать все что больше 3 аргументов, кидая их на страницу 404...
Суть нужно чтобы отдовалась 404 после того как человек выдаст большее количество параметров чем допустимо.
тестировать базу данных и сервер... смотерть дальнейшую производительность каторую будет выдерживать север и посоле этой процедуры буду учитса профелировать.....
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 69
