| |
| 2.2, HJ (??), 14:38, 26/08/2008 [^] [^^] [^^^] [ответить]
| +/– |
автор пишет, что
PostgreSQL version is in my TODO list.
It will be released sooner or later.
| | |
|
| 1.5, Аноним (5), 18:07, 26/08/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 во изврааатт... следующим этапом будет Bayesian прикручен наверно))
и юзеры будут апрувить хорошие и плохие запросы)
bzzrrrr@fatbastard.ath.cx
| | |
| 1.7, Аноним (-), 10:12, 27/08/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>> 1=1 зря.
SQL-бэкдор хочешь оставить в родной конторе на случай ухода? )))
| | |
| |
| 2.8, Frank (??), 11:25, 27/08/2008 [^] [^^] [^^^] [ответить]
| +/– |
 >>> 1=1 зря.
>
>SQL-бэкдор хочешь оставить в родной конторе на случай ухода? )))
А можно для общего развития разъяснить суть этой уязвимости?
| | |
| |
| 3.10, Аноним (-), 14:54, 27/08/2008 [^] [^^] [^^^] [ответить]
| +/– |
Я пока не достиг достаточного уровня просветления в таких вещах, как sql-injection, но насколько я понимаю, если есть конструкция вида "условие1 and параметр1 = x", где х вводится пользователем, то можно вместо "x" вставить " x or 1=1", а конструкция "условие1 and параметр1 = x or 1=1" всегда равна true... Я конечно понимаю, что много таким образом не вытащишь, да и проверок можно навставлять. А вот необходимость для реальных запросов конструкции 1=1 мне как раз кажется сомнительной...
| | |
| |
| 4.11, Dvorkin (??), 15:02, 27/08/2008 [^] [^^] [^^^] [ответить]
| +/– |
 >Я пока не достиг достаточного уровня просветления в таких вещах, как sql-injection,
>но насколько я понимаю, если есть конструкция вида "условие1 and параметр1
>= x", где х вводится пользователем, то можно вместо "x" вставить
>" x or 1=1", а конструкция "условие1 and параметр1 = x
>or 1=1" всегда равна true... Я конечно понимаю, что много таким
>образом не вытащишь, да и проверок можно навставлять. А вот необходимость
>для реальных запросов конструкции 1=1 мне как раз кажется сомнительной...
w = "select .. from ... where ";
for ( i = 0; i < 10; i++) {
if ( i != 0) w .= " AND ";
w .= " field${i}=$i";
}
а теперь представьте, что в некоем макроязыке нет циклов
| | |
| |
| 5.12, Аноним (-), 15:58, 27/08/2008 [^] [^^] [^^^] [ответить]
| +/– |
Я так понимаю, у вас есть массив, в котором есть сколько-то значений, и надо скриптом сделать запрос, который вытащит строки с этими значениями? Не могу пока ничего сказть, как сделать это без цикла...
Хотя, наверное, GreenSQL поддается тонкой настройке?
| | |
|
|
|
| 2.9, Dvorkin (??), 12:18, 27/08/2008 [^] [^^] [^^^] [ответить]
| +/– |
>>> 1=1 зря.
>
>SQL-бэкдор хочешь оставить в родной конторе на случай ухода? )))
иногда без конструкций, подобной 1=1 никак.
макроязык-надстройка над mySQL-интерфейсом некой программы с очень ограниченными возможностями по конструированию запросов...
| | |
| 2.13, vitek (??), 21:30, 27/08/2008 [^] [^^] [^^^] [ответить]
| +/– |
а как по поводу:
'Вася'='Вася'
или
'Вася' like '%я%'
?
true вернуть может не только 1=1
| | |
| |
| 3.14, demo (??), 21:57, 27/08/2008 [^] [^^] [^^^] [ответить]
| +/– |
Это - константные выражения. Теоретически можно зарубить их всех.
а вот "id IS NOT NULL" выглядит более невинно.
| | |
| |
| 4.15, vitek (??), 22:54, 27/08/2008 [^] [^^] [^^^] [ответить]
| +/– |
да. константные.
а теперь добавим сюда хранимые функции,...... , функции дат...
на этом фоне 1=1 - детский лепет.
о чём и сказал.
| | |
|
|
|
| 1.22, Alexey Pechnikov (?), 00:08, 29/08/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Имхо достаточно использовать параметризованные запросы (чтоб не допустить инъекции) и защиту от несанкционированного доступа типа такой:
proc authorizer {args} {
set dbname [lindex $args 3]
set code [lindex $args 0]
set action [lindex $args 1]
if { $dbname eq {merch} && [lin {SQLITE_DELETE SQLITE_INSERT SQLITE_READ SQLITE_SELECT SQLITE_UPDATE} $code] == 1 } {
return SQLITE_OK
}
if { $dbname eq {audit} && [lin {SQLITE_INSERT SQLITE_READ SQLITE_SELECT} $code] == 1 } {
return SQLITE_OK
}
return SQLITE_DENY
}
P.S. Код рабочий, взят из проекта на эскулайт.
| | |
| |
| 2.23, Dvorkin (??), 00:22, 29/08/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Имхо достаточно использовать параметризованные запросы (чтоб не допустить инъекции) и защиту от
>несанкционированного доступа типа такой:
>proc authorizer {args} {
> set dbname [lindex $args 3]
> set code [lindex $args 0]
> set action [lindex $args 1]
что такое action ? или не важно?
>[оверквотинг удален]
> return SQLITE_OK
> }
> if { $dbname eq {audit} && [lin {SQLITE_INSERT
>SQLITE_READ SQLITE_SELECT} $code] == 1 } {
> return SQLITE_OK
> }
> return SQLITE_DENY
>}
>
>P.S. Код рабочий, взят из проекта на эскулайт.
погодите, забавно. а что, SQLITE сама не умеет пермишены на отдельные операции/таблицы/строки делать?
респект за тисиэль! :)
| | |
| |
| 3.24, Alexey Pechnikov (?), 08:49, 29/08/2008 [^] [^^] [^^^] [ответить]
| +/– |
Аргументы авторайзера такие:
** (1) The authorization type (ex: SQLITE_CREATE_TABLE, SQLITE_INSERT, ...)
** (2) First descriptive name (depends on authorization type)
** (3) Second descriptive name
** (4) Name of the database (ex: "main", "temp")
** (5) Name of trigger that is doing the access
А вот пример передаваемых аргументов:
SQLITE_READ sqlite_master rootpage main {}
SQLITE_INSERT sqlite_master {} main {}
SQLITE_CREATE_TABLE test {} main {}
SQLITE_UPDATE sqlite_master type main {}
SQLITE_UPDATE sqlite_master name main {}
А зачем эскулайту заниматься разграничением доступа? Это дело приложения, а не встраиваемой библиотеки. Эскулайт предоставляет механизм для _контроля_ доступа, а как разграничивать доступ (и разграничивать ли вообще) - решает разработчик. Зато механизмы контроля очень гибкие - кроме вышеописанного, есть контроль изменения данных, коммита/отката транзакции и т.д. В десктопных приложения названные возможности обычно не требуются, а вот для многопользовательских серверов они очень удобны и гибки.
На чем же и писать крупные проекты, как не на тикле :-) Дело вкуса, сами понимаете, и кто-то пишет на лиспе, или на схеме.
| | |
| |
| 4.25, Dvorkin (??), 09:37, 29/08/2008 [^] [^^] [^^^] [ответить]
| +/– |
>А зачем эскулайту заниматься разграничением доступа? Это дело приложения, а не встраиваемой
>библиотеки.
я бы поспорил, ну да ладно.
>На чем же и писать крупные проекты, как не на тикле :-)
>Дело вкуса, сами понимаете, и кто-то пишет на лиспе, или на
>схеме.
язык - это дело вкуса ведущего разработчика, конечно. но привязывать свой "крупный проект" к SQLITE - это как-то... ну в общем, я бы не стал.
| | |
| |
| 5.26, Alexey Pechnikov (?), 12:32, 29/08/2008 [^] [^^] [^^^] [ответить]
| +/– | |
А как насчет ситуации, когда вы _лично_ несете финансовую ответственность за проект? Раньше работал с постгресом, но адаптировать его код намного сложнее, притом производительность постгреса существенно хуже. Для необслуживаемого сервера эскулайт оказывается к тому же намного надежнее (клиент-серверные СУБД без присмотра под нагрузкой начинают вести себя непредсказуемо, все же им приходится регулярно параметры настройки подкручивать, зомбиков пришибать и проч.) Начинал делать большие проекты на эскулайт с того, что один из проектов на постгресе с базой 20 гиг с чем-то перенес на эскулайт - скорость работы хорошо оптимизированного проекта на эскулайт оказалась выше скорости работы хорошо оптимизированного проекта на постгресе в 60 раз, нетрудно догадаться, что на продакшене давно уже работает именно эскулайт версия (архитектура проектов отличается, т.к. в постгресе использовалась единственная база, а в эскулайте набор из десятка баз, но модуль dblink для связки нескольких баз в постгресе для продакшена не годится, а в эскулайт объединение баз выполняется встроенной командой attach, которая работает очень эффективно). Планировщик запроса в эскулайт работает замечательно, за исключением некоторых исключительных случаев, а при нахождении багов можно рассчитывать на их устранение в течении нескольких часов или дней.
Эскулайт часто используется в критичных приложениях, скажем, система авторизации 10-й или 11-й солярки на эскулайт сделана и много других примеров. Тиклевский биндинг к эскулайт, кстати, защищает от sql-инъекций (все запросы автоматически подготавливает как prepared).
Код эскулайт в паблик домене - можно делать с ним все что угодно. Часть своих модулей к эскулайт я выкладываю, но моя версия эскулайт для отдельного проекта может содержать и те модули, которые публиковать не планирую, и лицензия эскулайт это позволяет без каких-либо ограничений.
| | |
| |
| 6.27, Dvorkin (??), 12:54, 29/08/2008 [^] [^^] [^^^] [ответить]
| +/– |
>А как насчет ситуации, когда вы _лично_ несете финансовую ответственность за проект?
>Раньше работал с постгресом, но адаптировать его код намного сложнее, притом
>производительность постгреса существенно хуже.
то, что с постгресом могут быть траблы производительности по сравнению с аналогичными структурами, хранящимися в, нампример мускуле - я в курсе.
> Для необслуживаемого сервера эскулайт оказывается к тому
>же намного надежнее (клиент-серверные СУБД без присмотра под нагрузкой начинают вести
>себя непредсказуемо, все же им приходится регулярно параметры настройки подкручивать, зомбиков
>пришибать и проч.)
ну как-то надо разделить обязанности с кем-то. вы - программист и руководитель, а кто-то - администратор БД. и чтобы ваш коллега денно и нощно решал не ваши проблемы. а вы - денно и нощно работали над оптимизацией своей части проекта.
я все-таки политически против привязки к конкретной БД.
| | |
| |
| 7.28, Alexey Pechnikov (?), 14:04, 29/08/2008 [^] [^^] [^^^] [ответить]
| +/– |
Дело не в распределении обязанностей, а в отсутствии доступа к серверу. Необслуживаемый сервер стоит в интранете и доступ возможен только из офиса заказчика. Так что получить доступ к такому серверу это отдельная история (заказчик может находиться за тысячи километров от нас...). Дебиан+аолсервер+тикль+эскулайт с автономной работой справляются, доступ требуется только чтобы установить новую версию системы.
| | |
| 7.29, Alexey Pechnikov (?), 14:33, 29/08/2008 [^] [^^] [^^^] [ответить]
| +/– |
Да, насчет отсутствия привязки к СУБД - вы готовы гарантировать корректную работу _для нескольких_ СУБД? Если будет заявлена возможность работы с несколькими СУБД, заказчик вправе использовать любую из них, но все проблемы должен решать разработчик ПО (будь то перегрузка при тысячах одновременных пользователей, sql-инъекция, сбой СУБД или любых других). Кстати, 99% тестового покрытия исходного кода я не видел более ни у одной СУБД. А уж найти встраиваемую СУБД, способную работать с десятками и сотнями гигабайт данных, имеющую поддержку sql, многопоточные биндинги практически ко всем языкам и отличный планировщик... Так что альтернатив просто не знаю. Постгрес ранее был выбран за надежность и себя оправдал (много лет эксплуатации на самом разном железе, пока физические диски и ФС целы, все данные в сохранности), но на больших объемах данных и высокой нагрузке в автономном режиме не годится, это совершенно другой класс задач. А других открытых СУБД сопоставимого качества не встречал (имеются в виду, с поддержкой sql, а так есть токиокабинет и некоторые другие, наподобии берклидб, но последняя требует некоторого администрирования на этапе установки), даже если рассматривать все классы СУБД, в т.ч. общего назначения и встраиваемые.
| | |
|
|
|
|
|
|
| 1.32, Виталий (??), 19:00, 21/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Скажите как сделать веб интерфейс, я загрузил все сделал и поставил, как сделать чтобы открывалась через браузер, может кто нибудь написать ?
| | |
|
