Здравствуйте, Keith, Вы писали:
я конечно может бтыь не понял всей глубины замысла, но по момему вы самостоятельно усложняете вопрос и потом боритесь с придуманой проблемой. Есть рол бейс секурити — пользуйтесь ней и нет проблем. Мало логин-пароль попробуйте сертификат — пусть босс носит сертификат на флешке если это критично.
Мне кажется что если безобасность столь критична — то лучше именно на ней и сосредосточится — на проверке буферов ввода, на механизмах аутентификации и авторизации — благо механизмы есть и придумывать самому не нужно, а не тратить время на решение проблем которые сами же и придумали решая совершенно стороние заачи.
это наверное не совсем то, что вы хотели бы услышать — но по моему это более правильно, чем то что вы делаете. Это всего лишь мнение — так, что его вполне можно игнорировать
Здравствуйте, Keith, Вы писали:
K> Для меня более странным является секьюрное требование отсутствия строки подключения на клиенте (даже по частям и в зашифрованном виде) из-за чего приходится городить сервер приложения с которым общаются все клиенты и который общается с БД. K> Т.е. схема такая: K> Клиент -> Сервер приложения -> БД.
Если есть аппсервер самое простое — ограничить логин пользователей по айпи адресам или учетным записям компьтеров в домене. Удаление функционала ничего особо не даст, узнав пароль найти инсталяху директорской версии уже не так сложно. Еще следует добавить аудит и слать письмо админу если директор вдруг вошел с другого компа. Зная об аудите сотрудники станут гораздо меньше прыти проявлять в этом плане.
Здравствуйте, Ziaw, Вы писали:
Z>Если есть аппсервер самое простое — ограничить логин пользователей по айпи адресам или учетным записям компьтеров в домене. Удаление функционала ничего особо не даст, узнав пароль найти инсталяху директорской версии уже не так сложно.
Интересно, как это они ее достанут?
К директорскому компу доступ будет только у директора.
Вы то же думаете, что лучше одно приложение делать? Даже если в случае с тремя приложениями они будут в одном солюшене лежать?
Здравствуйте, DashkovAndrey, Вы писали:
DA>я конечно может бтыь не понял всей глубины замысла, но по момему вы самостоятельно усложняете вопрос и потом боритесь с придуманой проблемой. Есть рол бейс секурити — пользуйтесь ней и нет проблем. Мало логин-пароль попробуйте сертификат — пусть босс носит сертификат на флешке если это критично.
Спасибо за идею сертификата.
DA>Мне кажется что если безобасность столь критична — то лучше именно на ней и сосредосточится — на проверке буферов ввода, на механизмах аутентификации и авторизации — благо механизмы есть и придумывать самому не нужно, а не тратить время на решение проблем которые сами же и придумали решая совершенно стороние заачи.
Секьюрити важно только в нескольких местах.
В частности, не хочется разворачивать у менеджеров .net приложение, которое содержит всю логику, включая директорский функционал —
могут заморочится и попробовать обойти защиту стандартных логинов/паролей. Обфусцировать то же не желательно.
DA>это наверное не совсем то, что вы хотели бы услышать —
Почему же я стараюсь не иметь предвзятых мнений и вообще как бы сторонний наблюдатель
DA>но по моему это более правильно, чем то что вы делаете.
Пока что еще ничего не делаем в этом направлении.
DA>Это всего лишь мнение — так, что его вполне можно игнорировать
Зачем же
зы Скажу честно — я бы и сервер приложения не стал городить из-за возможности выяснить строку подключения — лучше уж шифровать ее и хранить по частям, чем геморой с передачей объектов с сервера на клиент и обратно.
Здравствуйте, Keith, Вы писали:
K> Интересно, как это они ее достанут? K> К директорскому компу доступ будет только у директора.
А как они достали пароль директора, если доступ к паролю был только у директора? Достать пароль диретокра в домене будет сложнее? У меня подозрение, что с таким подходом к безопасности пароль может просто совпадать.
K> Вы то же думаете, что лучше одно приложение делать? Даже если в случае с тремя приложениями они будут в одном солюшене лежать?
Да, приложение одно в любом случае, худший вариант 3 вида гуя в разных dll. Лучший — когда ГУЙ сам знает как себя рисовать в зависимости от привилегий пользователя.
Здравствуйте, Ziaw, Вы писали:
K>> Интересно, как это они ее достанут? K>> К директорскому компу доступ будет только у директора.
Z>А как они достали пароль директора, если доступ к паролю был только у директора?
Директор может пароль на бумажке держать а потом ее выкинуть
Ну вы сами наверняка знаете, что главное в "хакерстве" — это социальная инженерия, а человек — самое тонкое место
Z>Достать пароль диретокра в домене будет сложнее? У меня подозрение, что с таким подходом к безопасности пароль может просто совпадать.
Сейчас не используется проверка логина в домене винды — авторизация на своих логинах/паролях, которые лежат в БД.
K>> Вы то же думаете, что лучше одно приложение делать? Даже если в случае с тремя приложениями они будут в одном солюшене лежать? Z>Да, приложение одно в любом случае, худший вариант 3 вида гуя в разных dll. Лучший — когда ГУЙ сам знает как себя рисовать в зависимости от привилегий пользователя.
Я имел ввиду, что проще:
— один проект в котором if'ами разруливается поведение ГУЯ в зависимости от роли или
— три проекта, каждый из которых знает только о своих отличиях (в зависимости от роли) от общего функционала, лежащего в общей библиотеке?
Z>>Да, приложение одно в любом случае, худший вариант 3 вида гуя в разных dll. Лучший — когда ГУЙ сам знает как себя рисовать в зависимости от привилегий пользователя.
K> Я имел ввиду, что проще: K> — один проект в котором if'ами разруливается поведение ГУЯ в зависимости от роли или
Не вижу ничего страшного в таких if-ах.
if (userRole.IsStaticticReportAllowed())
{
ShowStaticticReportGUI();
}
K> — три проекта, каждый из которых знает только о своих отличиях (в зависимости от роли) от общего функционала, лежащего в общей библиотеке?
K> Сейчас не используется проверка логина в домене винды — авторизация на своих логинах/паролях, которые лежат в БД.
Зная пароль в домене получаем программу по сети. Лучший способ избавиться от нежелательных действий подобного рода — аудит. И доведение до всех, что этот аудит проводится.
Z>>Да, приложение одно в любом случае, худший вариант 3 вида гуя в разных dll. Лучший — когда ГУЙ сам знает как себя рисовать в зависимости от привилегий пользователя.
K> Я имел ввиду, что проще: K> — один проект в котором if'ами разруливается поведение ГУЯ в зависимости от роли или K> — три проекта, каждый из которых знает только о своих отличиях (в зависимости от роли) от общего функционала, лежащего в общей библиотеке?
Я же ответил — лучший вариант это "if'ы". На каждой форме должен быть навешан набор привилегий при которых она вообще способна показываться, далее уже презентер устанавливает disabled/readonly флаги на нужные куски в зависимости от набора привелегий.
Здравствуйте, Kore Sar, Вы писали:
K>> Я имел ввиду, что проще: K>> — один проект в котором if'ами разруливается поведение ГУЯ в зависимости от роли или
KS>Не вижу ничего страшного в таких if-ах. KS>if (userRole.IsStaticticReportAllowed()) KS>{ KS> ShowStaticticReportGUI(); KS>}
Логика преставления, т.е. презентер в таком случае будет иметь множество методов для каждой роли, а не только для вывода отчетов.
Например куча контролов, которые надо прятать для одной роли и показывать для другой. Работа с общими контролами то же будет меняться в зависимости от роли... Классы будут большими, а какой метод для какой роли вызывается будет сложновато понимать без комментариев, против которых я ничего не имею, но стараюсь, чтобы код можно было понять и без них.
В случае же с тремя приложениями (пректами в студии) каждое приложения определенной роли будет использовать общую логику и дополнительно знать только о своих отличиях.
зы На самом деле, я это только представляю и спорю лишь чтобы сохранить объективность рассматриваемого вопроса.
Опыта в работе с несколькими приложениями, как я говорил, у меня нет, но и веских аргументов против трех приложений я еще не видел.
Здравствуйте, Ziaw, Вы писали:
K>> Сейчас не используется проверка логина в домене винды — авторизация на своих логинах/паролях, которые лежат в БД. Z>Зная пароль в домене получаем программу по сети.
Вопросы сетевой безопасности решаются параллельно. Я их не рассматриваю, т.к. это не яляется большой проблемой.
Z>Лучший способ избавиться от нежелательных действий подобного рода — аудит. И доведение до всех, что этот аудит проводится.
Аудит ведется, но наверно не в том виде, как вы это понимаете — в БД записываются операции над объектами и логин пользователя, который совершил изменения.
В принципе, это позволит выявить нежелательные действия, но уже после того, как они будут совершены, что естественно не желательно.
Z>Я же ответил — лучший вариант это "if'ы". На каждой форме должен быть навешан набор привилегий при которых она вообще способна показываться, далее уже презентер устанавливает disabled/readonly флаги на нужные куски в зависимости от набора привелегий.
Здравствуйте, Keith, Вы писали:
K>зы Скажу честно — я бы и сервер приложения не стал городить из-за возможности выяснить строку подключения — лучше уж шифровать ее и хранить по частям, чем геморой с передачей объектов с сервера на клиент и обратно.
признаюсь чесно я не перечитал все посты — рекомендации котрые вам накидали... судя из того, что я понял, вы опасаетесь того что код может попсть в чужие руки, делайте Web прилодение — соответсвенно код на сервере, клиент получит тупую страничку. при правильной организации приложения добавить Web клиента не проблема. Относительно строки подключения — IIS настроен так чтобы не отдавать файл с названием web.config, но даже в случае если он его отдаст, то ASP.Net позволяет использовать RSA алгоритм для шифрования частей файла. посмотритие на назначение утилит aspnet_regiis.exe и aspnet_setreg.exe. охрана самого сервера — это уже административный вопрос.
еще раз подчеркну мысль: наверное стоит сосредосточится на тех секурных фичах котрые уже есть чем изобретать что-то свое... ведь наверняка не вы первый сталкиваетесь с подобной задачей и для этого и придуманы права пользователей на машине, рол бейс для приложенией, сертификаты и др.
Здравствуйте, Keith, Вы писали:
K>Здравствуйте, Kore Sar, Вы писали:
K>>> Я имел ввиду, что проще: K>>> — один проект в котором if'ами разруливается поведение ГУЯ в зависимости от роли или
KS>>Не вижу ничего страшного в таких if-ах. KS>>if (userRole.IsStaticticReportAllowed()) KS>>{ KS>> ShowStaticticReportGUI(); KS>>}
K> Логика преставления, т.е. презентер в таком случае будет иметь множество методов для каждой роли, а не только для вывода отчетов. K> Например куча контролов, которые надо прятать для одной роли и показывать для другой. Работа с общими контролами то же будет меняться в зависимости от роли... Классы будут большими, а какой метод для какой роли вызывается будет сложновато понимать без комментариев, против которых я ничего не имею, но стараюсь, чтобы код можно было понять и без них.
Имя метода подлинее, пояснее, и всё будет хорошо.
Пусть лучше будет 100 виртуальных функций, чем 300 классов гёув по презентёру на каждого. Верно говорю?
K> В случае же с тремя приложениями (пректами в студии) каждое приложения определенной роли будет использовать общую логику и дополнительно знать только о своих отличиях.
И будет у вас файлов в солюшене в три раза больше.
K>зы На самом деле, я это только представляю и спорю лишь чтобы сохранить объективность рассматриваемого вопроса. K> Опыта в работе с несколькими приложениями, как я говорил, у меня нет, но и веских аргументов против трех приложений я еще не видел.
Как я уже говорил, чем меньше файлов (классов) — тем быстрее разработка.
Здравствуйте, Kore Sar, Вы писали:
KS>Имя метода подлинее, пояснее, и всё будет хорошо.
Я не против длинных имен методов
KS>Пусть лучше будет 100 виртуальных функций, чем 300 классов гёув по презентёру на каждого. Верно говорю?
Не совсем понял зачем функциям быть виртуальными в случае, если логика для разных ролей будет в одном классе.
К тому же в этом случае я боюсь разрастания формы и контролов — контролы могут друг на друга накладываться и редактировать их будет не удобно.
K>> В случае же с тремя приложениями (пректами в студии) каждое приложения определенной роли будет использовать общую логику и дополнительно знать только о своих отличиях. KS>И будет у вас файлов в солюшене в три раза больше.
Ну это уж не самое страшное, если учесть, что навигация по одному длинному файлу может быть не быстрее, чем по трем коротким.
K>>зы На самом деле, я это только представляю и спорю лишь чтобы сохранить объективность рассматриваемого вопроса. K>> Опыта в работе с несколькими приложениями, как я говорил, у меня нет, но и веских аргументов против трех приложений я еще не видел. KS>Как я уже говорил, чем меньше файлов (классов) — тем быстрее разработка.
Ну с этим уж точно не соглашусь
Можно иметь на каждую сущность предметной области по классу, а можно иметь на все сущности один класс — DataTable. Мне проще в этом случае, когда классов больше Да и не только в этом случае — многие согласятся, что наследование лучше кучи if'ов, хотя классов при наследовании больше.
Здравствуйте, DashkovAndrey, Вы писали:
DA>признаюсь чесно я не перечитал все посты — рекомендации котрые вам накидали... судя из того, что я понял, вы опасаетесь того что код может попсть в чужие руки, делайте Web прилодение — соответсвенно код на сервере, клиент получит тупую страничку. при правильной организации приложения добавить Web клиента не проблема. Относительно строки подключения — IIS настроен так чтобы не отдавать файл с названием web.config, но даже в случае если он его отдаст, то ASP.Net позволяет использовать RSA алгоритм для шифрования частей файла. посмотритие на назначение утилит aspnet_regiis.exe и aspnet_setreg.exe. охрана самого сервера — это уже административный вопрос.
К сожалению, пользовательский интерфейс должен быть rich, а на WPF переделывать уже поздно.
DA>еще раз подчеркну мысль: наверное стоит сосредосточится на тех секурных фичах котрые уже есть чем изобретать что-то свое... ведь наверняка не вы первый сталкиваетесь с подобной задачей и для этого и придуманы права пользователей на машине, рол бейс для приложенией, сертификаты и др.
Здравствуйте, Keith, Вы писали:
K> Не совсем понял зачем функциям быть виртуальными в случае, если логика для разных ролей будет в одном классе. K> К тому же в этом случае я боюсь разрастания формы и контролов — контролы могут друг на друга накладываться и редактировать их будет не удобно.
Не надо ничего накладывать, это действительно неудобно. Делите форму на области в которые вставляйте при необходимости нужные контролы.
K> Ну с этим уж точно не соглашусь K> Можно иметь на каждую сущность предметной области по классу, а можно иметь на все сущности один класс — DataTable. Мне проще в этом случае, когда классов больше Да и не только в этом случае — многие согласятся, что наследование лучше кучи if'ов, хотя классов при наследовании больше.
От логики ифов вы все равно не избавитесь, просто перенесете их в фабрику. Это вполне нормальный подход. Если формы начинают сильно различаться проще их разделить. IoC контейнер в руки и вперед .
Здравствуйте, Ziaw, Вы писали:
K>> Не совсем понял зачем функциям быть виртуальными в случае, если логика для разных ролей будет в одном классе. K>> К тому же в этом случае я боюсь разрастания формы и контролов — контролы могут друг на друга накладываться и редактировать их будет не удобно. Z>Не надо ничего накладывать, это действительно неудобно. Делите форму на области в которые вставляйте при необходимости нужные контролы.
Хочется, чтобы в дизайнере форм можно было с формами удобно работать.
Если программно конструировать контролы, то не удобно проверять их внешний вид.
K>> Ну с этим уж точно не соглашусь K>> Можно иметь на каждую сущность предметной области по классу, а можно иметь на все сущности один класс — DataTable. Мне проще в этом случае, когда классов больше Да и не только в этом случае — многие согласятся, что наследование лучше кучи if'ов, хотя классов при наследовании больше. Z>От логики ифов вы все равно не избавитесь, просто перенесете их в фабрику. Это вполне нормальный подход.
Вполне избавлюсь, если в приложении директора будет лишь расширение приложения менеджера с помощью наследования.
Z>Если формы начинают сильно различаться проще их разделить.
А тестировать потом то же по отдельности?
Z>IoC контейнер в руки и вперед .
IoC уже в руках и именно с его помощью я собирался конфигурировать директорское приложение на использование унаследованных расширенных форм и презентеров.
Кстати, сейчас вот возник вопрос — а можно ли редактировать в дизайнере форму, унаследованную от другой формы?
Т.е. можно ли редактировать в дизайнере класс как форму, если он унаследован от формы?
Здравствуйте, Keith, Вы писали:
K> Хочется, чтобы в дизайнере форм можно было с формами удобно работать. K> Если программно конструировать контролы, то не удобно проверять их внешний вид.
Z>>От логики ифов вы все равно не избавитесь, просто перенесете их в фабрику. Это вполне нормальный подход.
K> Вполне избавлюсь, если в приложении директора будет лишь расширение приложения менеджера с помощью наследования.
Это в теории красиво, на практике наследование GUI ничего кроме головной боли не приносит.
Z>>Если формы начинают сильно различаться проще их разделить.
K> А тестировать потом то же по отдельности?
Естественно, это чуть проще чем тестировать одну форму которая отображается несколькими кардинально отличающимися способами.
Z>>IoC контейнер в руки и вперед .
K> IoC уже в руках и именно с его помощью я собирался конфигурировать директорское приложение на использование унаследованных расширенных форм и презентеров. K> Кстати, сейчас вот возник вопрос — а можно ли редактировать в дизайнере форму, унаследованную от другой формы? K> Т.е. можно ли редактировать в дизайнере класс как форму, если он унаследован от формы?
Смотря что подразумевается под редактировать. Я уже писал, теоретически можно, на практике мы потом каленым железом выжигали унаследованные контролы как только нашли время.
Здравствуйте, Keith, Вы писали:
K>Здравствуйте, Kore Sar, Вы писали:
KS>>Имя метода подлинее, пояснее, и всё будет хорошо.
K> Я не против длинных имен методов
KS>>Пусть лучше будет 100 виртуальных функций, чем 300 классов гёув по презентёру на каждого. Верно говорю?
K> Не совсем понял зачем функциям быть виртуальными в случае, если логика для разных ролей будет в одном классе.
Ну, в принципе это зависит от реализации.
K> К тому же в этом случае я боюсь разрастания формы и контролов — контролы могут друг на друга накладываться и редактировать их будет не удобно.
А вы не делайте по контролу для каждого из трёх приложений. Делайте один универсальный.
K>>> В случае же с тремя приложениями (пректами в студии) каждое приложения определенной роли будет использовать общую логику и дополнительно знать только о своих отличиях. KS>>И будет у вас файлов в солюшене в три раза больше.
K> Ну это уж не самое страшное, если учесть, что навигация по одному длинному файлу может быть не быстрее, чем по трем коротким.
Навигация — это одно. А редактирование в трёх местах сложнее, чем в одном. К тому же одинаковая навигация по трём коротким классам будет еще напряжнее, чем одна навигация по одному длинному.
K>>>зы На самом деле, я это только представляю и спорю лишь чтобы сохранить объективность рассматриваемого вопроса. K>>> Опыта в работе с несколькими приложениями, как я говорил, у меня нет, но и веских аргументов против трех приложений я еще не видел. KS>>Как я уже говорил, чем меньше файлов (классов) — тем быстрее разработка.
K> Ну с этим уж точно не соглашусь K> Можно иметь на каждую сущность предметной области по классу, а можно иметь на все сущности один класс — DataTable. Мне проще в этом случае, когда классов больше Да и не только в этом случае — многие согласятся, что наследование лучше кучи if'ов, хотя классов при наследовании больше.
Во время разработки — может быть Вы и правы. Но дальнейший суппорт (который чаще делают не те, кто разрабатывал) будет более проблемным.
Здравствуйте, Ziaw, Вы писали:
Z>>>От логики ифов вы все равно не избавитесь, просто перенесете их в фабрику. Это вполне нормальный подход. K>> Вполне избавлюсь, если в приложении директора будет лишь расширение приложения менеджера с помощью наследования. Z>Это в теории красиво, на практике наследование GUI ничего кроме головной боли не приносит.
Главное чтобы сила этой боли не была больше той боли, которую можно испытать от редактирования большога файла, включающего логику всех ролей.
Z>>>Если формы начинают сильно различаться проще их разделить. K>> А тестировать потом то же по отдельности? Z>Естественно, это чуть проще чем тестировать одну форму которая отображается несколькими кардинально отличающимися способами.
"Чуть" — это очень относительно. Наверное, придется пробовать самому оба подхода ибо универсальной выигрышности одного подхода не видно.
Z>>>IoC контейнер в руки и вперед . K>> IoC уже в руках и именно с его помощью я собирался конфигурировать директорское приложение на использование унаследованных расширенных форм и презентеров. K>> Кстати, сейчас вот возник вопрос — а можно ли редактировать в дизайнере форму, унаследованную от другой формы? K>> Т.е. можно ли редактировать в дизайнере класс как форму, если он унаследован от формы? Z>Смотря что подразумевается под редактировать. Я уже писал, теоретически можно, на практике мы потом каленым железом выжигали унаследованные контролы как только нашли время.
Что подразумевается под унаследованными контролами?
Контрол, содержащий группу простых контролов или сложный контрол с хитрым поведением, заточенный под конкретное приложение?
Здравствуйте, Kore Sar, Вы писали:
K>> К тому же в этом случае я боюсь разрастания формы и контролов — контролы могут друг на друга накладываться и редактировать их будет не удобно. KS>А вы не делайте по контролу для каждого из трёх приложений. Делайте один универсальный.
Я бы рад, но бизнес-логика иногда может требовать разных контролов в одном и том же месте для разных ролей.
K>>>> В случае же с тремя приложениями (пректами в студии) каждое приложения определенной роли будет использовать общую логику и дополнительно знать только о своих отличиях. KS>>>И будет у вас файлов в солюшене в три раза больше. K>> Ну это уж не самое страшное, если учесть, что навигация по одному длинному файлу может быть не быстрее, чем по трем коротким. KS>Навигация — это одно. А редактирование в трёх местах сложнее, чем в одном. К тому же одинаковая навигация по трём коротким классам будет еще напряжнее, чем одна навигация по одному длинному.
Придется пробовать оба подхода, чтобы найти отличия для моего приложения
KS>>>Как я уже говорил, чем меньше файлов (классов) — тем быстрее разработка. K>> Ну с этим уж точно не соглашусь K>> Можно иметь на каждую сущность предметной области по классу, а можно иметь на все сущности один класс — DataTable. Мне проще в этом случае, когда классов больше Да и не только в этом случае — многие согласятся, что наследование лучше кучи if'ов, хотя классов при наследовании больше. KS>Во время разработки — может быть Вы и правы. Но дальнейший суппорт (который чаще делают не те, кто разрабатывал) будет более проблемным.
Все равно не согласен — Поддерживать набор классов с красивой иерархией легче, чем один класс с кучей if'ов.
