конечно метод, но как тогда

16.5.2001 12:08 kostysh []
...это, конечно метод, но как тогда быть с корпоративными юзерами, сидящими в маскарадных сетках?

у них же у вес один IP, хоть даже если их 100, и поллучается, что если среди них затесался

хакерюга и лезет подбирать пароль к тебе на сервер, то после н-ного кол-ва попыток, он

просто напросто отрубит всю свою сетку от доступа к твоему серверу...

я думаю, что здесь нет единого оптимального решения.

того, кто серьезно задумал поломать твой сервис остановить почти невозможно.

для пользователей не-вебовских интерфейсов доступа к сервисам есть одни методы

контроля.. для пользователей именно вэбовских интерфейсов - другие.

я думаю, что розумнее всего контролировать вэбовского юзера с использованием

сессий... в таком случае мы имеем дело с действительно уникальным параметром

- ID сессии... ограничить число попыток входа в систему в рамках одной сессии

это очень простая задача, но расчитывать на то, что хакер будет сидеть за окном

броузера и постить тебе формы с подбором пароля - просто смешно.. скорее всего

это будет специальный софт, который без проблем начнет новую сессию, когда ты

закроешь предудущую... ты с ним в этом случае ничего не сделаешь.

есть один выход - анализ трафика. Что я имею ввиду - а вот что:

необходимо контролировать и анализировать общее количество сессий открытых

в системе с определенного IP, причем не всех сессий а только тех

которые были закрыты по причине ошибок ввода пароля.

необходимо либо на угад, либо опытным путем установить критическое число для

этого случая и только при достижении его, закрывать доступ этому IP в систему.

Анализируя трафик, нужно не забывать о распределении отказов доступа во

определенном временном промежутке, чтобы не перепутать обычный всплеск пользовательской

активности с атакой хакера... короче здесь еще говорить и говорить.

вот, такая получилась маленькая статья. Я, кстати, сейчас работаю именно над

такой системой, если есть желание, можем обсудить возникающие вопросы - если это еще актуально.

------------------------------

14.6.2001 18:14 Andrew []
Что ж, решение стандартное, каждый веб-программист с такого и начинает :). (нечто подобное делал и я) А что будет с сайтом у которого большой траффик?? Через какое время БД логов забьется под завязку? Сколько потребуется времени MySql-у чтобы переварить свои сотни тысяч записей, для составления статистики? Может необходимо подумать о вычислении каких-то промежуточных результатов, и хранить только их? Скажу, что я эту проблемму еще не решил... Хотелось бы услышать мнения на этот счет

20.6.2001 10:57 Iv An []
1. Берётся халявная Виртуоза ( http://www.openlinksw.com ), а вовсе не MySql. Хотя бы потому, что primary key будет расти абсолютно монотонно, и MySql "заболеет" после right-edge вставки 100000 записей.

2. Не берётся PHP вообще. (Ау, модератор, здесь дальше сплошной оффтопик).

3. Импорт данных не есть проблема, даже если их глотать просто из Apache-вского лог-файла. Для разбиения каждой строки на поля есть напр. split_and_decode(...), а для особенно изощрённой обработки HTTP-USER-AGENT есть regexp_...(...).

Можно повесить импорт на таймер, напр. читать новые/подросшие файлы каждые 15 минут.

4. Пишется набор тривиальных VSP-страничек. Ну то есть совсем тривиальных. Данные для них можно собрать "на лету", можно готовить при помощи триггера (обновлять табличку с готовыми статистиками after insert of записи из лога с номером кратным 1000), можно опять же повесить функцию на таймер.

Поскольку это Виртуоза, о скорости можно особенно не думать. Специальные хитрости действительно необходимы только при годовом логе по мегабайту в день.

27.6.2001 17:08 kosha
По моему этот способ очень хорош для тех случаев когда логи за год просто не требуются. У меня например давно работает подобная вещь и лог чистится еженелдельно потому что мне больше не надо.

17.8.2001 12:00 Bronislav []
Во многом согласен с Андреем. Вычисление статистики делается не для пользователя, а я подожду ;)) Несколько слов об объеме базы. При посещаемости 250 стр/день за год не наберется и одной сотни тысяч. Но для сайтов с иной посещаемостью эта проблема имеется. C желательностью сотавления "промежуточных результатов" (с) я уже столкнулся. На мой взгляд, здесь нет ничего принципиального. Такого рода архивация предусматривает потерю некоторых данны, и, следовательно, невозможности получения некоторых отчетов. Но так ли нам нужны ВСЕ виды отчетов за предыдущий год (полугодие) ? Некоторое неудобство - немного иная структура таблицы и другие программы. Оговорюсь, что программу эту я пока не писал.

архив | ссылки | форумы | что такое php

30.5.2001 22:26 KVN []
Хм , статья то в принципе правильная, но это не подход!

Потому, что ты обругал что-то, НЕ предложив ничего взамен.

Икак же нам теперь учиться PHP?
Ответ DL:

Да, возможно, конструктива мало. Это больше крик души: не делайте так, как я сделал однажды. А чтобы учиться, надо писать то, что требуется, и изучать новое на простейших программках.

30.5.2001 22:30 Spectator
Ну не то, чтобы я совсем со всем согласен ;) Желание написать сразу большие вещи - это как графоманство: все хотят написать именно РОМАН. С первого раза. Реально же - ни у кого роман сразу не получается ;) Да, пробовать лучше с маленьких вещей. Хотя когда я программировал Spectator.ru, начал сразу с большого. Но: а) я отдельные куски столько раз переписывал, что старых просто не осталось б) у меня уже был опыть программирования. в) новые фичи добавлялись постепенно, а не все сразу.

Поэтому я согласен с Дмитрием - не надо сразу бросаться делать большой проект. Скромнее надо быть. И поковырятся в чужих скриптах тоже очень полезно - чужие ошибки просто виднее, чисто психологически ;) Да, и главная проблема - если вы беретесь за большой проект, не умея при этом программировать, главная проблема - то, что вы просто не видите и не представляете истиный объем работы - вы же не умеете программировать...

Короче, все правильно ;)

31.5.2001 16:59 tony2001 []
to KVN:

> НЕ предложив ничего взамен

А тебе надо было подкинуть задачку? пожалуйста: а не напишешь ли ты портальчик маленький такой... с нуля.. ??? Или Чат.ру сделай заново =)))

Учись на тех задачах, которые встают каждый день!

А эту можно решить с помощью Пфорума - если что-то не понравится в нем, то когда разберешься более менее, можно будет и подпатчить.

Но сразу писать форум. Да еще когда все велосипеды уже изобретены и ездят...

Глупо, ИМХО. Так что статья в тему и по делу.

1.6.2001 06:03 Nina
Тогда уж не "простейшие программки", а модули, классы и функции. Их можно переписывать хоть до упаду, а потом вставлять в шахматном порядке в большущий проект :).

Неплохо было бы упомянуть и о том, что собственно кодирование отнимает едва ли не 10% всего времени. 50% - планирование, остальное - отладка, тестирование, размышления на тему "а нужно ли оно". Суровые программистские будни :).
Ответ DL:

Да, естественно :)

27.5.2002 15:34 tony2001 []
если кто собирал ман от РНР из XML - поделитесь, плз, опытом.

если получится - будет и русская версия мана от SRM =)

4.6.2002 20:31 tony2001 []
Поздно, уже разобрался.

Перевод мана от SRM ~25% готовности...

Estimated time - 2-3 weeks.

архив | ссылки | форумы | что такое php

3.6.2002 21:43 webdeveloper
Я бы еще сказал, что XML+XSL очень хорошо будут работать на разных content managers. Там где требуется полностью отделить код от дизайна. В принципе не важно РНР это или ASP или CFML. Главное это идея. И то что это все таки стандарт. Что тоже значительно упрощает поддержку готового приложения жругими програмистами. (В отличии от многочисленных классов шаблонов)

20.6.2002 13:06 DenisK []
по поводу выводов: пункт 1, 2 - согласен

пункт 3: я его несколько раз прочитал, так и не врубился - это почему же XSL не для крупных проектов?

а на фига он нужен в домашних страницах?

а так все хорошо начиналось...
Ответ DL:

Насчёт того что не для крупных проектов - это, конечно, спорно. Здесь я просто ретранслировал мнение одного человека, который работал в крупных проектах, и кому доверяю.

архив | ссылки | форумы | что такое php

Содержание раздела