Хранить строку в приложении

@Kyra90 · Регистрация: 06.10.2020

Студворк — интернет-сервис помощи студентам

Всем привет. Помогите, пожалуйста с курсовой.
Значит задача: Создать приложение с пользовательским доступом (логин/пароль, пользователь может быть пользователем, может быть админом). Значит я делаю следующим образом: В программу уже вшит пользователь "Администратор", при первом запуске предлагается создать ему пароль. Как только пароль создан рядом с приложением создается папка "Users" (по ее наличию, собственно, и проверяется первый запуск), где в файлах в зашифрованном виде хранится информация о пользователе.

Препод говорит, что это не совсем правильное решение, и файла с данными "Администратор" в папке с пользователями быть не должно, так как (цитирую дословно) "Я скопирую пользователей в другое место, прибью папку Users, запущу программу и получу доступ к Администратору, снова введя пароль, потом верну пользователей назад"

Можно ли как то хранить строковую переменную внутри приложения? Или может еще где-то. Или может какой-то другой метод хранения данных о пользователях есть? Буду очень благодарна за советы. Спасибо

@Элд Хасп · 29.01.2022, 20:17

Сообщение от wizard41

В обоих ситуациях, конечно же, коллекцию сущностей можно (нужно) держать в самом приложении.

Это естественно.
Вне приложения любые библы - это просто код.
Сущности могут генерироваться только приложением в рунтайме.
Другой вопрос - это зависимости между разными объектами (в том числе сущностями) в приложении.
Здесь уже требуется более чёткая терминология, так просто "Приложение" - это по сути любой код используемый приложением.

@Wolfdp · 30.01.2022, 07:51

Сообщение от Элд Хасп

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

Не соглашусь. Зависит от реализации вызываемых сервисов.

C#
1
2
3
4
5
6
7
private aysnc void Login_Click(object sender, EventArgs args)
{
loginButton.Enabled = false;
var user = await  userService.LoadAsync(name, password);
if(user == null)
...
}

@wizard41 · 30.01.2022, 09:37

Сообщение от Элд Хасп

так просто "Приложение" - это по сути любой код используемый приложением

В данном контексте под "Приложением" имеется в виду приложение, использующее библиотеку, т.е. типа клиент.

Сообщение от Элд Хасп

Сущности могут генерироваться только приложением в рунтайме.

Ну.. как генерироваться.. Если приложение само источник некоторых данных, которые обрабатываются и хранятся "где-то там", то да.
Вообще, я считаю, что обе концепции имеют право на существование.
Пример номер раз:
В приложении (WF) пользователь создал класс User примерно такого содержания:

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
        class User
        {
            public string Name { get; set; }
            public string Password { get; set; }
            public string UserType { get; set; }
 
            public User( string name, string pass, string type )
            {
                Name = name;
                Password = pass;
                UserType = type;
            }
        }

И, допустим, библиотека (далее по тексту - сервис), принимает объект этого класса в качестве аргумента для регистрации нового пользователя. Далее WF делает так:

C#
1
2
User user = new User( "bob", "qwuy7632uhew", "User" );
Service.CreateUser( user );

Все нормально, пользователя bob зарегистрировали. А дальше что? А дальше ничего - больше этот объект User уже не нужен.
Теперь, по запросу WF сервис ему возвращает пользователей в виде списка объектов... (!) User? Нет. Иначе придется вставлять затычку в поле Password, ведь ни хеши ни тем более пароли пользователей сервис НЕ возвращает!
Т.е. нужен уже "другой" класс User, с двумя полями Name и Type.

Пример номер два:
Некий разработчик пишет форточку для управления пользователями. Я пишу ядро, которое вобщем-то ими и управляет, авторизует, пишет в файл или в БД и т.п.
Я не вижу ни форточки ни того разработчика, но мы условились, что, при авторизации я принимаю в метод только string name и string password. А при запросе возвращаю массив пользователей в виде объектов класса User с двумя полями: Имя и Роль. И мне на самом деле не важно какие там сущности плодит разработчик в своей программе, как он будет использовать возвращенный мной массив пользователей - суть одна: он так или иначе должен будет привести свои сущности к тому виду, который указал я (ну, или о которых мы договорились изначально).
Для этого, как минимум, его приложение должно понять то, что я ему верну, и для этого я предоставил ему открытый класс User.
А если тех разрабов будет штук 10 и у каждого свое видение ситуации? Да, можно сделать кучу перегрузок для каждого из них, но так или иначе все будет ограничено некоторыми рамками, в которые можно упереться и дальше ни как..

Ну и потом, кто мне запрещает диктовать свои условия, как разработчику "сервиса". Напомню - обособленного сервиса, а не в составе всего остального.

Добавлено через 8 минут
P.S. чуть не дописал..
Да, возвращенный массив пользователей, конечно же, может иметь право на существование в приложении VM (WF), но вот куча объектов User с именами и паролями там явно лишняя. Они просто не нужны.
При входе, вводится имя и пароль - все, дальше пароль "затирается".

Это к вопросу limeniye о том, зачем я инкапсулировал пользователей в библиотеку. Да из базы достал или из файла, и храню их, пока кто-то не войдет в систему и не попросит их.
Или в этом подходе снова что-то не так?

@limeniye · 30.01.2022, 13:16

wizard41, нееет. Вы путаете. Есть User, а есть его данные для авторизации. У User'а нет свойства Password.

@wizard41 · 30.01.2022, 14:16

Сообщение от limeniye

Есть User, а есть его данные для авторизации. У User'а нет свойства Password.

Как вариант. LoginData?

@limeniye · 30.01.2022, 14:30

wizard41, очень даже хороший вариант!

@wizard41 · 30.01.2022, 14:54

Ну логично.
Тогда создание и авторизация превращаются в

C#
1
2
Service.CreateUser( User, LoginData );
Service.LogIn( LoginData );

И если уж на то пошло, то создавать нужно только обычных пользователей. А модерами и админами их можно только потом назначать. Ну, если по правде.

@limeniye · 30.01.2022, 15:26

wizard41, да нет, сделайте просто enum доступа и передайте в LoginData, если по простому.

@Элд Хасп · 30.01.2022, 15:34

Сообщение от Wolfdp

Не соглашусь. Зависит от реализации вызываемых сервисов.

Это реализация должна быть ещё и логична с человеческой точки зрения.
Вот вы набрали в форме авторизации логин и пароль.
Нажали "вход".

При переходе к следующей странице, какие ещё действия в GUI должны выполняться?
Очевидно же что эти действия зависят от результата авторизации и, до получения этого результата, GUI должен быть заморожен.
То есть диалог авторизации должен быть модальным.

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

Добавлено через 4 минуты

Сообщение от wizard41

В данном контексте под "Приложением" имеется в виду приложение, использующее библиотеку, т.е. типа клиент.

Сообщение от wizard41

Ну.. как генерироваться.. Если приложение само источник некоторых данных, которые обрабатываются и хранятся "где-то там", то да.

В данном случае мы явно под приложением понимаем разные вещи.
И без уточнения терминологии дальнейшая дискуссия - это тупиковый путь.

приложение, использующее библиотеку - вообще, даже смысла этого не понимаю.
Что это означает?
Вот у вас есть Решение, в нем проект WPF View, WPF App, VM Core, подключенные пакеты и зависимости м пр.
Что из этого вы считаете Приложением, а что библиотекой?

Добавлено через 2 минуты

Сообщение от wizard41

Пример номер раз:
В приложении (WF) пользователь создал класс User примерно такого содержания:

Это мутабельный DTO или простая сущность - зависит от того для чего будет использован.
Мо феншую может использоваться только для разовой передачи данных между слоями или быть инкапсулированной сущностью внутри слоя.

@wizard41 · 30.01.2022, 15:39

Элд Хасп, ну не придирайтесь ) Я думаю вы меня прекрасно поняли. "Приложение" - это то, чего у меня нет. А библиотека - то что есть. Я понимаю что все это в куче тоже приложение. Ну назвал я клиентское окно приложением - разве это не так? Если угодно - приложение это *.exe , а библиотека *.dll

@Элд Хасп · 30.01.2022, 15:43

Сообщение от wizard41

Все нормально, пользователя bob зарегистрировали. А дальше что? А дальше ничего - больше этот объект User уже не нужен.
Теперь, по запросу WF сервис ему возвращает пользователей в виде списка объектов... (!) User? Нет.

Первое - да.
А второе, то есть вывод - не верно.

Так как User мутабельный, то сохранять ссылку на него в сервисе бессмысленно (чревато багами).
Но вполне можно клонировать (отразить) экземпляр и хранить его клон.
А перед возвратом списка передавать не внутренний список, а его отражение (глубокую копию).

Получится, что у вас один и тот же класс выступает при обмене данными как DTO, а при хранении данных в сервисе, как сущность.

Но так обычно не делают, так как при таком использовании большая вероятность путаницы и, как следствие, ошибок и багов.
Поэтому типы для DTO и Сущностей лучше именовать по разному.

Добавлено через 2 минуты

Сообщение от wizard41

ну не придирайтесь )

Я не придираюсь.
Просто мы зашли в такую область, где важно точно взаимопонимание.
Иначе можно полсотни просто написать и в конце выяснить, что просто по разному трактуем одинаковой термин.
Или наоборот одинаковое называем по разному.

@wizard41 · 30.01.2022, 15:54

Сообщение от Элд Хасп

не внутренний список, а его отражение (глубокую копию).

В одном из вариантов я именно так и делал (cloneable). Но там у меня возникли трудности как раз с паролями, т.к. они проворачивались через механизм SHA еще раз и становились неверными.
Но в свете последних советов, логику можно и переорганизовать под отражение.

Добавлено через 8 минут

Сообщение от limeniye

сделайте просто enum доступа и передайте в LoginData

В моем понимании enum доступа это "Авторизован-Не авторизован", а LoginData это пара логин-пароль. Ну а User понятно - Имя, возраст, ... и черт знает что еще.

@Элд Хасп · 30.01.2022, 16:01

Сообщение от wizard41

Если угодно - приложение это *.exe , а библиотека *.dll

Ок.
Вот так гораздо более конкретно.
exe у нас (в WPF) ассоциируется с классом App и типами его уровня.
Вся WPF View, даже если явно не выделена в отдельный проект, логически всё равно относится к "библиотеке".

Здесь при разделении функционала важно определить какие сборки (библиотеки) дружественные, а какие нет.
Дружественные - это те которые могут "влазить" в логику друг друга.
На уровне Шарпа этому, примерно, соответствует модификатор доступа internal.

Как реализовать....
Общего ответа здесь не дашь.
Зависит от конкретной задачи, выбранной архитектуры, реализации.
В "классическом" MVVM считаются, что все слои между собой "не дружат".
А реализацию внутри слоёв MVVM не регламентирует.

Примерная структура WPF MVVM Решения:
Структура связей в WPF Решении
Структура WPF решения

Но в простых задачах это всё упрощают.
Наприме очень часто реализуют Модель так, чтобы её можно было использовать сразу и как VM.

Добавлено через 4 минуты

Сообщение от wizard41

В одном из вариантов я именно так и делал (cloneable). Но там у меня возникли трудности как раз с паролями, т.к. они проворачивались через механизм SHA еще раз и становились неверными.

Вообще, я уже писал ранее (и не только в этой теме как отметил limeniye), если брать именно задачу реализации авторизации в которой нужно передать логин и пароль, то не нужно делать дополнительных объектов для хранения пароля.
Желательно это должен быть одноразовый уничтожаемый объект.
Сформировали его в View, передали по цепочке ссылку на него до авторизации.
Успешна или нет авторизация, в любом случае объект пароля должен быть уничтожен.
Хранить его поле попытки авторизации - бесмыслица.

Добавлено через 1 минуту
Поэтому, именно для авторизации лучше передать отдельно два стринга.
Или для пароля даже использовать char[], который после авторизации будет затираться.

@wizard41 · 30.01.2022, 16:05

Сообщение от Элд Хасп

Примерная структура WPF MVVM Решения:

Да, в одно время я хорошо подсел на WPF и MVVM, хотя последнее давалось не легко. Жаль что на реальной практике не встретилось конкретных задач именно на WPF. Мои работодатели до сих пор предпочитают WF, и что того хуже - net FW 4.х. Им даже Core не подсунешь.
В данном случае у ТСа формы и в случае чего код придется брать тоже с форм.

Добавлено через 1 минуту

Сообщение от Элд Хасп

Желательно это должен быть одноразовый уничтожаемый объект.

Сообщение от Элд Хасп

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

Вот что я хотел услышать!

@Элд Хасп · 30.01.2022, 16:06

Сообщение от wizard41

Мои работодатели до сих пор предпочитают WF

Там же всё равно нужно реализовывать MVC или MVP.
Или вы "по старинке" - "бурелом черт пойми чего"?

@limeniye · 30.01.2022, 16:06

Под enum я подразумевал следующее

C#
1
2
3
4
5
6
7
8
public enum UserAccess
{
    Uknown,
    Simple,
    Admin,
    Support,
    Moderator
}

При регистрации указывается какой у человека уровень доступа.

@Элд Хасп · 30.01.2022, 16:08

wizard41, кстати, в WF тоже есть привязки и на нём тоже можете без проблем (условно) реализовать MVVM.

Добавлено через 30 секунд

Сообщение от limeniye

При регистрации указывается какой у человека уровень доступа.

Часто это называю Ролями.

@limeniye · 30.01.2022, 16:08

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

Согласен с Элд Хасп. Но. Тут в логике понапутно где авторизация, где регистрация, а где просто User.

@wizard41 · 30.01.2022, 16:09

Сообщение от Элд Хасп

"бурелом черт пойми чего"?

По разному. Я в основном пишу мелкие модули, конвертеры, математику... А склеивают воедино другие ребята.
Но есть и свои пара проектов почти MVC. Старался, во всяком случае.

Сообщение от limeniye

Под enum я подразумевал следующее

Так так так... Понял.

@Элд Хасп · 30.01.2022, 16:12

Сообщение от wizard41

Вот что я хотел услышать!

Так это когда вам уже написали:

Сообщение от limeniye

Вообще, как-то Элд Хасп мне говорил, что если создаётся пользователь, например, то правильно было бы передавать его не как объект в параметр метода, а каждое его свойство в параметры метода

Добавлено через 2 минуты
wizard41, требования по безопасности какие?
Имею ввиду для пароля.
Надо просто его скрыть в GUI или обеспечить безопасную передачу с шифрованием?

Новые блоги и статьи Все статьи Все блоги /
Baragoz - DPS/HPS бот для WoW 3.3.5a, многоязычный AmbA 26.10.2026 Хотите ещё ботов? У меня есть один! А я пока отдохну от него. https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=12062&stc=1&d=1793007952 Инструкция внутри. Сразу отвечу: А в PvP с ним. . .	Особенности gif сгенерированных в Си russiannick 21.10.2026 Рассмотрим генерацию gif файлов, которые в Си имеют свои особенности. Gif представляет собой графический формат популярный в интернете. Посмотрим на палитру. Gif файл сгенерированный в си отличается. . .	FPS контроллер с анимированными Y-Bot и 3D-звуком miniaudio (Box3D, Recast, BehaviorTree.CPP, ozz-animation, ImGui, OpenGL и SDL3) 8Observer8 18.10.2026 Содержание блога \| English Version Полное мультиплатформенное руководство по стартовому проекту с FPS-контроллером игрока, анимированными роботами Y-Bot с 4-слойным блендингом, 3D-физикой Box3D,. . .	Локальный http сервер Argus19 17.10.2026 Локальный http сервер На работе, на двух локальных компьютерах круглосуточно работают программы опроса приборов с записью в книги Excel,которые раз в сутки записываются на сервер компании. Т. к. . . .
Копировать Windows на новый диск на UEFI damix 17.10.2026 https:/ / uriesk. wordpress. com/ 2016/ 11/ 01/ move-window-10-to-ssd-on-a-uefi-dualboot-system-with-basic-linux-tools/ TL DR Вставляем диск, а старый подключаем через переходник, грузимся с лайва. . .	ИИ не может найти нужный язык в списке Supersumestria 05.10.2026 Я ему даю вот такое изображение и прошу найти и подчеркнуть немецкий язык. Возвращает он вот это: https:/ / i. **********/ vqBWLe2. png Нужную строчку в 3й колонке просто выдумал. . Это. . .	Новая последняя моя музыка в SUNO zorxor 05.10.2026 Здравствуйте, дорогие мои друзья! С большой радостью я хотел бы представить вам свою новую последнею музыку, которую сгенерировала мне по моей просьбе нейросеть SUNO. С уважением, zorxor. Это. . .	Программный домашний кинотеатр russiannick 27.09.2026 Сподобился на программный домашний кинотеатр. В качестве ЯВУ по традиции выбрал js. В помощники взял Яндекс-Алису. Было создано три зала на разные интересы. исторические и ретро сериал Хичкок. . .

@Kyra90 232 / 153 / 85 Регистрация: 06.10.2020 Сообщений: 468

	Хранить строку в приложении 14.01.2022, 12:58. Показов 11153. Ответов 209 Метки нет (Все метки) Всем привет. Помогите, пожалуйста с курсовой. Значит задача: Создать приложение с пользовательским доступом (логин/пароль, пользователь может быть пользователем, может быть админом). Значит я делаю следующим образом: В программу уже вшит пользователь "Администратор", при первом запуске предлагается создать ему пароль. Как только пароль создан рядом с приложением создается папка "Users" (по ее наличию, собственно, и проверяется первый запуск), где в файлах в зашифрованном виде хранится информация о пользователе. Препод говорит, что это не совсем правильное решение, и файла с данными "Администратор" в папке с пользователями быть не должно, так как (цитирую дословно) "Я скопирую пользователей в другое место, прибью папку Users, запущу программу и получу доступ к Администратору, снова введя пароль, потом верну пользователей назад" Можно ли как то хранить строковую переменную внутри приложения? Или может еще где-то. Или может какой-то другой метод хранения данных о пользователях есть? Буду очень благодарна за советы. Спасибо 0

@limeniye 1182 / 624 / 160 Регистрация: 19.04.2018 Сообщений: 2,923
	30.01.2022, 13:16
	wizard41, нееет. Вы путаете. Есть User, а есть его данные для авторизации. У User'а нет свойства Password. 1

@limeniye 1182 / 624 / 160 Регистрация: 19.04.2018 Сообщений: 2,923
	30.01.2022, 14:30
	wizard41, очень даже хороший вариант! 0

@limeniye 1182 / 624 / 160 Регистрация: 19.04.2018 Сообщений: 2,923
	30.01.2022, 15:26
	wizard41, да нет, сделайте просто enum доступа и передайте в LoginData, если по простому. 0

@wizard41 3465 / 2785 / 576 Регистрация: 04.09.2018 Сообщений: 8,758 Записей в блоге: 3
	30.01.2022, 15:39
	Элд Хасп, ну не придирайтесь ) Я думаю вы меня прекрасно поняли. "Приложение" - это то, чего у меня нет. А библиотека - то что есть. Я понимаю что все это в куче тоже приложение. Ну назвал я клиентское окно приложением - разве это не так? Если угодно - приложение это .exe , а библиотека .dll 0