Как в БД сделать только одно поле? Пишу чат и мне нужно где то хранить пароль от прав супер-администратора (который может добавлять других администраторов). Я решил что наверное буду задавать его при старте сервера, а хранить в БД. Но не знаю как сделать только одно поле под это дело. Неужели мне ради этого придется новую таблицу создавать? Т.е. новую сущность и новый список объектов этой сущности в контейнере... Может можно как то проще?
То есть у администратора других полей не будет? Любой, кто знает пароль супер-администратора, сможет добавлять администраторов? Или у него всё таки тоже будет логин?
А почему вы решили хранить его в базе данных, а не конфиге сервера?
Администратор - это такая же учетная запись как и все остальные. Только в таблице Roles у него будет флаг Admin, а у супер-администратора флаг SuperAdmin. Можете посмотреть вот тут Как правильно описать структуру БД? как я это все организовал. Смысл в том что по секретной комбинации клавиш выскакивает окошко, вводишь пароль, если он верный тебе даются права супер-администратора (и соответствующая пометочка в БД).
То есть вы хотите усложнить жизнь супер-администратору. Он должен будет вводить пароль, запоминать секретную комбинацию клавиш, вводить второй пароль и только после этого получит свои права?
С чего бы ему два раза вводить пароль? Нет, он сначала просто входит как обычный пользователь на сервер. Если он уже прописан в БД как супер-админ, то он входит уже супер-админом, иначе он после входа жмет комбинацию клавиш, вводит пароль, получает права и в следующий раз уже только просто входит.
DarkByte2015: ну и я не меньше раз. Авторизовываться нужно всем пользователям. Суперадминистратор вводит свой обычный пароль и всё. Зачем вам секретная комбинация. Пользователь либо системный администратор, либо нет.
1. Храните этот пароль в таблице пользователей. С каким нибудь особым именем. Можете с id=0
2. У вас странная база данных. Вы дублируете данные. Почему вы в таблице пользователей не указали id роли, а в таблице ролей лишь названия? Первый раз вижу такое решение, как у вас.
3. Вы реализовываете на c#. Посмотрите, что такое web.config. Может быть имеет смысл там задать пароль супер админа?
> Суперадминистратор вводит свой обычный пароль и всё. Зачем вам секретная комбинация.
Чтобы получить права суперадминистратора.
> 1. Храните этот пароль в таблице пользователей. С каким нибудь особым именем. Можете с id=0
Как то коряво звучит...
> 2. У вас странная база данных. Вы дублируете данные. Почему вы в таблице пользователей не указали id роли, а в таблице ролей лишь названия? Первый раз вижу такое решение, как у вас.
Это где же я их дублирую? Ни разу не дублирую... Но да, насчет структуры БД да и насчет всей этой админской фигни я уже весь мозг сломал. Ну хоть убей не знаю как правильно это все оформить. Никто мне не хочет говорить как делают в реальных проектах. Как сговорились все.
> 3. Вы реализовываете на c#. Посмотрите, что такое web.config. Может быть имеет смысл там задать пароль супер админа?
Мутная тема. Хотя возможно.... Только чем это будет отличаться от того что я предлагал в самом начале? Т.е. можно тогда уж тупо задать в коде константой хэш пароля и все.
> У вас десктопное приложение или сайт?
Десктоп.
> Обычный пользователь авторизовался. Ввёл вашу комбинацию - стал суперадмином? А так сколько угодно суперадминов - и на всех один пароль?
Да. Именно так. Но один пароль только для получения админки. Для авторизации то у них у всех разные пароли.
1. С описанной вами в пункте 5 реализацией - согласен, будет неправильно.
2. У вас две таблицы, завязанных на id пользователя. То есть, чтобы проверить принадлежность пользователя к какой-либо конфигурации вам нужно будет обойти две таблицы.
3. Заданное значение в web.config можете изменять не открывая кода вашего сервера. Не знаю, почему мутно. В данном файле хранятся настройки сервера. То есть, если ваш код будете продавать, заказчик сам сможет этот пароль установить.
> 2. У вас две таблицы, завязанных на id пользователя. То есть, чтобы проверить принадлежность пользователя к какой-либо конфигурации вам нужно будет обойти две таблицы.
Ну блин я не знаю. Можно вообще все в одной таблице сделать. Вы то как предлагаете?
> 3. Заданное значение в web.config можете изменять не открывая кода вашего сервера. Не знаю, почему мутно. В данном файле хранятся настройки сервера. То есть, если ваш код будете продавать, заказчик сам сможет этот пароль установить.
Ну да в принципе это плюс. Хорошо, вы можете подсказать какой настройкой там можно задать этот пароль? Я в конфигах почти ничего не понимаю. И кстати что за web.config? У меня такого нету, у меня только App.config.
p.s. Позабавило про продажу :) Нет, увы вся это морока ради диплома...
2. Я предлагаю хранить в одной таблице пользователей и id роли. В другой таблице id роли и расшифровка.
3. Не сразу понял как вы сервер создаете. У вас же отдельные проекты для клиента и сервера?
В проекте сервера нужно добавить файл Settings. Далее в папке Properties редактировать *.settings, то есть задать Name=Password, Value=ваш хэш. В зависиммости от того, выберете Scope=User/Application к нему разное обращение. Погуглите отличия scope
p.s. нет ничего более постоянного в проекте, чем то, что создано временно. Лучше сразу писать как на продажу. Потом допилите и будет реальный проект.
p.p.s. У нас такая курсовая, как у вас диплом - написать чат. Правда с web-интерфейсом.
2. А есть ли смысл вообще разносить это в разные таблицы? Просто расшифровка - это один единственный флаг. Ну что это за таблица такая в которой только один столбец?
3. Что такое scope? Settings? Я как то пытался разобраться с этой странной штукой, но мне кажется это бред какой то... Насколько я помню она хранит эти настройки где то черте где типа "C:\Users\User\AppData\LocalSettings..." Лазить туда чтобы поменять настройки? Увольте... Если бы оно создавало настройки рядом с приложением было бы збс, но я еще тогда сто лет назад узнавал поменять путь жуткий геморой, надо написать столько кода что лучше забить на это и написать свой класс с настройками сериализуя их в xml.
DarkByte2015:
2. Есть. Вы хотите поменять название роли - и вам придётся у каждого пользователя изменять данное значение.
Возможно, я не до конца точно выразился. Первая таблица User содержит IdRole, вторая таблица в вашем случае содержит 2 столбца и 3 строчки
Id Name
0 User
1 Admin
2 SuperAdmin
Примерно так. Своеобразный enum в базе данных.
3. Что то вы перепутали. Честно, лет сто назад - не знаю как это работало. в ту дирректорию, что вы указали, копируется файл настроек Windows-службы на время её работы. У сервера же он будет иметь имя NameProject.config и лежать рядом с исполняемым файлом.
Правой кнопкой по папке properties -> add new item -> выбираете settings. После открываете его в студии и редактируете. Там будет табличка как Excel
2. enum так или иначе есть, я же указывал там реально enum UserRole: User, Admin, SuperAdmin. Но я еще раз спрашиваю какой смысл в отдельной таблице если там всего лишь один столбец? Нет, ничего менять ни придется у каждого юзера. Просто добавить новый флаг в enum. И все, можно будет назначать этот флаг юзерам.
3. Да нет же! Вот сейчас специально протестил. Не создает он такого файла рядом с приложением. Только если appname.exe.config, но значения туда не пишутся.
Да точно кстати я нашел этот файл по пути: "C:\Users\User\AppData\Local\ConsoleApplication7\ConsoleApplication7.vshos_Url_h2wf3j4ryvcvg0h4vaqmhcwfdnaoojf0\1.0.0.0\user.config". В нем сохранились заданные в настройках данные.
DarkByte2015:
2. Вы измените User на Юзер - и всем пользователям обновлять?
3. Да, если вы записываете туда значение программно - он сохраняется не понятно где. Попробуйте выводить на экран поля, изменяя конфиг вручную.
2. Что им обновлять? Ничего им не надо обновлять. Название только в коде изменится. Enum - это же числовое значение. Оно как было так и останется.
3. Что значит выводить на экран? Что значит вручную? о_О Так или иначе настройки меняются программно. Просто для них можно сделать удобный интерфейс (но не в моем случае), но они все равно будут меняться программно.
DarkByte2015: Вы хотели захардкодить пароль супер админа. Я предлагаю вынести его в отдельный файл, специально для этого предназначенный, и изменять его значение.
Простой
