|
|
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
Добрый вечер коллеги! Интересует следующее: чем и насколько чревата имитация создания пользователей "программным" способом. Поясню - речь идет о том, чтобы вместо использования механизма создания и подключения пользователей на стороне сервера, использовать подключение под одним и тем же пользователем для всех. Таким образом, при создании аккаунта мы уходим от понятия логина (при авторизации будет комбобокс с ФИО-ми), пароль же будет шифроваться в мд5 и хранится в таблице пользователей. Такой метод я еще не использовал, обходился классическим способом, но заказчик категорически против логинов :) Хочет чтобы их не было совсем. Пришлось придумать вышеописанное :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2015, 20:36 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
rtfm trusted autentification ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2015, 21:24 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
Softologic, Ну, например, чревато отсутствием разграничения прав доступа на уровне базы (использвания прав ролей/пользователей), отсутствие вменяемого журналирования действий пользователей в процедурах/триггерах. Проблему можно решить приблизительно так: 1. Создаётся таблица соответствия логинов и отображаемых имён пользователей. Логины создаются автоматически (при добавлении пользователей либо простой нумерацией "USER1", "USER2" и т.п., либо преобразованием кирилицы в латиницу "Иванов П.С." -> "IVANOV_P_S", либо ещё хэш знает как-нибудь). 2. Перед подключением пользователя происходит подключение под специальной учётной записью, которая может читать только эту таблицу соответствий. Пользователь выбирает из списка себя и выполняет соединение уже под своим логином. Сами логины в списке выбора можно и не отображать, чтобы заказчик не кипятился. Ну, или, как уже подсказали выше, можно использовать trusted autentification. Тогда пользователю вообще ничего вводить не надо, но есть некоторые но. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2015, 21:39 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
trusted autentification не подойдет. По той причине, что перелогиниваться через выход из системы не вариант - долго (розничная точка с большой проходимостью в торговом центре в мск) и нужны параллельно открытые программы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2015, 21:42 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
Softologicперелогиниваться через выход из системы не вариант А зачем вообще перелогиниваться-то? Раз уж начальству пофиг на безопасность, разграничение прав и всё остальное, что написали выше, то зачем вообще имена пользователей? Пусть все работают под одним SYSDBA. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2015, 21:46 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovРаз уж начальству пофиг на безопасность... На это может и пофиг, но, скорей всего, это просто широко распространённый синдром "не-хочу-печатать-много-букв-хочу-тыкать-мышкой". Ведь "и-так-пароль-набирать-приходится"! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2015, 21:52 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovSoftologicперелогиниваться через выход из системы не вариант А зачем вообще перелогиниваться-то? Раз уж начальству пофиг на безопасность, разграничение прав и всё остальное, что написали выше, то зачем вообще имена пользователей? Пусть все работают под одним SYSDBA. Разграничение прав он видит в двух вариантах - SYSDBA (неогран. права) и все остальные (с ограниченными правами, настраиваемые и реализуемые программно). Как то так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2015, 21:54 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
SoftologicКак то так.Это НЕ разграничение прав. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2015, 21:58 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
dennis-rSoftologicКак то так.Это НЕ разграничение прав. :) На уровне базы согласен, но на уровне программы вполне. В общем, скорее всего сделаю с автогенерацией логинов все же. Спасибо всем за комментарии и советы! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2015, 22:01 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
у меня в одной системе сделано именно так программа ходит в базу под одним логином и паролем в зависимости от того, какой пароль вводят, перелогинивается с найденной ролью в базе и программе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2015, 22:29 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
Softologic, да сделай логин и пароль тупо одним и тем же ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 00:01 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
SoftologicДобрый вечер коллеги! Интересует следующее: чем и насколько чревата имитация создания пользователей "программным" способом. достаточно давно пользуюсь данным методом, могу поделиться наработками, есть уже готовый механизм управления пользователями, правами, форма ввода логина, и т.д. где то на форуме уже выкладывал пример, найду повторю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 06:16 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
Пример правда староват Delphi 2007 test.rar ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 06:20 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
Softologic, Когда-то давно делал как у Вас описано: - таблица юзеров с шифр. паролями, ФИО, даже аватар))) - подключение к БД идет только под SYSDBA, - при заходе в программу имя выбирается из списка, - есть тип пользователя и взависимости от него настраивается вид приложения (доступность пунктов меню) - ID пользователя, тип хранятся глобально после входа в проложение, - количество однеовременно запущенных копий приложения на 1 машине неограничено (даже под одним логином) - при необходимости в параметрах запросов перадается ID пользователя (если надо зафиксировать его действия, например пометить что запись удаленена и кем) Как-то так... Без проблем работало не один год, нареканий не было. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 08:09 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
Softologictrusted autentification не подойдет. По той причине, что перелогиниваться через выход из системы не вариант - долго (розничная точка с большой проходимостью в торговом центре в мск) и нужны параллельно открытые программы...Ужоснах. Шляются все кому не лень, работают с деньгами и лень заводить пароль? Страна непуганых идиотов, простите мой аглицкий. Кури в строну УСБ токенов и аутентификация оными в домене винды, далее трастет аутентификация. У каждого юзера свой токен на шее на веревочке, отошел комп заблокировался, пришел, воткнул в разъем, разблокировался. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 09:01 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
kaktus1983, не надо ходить обычным пользователям под SYSDBA. Если уже надо всем ходить под одним пользователем, то заведи отдельного и дай ему все права. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 09:33 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
У нас пользователи программные. SQL-пользователь для юзеров свой - бесправный. Коннект приложения выполняют только с указанием роли. SQL-ролей с правами на таблицы, вьюхи, процедуры в базе по необходимости несколько. Роль для приложения прописана каждому жёстко. А вот права юзерам ещё и дополнительно прописываются программно (кто какую роль в системе имеет право выполнять: начальник, кассир, бухгалтер и т.п.). Каждая программа коннектится к базе общим бесправным SQL-пользователем своей SQL-ролью. Авторизует пользователя программно по логину/паролю, проверяет его права и уже только после этого впускает в интерфейс, если тот имеет право. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 10:03 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
o_v_aУ нас пользователи программные. SQL-пользователь для юзеров свой - бесправный. Коннект приложения выполняют только с указанием роли. SQL-ролей с правами на таблицы, вьюхи, процедуры в базе по необходимости несколько. Роль для приложения прописана каждому жёстко. А вот права юзерам ещё и дополнительно прописываются программно (кто какую роль в системе имеет право выполнять: начальник, кассир, бухгалтер и т.п.). Каждая программа коннектится к базе общим бесправным SQL-пользователем своей SQL-ролью. Авторизует пользователя программно по логину/паролю, проверяет его права и уже только после этого впускает в интерфейс, если тот имеет право. программные пользователи - признак того, что разработчики не знают СУБД :) кроме SELECT, UPDATE, INSERT и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 12:30 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
MaratIsk, еще программные пользователи - признак трехзвенки. Потому что обычные пользователи в web или трехзвенке нафиг не нужны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 16:16 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
Hello, Kdv! You wrote on 11 июня 2015 г. 17:10:10: Kdv> еще программные пользователи - признак трехзвенки. > Потому что обычные пользователи в web или трехзвенке нафиг не нужны. +500 Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 17:09 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
kdvMaratIsk, еще программные пользователи - признак трехзвенки. Потому что обычные пользователи в web или трехзвенке нафиг не нужны. А можно поподробнее пожалуйста, почему они (в web или трехзвенке) не нужны? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 18:01 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
Softologic, в вебе по многим причинам. Начиная с того, что зачастую в вебе пользователи добавляются автоматом при регистрации, а для добавление пользователя в СУБД нужны не маленькие права. Никто в здравом уме не даст выполнять DDL запросы при каждой регистрации пользователя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 18:04 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
SoftologicА можно поподробнее пожалуйста, почему они (в web или трехзвенке) не нужны? во-первых, количество коннектов к СУБД в трехзвенке или веб обычно не равно и сильно меньше, чем коннектов в клиент-сервере. Иначе смысл трехзвенки теряется. во-вторых, исходя из первого пункта, пользователь не может быть извне спроецирован на коннект к СУБД. И это не нужно. Потому что пользователей веба или трехзвенки может быть миллионы, но одновременно будут работать максимум тысячи или десятки тысяч (есть такой принцип, понятый еще в телефонии - трехзвенкой была "барышня", которая соединяла абонентов). отсюда следует, что - права пользователей веба или трехзвенки регулируются правами веба или трехзвенки, а не СУБД, тем более что система прав веба или трехзвенки может совсем не совпадать с правами SQL (как минимум, разграничение доступа на уровне записей). - соответственно, для веба (всяческие форумы, e-commerce, e-education и проч) обычно требуется только 1 пользователь СУБД (не SYSDBA). Для трехзвенки пользователей может быть потребуется побольше, зависит от системы. И т.д. как-то так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 18:14 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
Симонов Денисkaktus1983, не надо ходить обычным пользователям под SYSDBA. Если уже надо всем ходить под одним пользователем, то заведи отдельного и дай ему все права. kdv обычно требуется только 1 пользователь СУБД (не SYSDBA). Подскажите, а чем чревато если этот 1 пользователь будет именно SYSDBA, при условии, что добавление пользователей и ролей в будущем исключается? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 20:03 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
kaktus1983Подскажите, а чем чревато если этот 1 пользователь будет именно SYSDBA, да ё-мое. для SYSDBA не выполняются никакие проверки прав, и на него не действует shutdown БД. Фактически это root для СУБД. Существует масса систем, в которых "все пользователи - SYSDBA", из-за чего как раз проблемы с shutdown. Тут уже говорили, что если не хотите N пользователей СУБД - создайте ОДНОГО, и дайте ему все права. Но он не будет SYSDBA. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 20:16 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
Как так, shutdown full разве не всем запрещает соединяться с БД, включая SYSDBA? "full - Shutdown and don't allow any connections from anyone, even SYSDBA or the database owner." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 20:23 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
MrCat, дальше-то что? я вам предлагаю разобраться с режимами shutdown, для чего каждый режим нужен. Нормальный режим - это когда мы запрещаем доступ ПОЛЬЗОВАТЕЛЯМ оставляя доступ SYSDBA для осуществления регламентных операций. В этом случае, если каждый юзер SYSDBA, выполнение регламентных операций по факту невозможно, т.к. shutdown в этом режиме не приводит к реальному shutdown. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 20:36 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
Я вполне понимаю, как использовать эти режимы по уму, и что всем сидеть под SYSDBA|OWNER чревато не спорю. Внезапный DDL чего стоит. Мне непонятно откуда "куча" проблем с shutdown, когда пользователь один. Если требуется отрубить пользователей, то вполне хватает и shutdown single. Если после него удаётся начать обслуживание - ок, больше никто не помешает. Если нет - значит подцепился пользователь и обслужить не выйдет, обслуживание аварийно завершается. БД при этом остаётся в частичном shutdown'е, но вернёть её в online не проблема. "Да, ужас, но не ужас-ужас" =) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 20:51 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
MrCatто вполне хватает и shutdown single. ага. юзеры при внезапном дисконнекте к БД начинают "тыкать в приложение", в резульатате этим самым single sysdba может оказаться кто угодно, только не настоящий sysdba. В любом случае, массово пользователи НЕ должны работать под рутом. Аминь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 21:54 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
в результате этим самым single sysdba может оказаться кто угодно Верно. Но в приложениях, в которых один пользователь БД, разграничением прав занимается само приложение. А это значит, что даже если пользователь SYSDBA-обычный успеет подрубиться в паузе между shutdown single и SYSDBA-админом, то он не натворит ничего страшнее того, чего он мог бы натворить и без shutdown single - приложение не даст. Да и времени у него не так много на реконнект, т.к. пауза - кратчайшая. И какой смысл "создать пользователя, отличного от SYSDBA, но дать ему все права на БД"? Он наворотит бед не меньше, чем SYSDBA. Ну разве что базу не удалит (если только он не DB OWNER). Второго пользователя надо сильно поражать в правах, DDL запрещать, хотя бы на физические данные. Но тут мы выходим за рамки темы, ТС говорит про одного пользователя. И да, я ни в коем случае не говорю, что один пользователь на БД - хорошая идея. Плохая. Но не смертельная. Как рыба фугу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 22:51 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
MrCat, разница большая. Владелец БД он хотя бы может творить что угодно только со своей БД. А SYSDBA с любой которая находится на том же сервере. DDL до тройки ты всё равно не запретишь. По крайней мере создание объектов метаданных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2015, 23:03 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
Имхо, оправдание работе клиентов под sysdba только одно - лень заводить юзера при инсталляции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2015, 10:45 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
MaratIskпрограммные пользователи - признак того, что разработчики не знают СУБД :) кроме SELECT, UPDATE, INSERT и т.д. Видимо, мусью просто не имел опыта разработки систем из десятков приложений, которые рождаются в течение десятков лет в процессе автоматизации сложных техпроцессов уровня предприятия со сложной иерархией должностных обязанностей персонала. Про трёхзвенку тоже верно приметили. Есть такое дело. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2015, 10:50 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
Softologictrusted autentification не подойдет. По той причине, что перелогиниваться через выход из системы не вариант - долго (розничная точка с большой проходимостью в торговом центре в мск) и нужны параллельно открытые программы... Используешь т.н. "Mixed model autentification": 1. По умолчанию - trusted autentification. 2. Если юзер хочет перелогиниться - используем Native. То есть, ручками логин+пароль. 3. При удачном коннекте (правильный логин+пароль) запоминаем имя пользователя (в реестре, например). 4. При следующем коннекте "вспоминаем" логин и, если он совпадает с именем юзера Windows => trusted autentification. Иначе => снова native. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2015, 22:59 |
|
||
|
Программные пользователи. Чревато?
|
|||
|---|---|---|---|
|
#18+
Приложение подключается с ролью "АРМ". Логин/пароль trusted или шифрован в реестре/xml. Авторизация пользователя - картой/штрихкодом/паролем. Пишется user_id в SET_CONTEXT. Во все операции/хранимые процедуры/логи пишется user_id из GET_CONTEXT. Как-то так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2015, 09:40 |
|
||
|
|
start [/forum/topic.php?all=1&fid=40&tid=1562775]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
37ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
67ms |
get tp. blocked users: |
2ms |
| others: | 273ms |
| total: | 423ms |
| 0 / 0 |
