Есть такой сайт Нотик, люди на него заходят чтобы посмотреть какой ноутбук купить, и не факт что у них, он просто очень удобный для поиск. А есть сотни других интернет-магазинов, которые не удобны для поиска, покупок и обзоров. В своей статье я описал основные проблемы интернет-магазинов, не как открыть свой, а на что стоило бы обратить свое внимание при открытие нового. Критиковать интерфейсы и выслушивать критику интерфейсов это моя работа, я проектировщик интерфейсов. И «я не нашел», «мне не понравилось», «мне кажется сложным» так подумают миллионы таких же пользователей, как я.
М-дя… хотел узнать как происходит запись на субботники — позвонил секретарю, он мне сказал, что специалист по субботникам выйдет на работу в понедельник и больше помочь никто не сможет. А говорят «найдется всё»(
Хотел сказать что и сейчас работаю с некоторыми описанными персонажами, но подумал — а может и я тоже персонаж.
Другими словами спорная статья… вроде «все кругом козлы, а я бабочка», а с другой стороны «кто без греха...». В общем отвечать нужно только за себя, а подставляя других перед начальником сам себе яму выроешь…
Вот ссылочка на мой пример (на библиотеке Chain), набросал за пару часов, но думаю разберешься… там привязка к данным в обе стороны www.box.net/shared/g7671b23dk
Да, вы правы, в тексте статьи об этом как раз и написано: «Книга Александра Драгункина “Быстрый английский” может помочь вам быстро вспомнить…… давайте все-таки заведем блокнот, в котором структурируем правила из его книги, для простоты использования»
Мне лично весьма интересно читать лекции BBC, но это уже кто чем интересуется… про кузнечиков согласен, если прет тема, то нужно использовать, пока не пропадет интерес=) Только есть одно НО, без базовых знаний, которые и предлагает получить эта статья за 15-20 дней, будет тяжко. Сомнительное удовольствия читать один абзац пол часа, тут у любого пропадет запал, пусть даже будет много фоток этих самых кузнечиков. А те лекции BBC, что я предложил для начала, как раз входят в базовые знания. В них хорошо разжеваны многие нюансы разговорной речи (и не только), т.е. вы узнаете особенности языка, и плюс его учите. Я за продуктивность изучения. Пусть я потрачу месяц на старт, но зато потом буду с удовольствием читать периодику, статьи и тд.
А страничек больше нету, на первой фотостраничке под желтыми стикерами правда скрылось кое-что: особенности употребления слова ANY, и употребление слова NO в отрицательных предложениях…
Попозже добавлю фото этого скрытого участка
У меня, как у разработчика такой приоритет: то что очень легко сделать, допустим добавить кнопочку, которая была в прошлой версии и почему-то была убрана — принесет гораздо больше положительных отзывов, чем внутренняя оптимизация. Такова уж психология людей. У микрософта например есть баги в ОС которые переходят из версии в версию, зато юзабилити постоянно дорабатывается, и пусть будут какие-то внутренние баги, для развивающегося софта это нормально, но вот когда проблемы в юзабилити, это раздражает гораздо больше.
Я к сожалению заплатил за аккаунт когда была версия 3.1, которая хоть как-то работала, и имела довольно неплохой функционал, но когда они прекратили поддержку 3.1 и вывели версию 3.5 в финальную, пришлось перейти на нее. Это кошмар, постоянные письма в саппорт с просьбой вернуть хоть какую-то часть того функционала, за который я и платил деньги, в 90% случаев не увенчались успехом. О текущих «висящих» проблемах можно посмотреть на их форуме. В большинстве случаев они говорят «да, мы знаем об этой проблеме...», и не делают ничего, для ее решения. Такое впечатление что они просто забили на свою программу.
Отличная работа! не хватает только динамического обновления списка каталогов и файлов, когда кто-то удаляет папку, в которой я нахожусь и я пытаюсь открыть в ней файл получаю сообщение «неверные параметры»
Повторюсь, все зависит от задачи и степени важности данных, если это форум, разумеется не стоит впадать в пароною, а вот если мы имеем дело с финансами, то тут стоит подумать ото всех степенях защиты, в том числе и правки исполняемого приложения в памяти, но это уже тема отдельной статьи)
Ну начнем с того что десктопные приложения тоже работают с базами данных, и не все используют Perl, PHP и тд. И если запрос к базе можно перехватить, то его можно и поправить, в случае в процедурами мы не раскрываем схемы базы, логики запросов и тд. А вот в случае запроса мы позволяем менять запрос как угодно.
Как проще вытащить все поля, в том числе и пароли пользователей: если у нас процедура getUserList (которая вытаскивает id, name), или запрос, который выглядит как SELECT id, name FROM users. Я думаю правка «id, name» на "*" проще чем подобрать имя таблицы. Инъекция может быть на любой стадии, от формирования запроса, до передачи SQL серверу.
А дополнительная защита когда пользователь входит в базу под своим системным пользователем, у которого права определяются в самой процедуре. Т.е. даже имея имя, пароль пользователя (не рута) и имея имя процедуры ничего секретного вытащить не сможем
Мсье проектировал, реализовывал (один и в команде) сложные ERP, CRM системы, некоторые из которых (по лени и не соблюдению вышеописанных правил на некоторых участках кода) подвергались SQL-инъекциям) И код этих участков рефакторился, из-за порчи данных в важных таблицах (например кто-то умудрился испортить хеши всех паролей у пользователей и чуть не сорвал рабочий день огромной компании в трех странах, благо дальше этого ничего сделать не смог\не захотел и мы быстренько восстановили из бэкапа и задумались над проблемой безопасности всерьез)
А как такой вариант #1:
listAllUser(filterId INT) которая внутри фильтрует данные путем join`а к таблице фильтра,
таблица filter имеет тип Memory
заполняем перед вызовом процедуры listAllUser наш фильтр процедурой AddFilter(typeId int, valueId int)
… как то вот так.
Второй вариант:
Вытаскиваем какие-то данные в контроллер (класс работающий со списком User`ов) и в нем реализуем эти самые фильтры (не на стороне базы).
Все зависит от поставленных задач, если мы в динамике должны постоянно менять набор фильтров, то (опять таки в зависимости от количества данных, ширины канала, объема оперативки) выбираем приемлемый вариант реализации: либо в базе это делать, либо на клиенте. Ну и также зависит от конкретной реализации схемы базы.
В общем это тема отдельной статьи)
Другими словами спорная статья… вроде «все кругом козлы, а я бабочка», а с другой стороны «кто без греха...». В общем отвечать нужно только за себя, а подставляя других перед начальником сам себе яму выроешь…
Попозже добавлю фото этого скрытого участка
Как проще вытащить все поля, в том числе и пароли пользователей: если у нас процедура getUserList (которая вытаскивает id, name), или запрос, который выглядит как SELECT id, name FROM users. Я думаю правка «id, name» на "*" проще чем подобрать имя таблицы. Инъекция может быть на любой стадии, от формирования запроса, до передачи SQL серверу.
А дополнительная защита когда пользователь входит в базу под своим системным пользователем, у которого права определяются в самой процедуре. Т.е. даже имея имя, пароль пользователя (не рута) и имея имя процедуры ничего секретного вытащить не сможем
listAllUser(filterId INT) которая внутри фильтрует данные путем join`а к таблице фильтра,
таблица filter имеет тип Memory
заполняем перед вызовом процедуры listAllUser наш фильтр процедурой AddFilter(typeId int, valueId int)
… как то вот так.
Второй вариант:
Вытаскиваем какие-то данные в контроллер (класс работающий со списком User`ов) и в нем реализуем эти самые фильтры (не на стороне базы).
Все зависит от поставленных задач, если мы в динамике должны постоянно менять набор фильтров, то (опять таки в зависимости от количества данных, ширины канала, объема оперативки) выбираем приемлемый вариант реализации: либо в базе это делать, либо на клиенте. Ну и также зависит от конкретной реализации схемы базы.
В общем это тема отдельной статьи)