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

Вроде все просто — вошли, загрузили данные, отображаем.

При выходе — просто удаляем данные и все тут.

Но дьявол как всегда в деталях...

Во-первых, если пользователь не нажимал явно "выйти" но по каким-либо причинам доступ данным не возможен (пользователь изменил пароль или удалил приложение из доверенных) — данные удалять не стоит, но при этом нужно перейти на страницу повторного входа. Данные же нужно сохранить, т.к. скорее всего пользователь просто перезайдет.

И тут сразу нюансы... Если мы данные не удаляем — то пользователь ведь может зайти под другим аккаунтом. Уже сразу нужно сравнить его данные или новый пользователь.

Далее...

При выходе нужно отписаться от оповещений как минимум. Иначе оповещение придет а пользователь не вошел. Глупо.

Еще далее. Фоновые задачи. Пользователь мог выйти, но при этом фоновую задачу вы не остановили. Данные удалили — а фоновая задача об этом не знает, т.к. исполняется в отдельном изоляте — она подумает что ничего не изменилось и сохранит некие новые данные для текущего пользователя. Значит обязательно остановить все фоновые задачи, дождаться остановки — и уже тогда удалять.

Но и еще. Остановили фоновые задачи — а если это не фоновая а запрос пользователя, который выполнялся дольше обычного? При этом он удалил базу, потом пришел ответ на запрос. Ну ок, можно блокировать запись в базу. Но! А что если вы создали новую базу (сняли блокировку) — и тут приходит старый ответ на запрос? Опаньки...

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

Казалось бы мелочь — но на практике как всегда множество нюансов...

Здравствуйте, Shmj, Вы писали:

S>Еще далее. Фоновые задачи. Пользователь мог выйти, но при этом фоновую задачу вы не остановили. Данные удалили — а фоновая задача об этом не знает, т.к. исполняется в отдельном изоляте — она подумает что ничего не изменилось и сохранит некие новые данные для текущего пользователя. Значит обязательно остановить все фоновые задачи, дождаться остановки — и уже тогда удалять.

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

Здравствуйте, Shmj, Вы писали:

S>Допустим есть программа, в которой может быть залогинен только один пользователь, т.е. нет переключения между аккаунтами — только Вася или Петя, .

Пользователей больше одного? Это — многопользовательское приложение.

S>но не оба одновременно

А это — малозначимая деталь реализации.

Все проблемы от жадности и глупости

Здравствуйте, Stanislaw K, Вы писали:

S>>Допустим есть программа, в которой может быть залогинен только один пользователь, т.е. нет переключения между аккаунтами — только Вася или Петя, .
SK>Пользователей больше одного? Это — многопользовательское приложение.

А что бывают приложения где 1 пользователь

S>>но не оба одновременно
SK>А это — малозначимая деталь реализации.

Но вроде как это позволяет иметь 1 базу, т.к. пользователь всегда один. Вышел — удалять.

Здравствуйте, Stanislaw K, Вы писали:

SK>Пользователей больше одного? Это — многопользовательское приложение.

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

Здравствуйте, Shmj, Вы писали:

S>>>Допустим есть программа, в которой может быть залогинен только один пользователь, т.е. нет переключения между аккаунтами — только Вася или Петя, .
SK>>Пользователей больше одного? Это — многопользовательское приложение.

S>А что бывают приложения где 1 пользователь

Word, FAR, калькулятор.. Много их.

S>>>но не оба одновременно
SK>>А это — малозначимая деталь реализации.
S>Но вроде как это позволяет иметь 1 базу, т.к. пользователь всегда один. Вышел — удалять.

чиво?

Все проблемы от жадности и глупости

Здравствуйте, Stanislaw K, Вы писали:

S>>Но вроде как это позволяет иметь 1 базу, т.к. пользователь всегда один. Вышел — удалять.
SK>чиво?

Ну что чиво? Одна база — типа user. И там все данные. Пользователь нажал выход из программы — удаляем эту базу данных.

Здравствуйте, Shmj, Вы писали:


S>>>Но вроде как это позволяет иметь 1 базу, т.к. пользователь всегда один. Вышел — удалять.
SK>>чиво?

S>Ну что чиво? Одна база — типа user. И там все данные. Пользователь нажал выход из программы — удаляем эту базу данных.

Это у тебя дизайн, архитектура приложения, изначально неверно спроектирована. Junior style.

Все проблемы от жадности и глупости

Здравствуйте, Stanislaw K, Вы писали:

S>>Ну что чиво? Одна база — типа user. И там все данные. Пользователь нажал выход из программы — удаляем эту базу данных.
SK>Это у тебя дизайн, архитектура приложения, изначально неверно спроектирована. Junior style.

А раскрыть сможете? Ведь если достаточно одной базы — то зачем усложнять?

Здравствуйте, Shmj, Вы писали:

S>>>Ну что чиво? Одна база — типа user. И там все данные. Пользователь нажал выход из программы — удаляем эту базу данных.
SK>>Это у тебя дизайн, архитектура приложения, изначально неверно спроектирована. Junior style.

S>А раскрыть сможете? Ведь если достаточно одной базы — то зачем усложнять?

Ты заранее знаешь что пользователей у тебя 1+N, значит и проектировать нужно с учетом этого.

даже в zx sinclair уже были многопользовательские приложения с одной базой. 40+ лет назад. сейчас то что случилось?

Все проблемы от жадности и глупости

Здравствуйте, Shmj, Вы писали:

S>Допустим есть программа, в которой может быть залогинен только один пользователь, т.е. нет переключения между аккаунтами — только Вася или Петя, но не оба одновременно.

S>Вроде все просто — вошли, загрузили данные, отображаем.

S>При выходе — просто удаляем данные и все тут.

S>Но дьявол как всегда в деталях...

Задача-то в чём заключается? Не дать двум разным людям пользоваться одной программой?

Сделай кнопку "Программу уже использует пользователь Вася. В случае продолжения, его данные будут стёрты. Продолжать?"

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

Здравствуйте, Pzz, Вы писали:

Pzz>Задача-то в чём заключается? Не дать двум разным людям пользоваться одной программой?

Сделать корректный выход.

Pzz>Сделай кнопку "Программу уже использует пользователь Вася. В случае продолжения, его данные будут стёрты. Продолжать?"

Я описал проблемы в стартовом сообщении.

Если сервер сообщил что данные аутентификации устарели/были отозваны — удалять ли локальный хеш? Может быть пользователь перезайдет под тем же ID, а может под другим.

Далее. Вот есть некая операция, она выполняется. Пока не завершила выполнение — пользователь вышел и зашел под другим. Операция завершила выполнение и готова записать результат в базу. Но база уже — другого пользователя. Что делать? Разные базы для каждого пользователя, не смотря на то что возможен только один в одно время? И все-равно — та то база уже удалена — чего ее тревожить? Или каждый раз после завершения любой операции проверять что пользователь не изменился?

Здравствуйте, Stanislaw K, Вы писали:

SK>Ты заранее знаешь что пользователей у тебя 1+N, значит и проектировать нужно с учетом этого.

А вот, кстати, если некая операция выполняется достаточно долго — за это время пользователь успел выйти из одного аккаунта и войти в другой — как быть в таком случае? Операция выполнилась, готова писать результат в базу — но только база теперь принадлежит другому пользователю и данные не его. Как это решить лучше? Держать постоянно локальный контекст операции — к какому пользователю она прикреплена?

Здравствуйте, Shmj, Вы писали:

SK>>Ты заранее знаешь что пользователей у тебя 1+N, значит и проектировать нужно с учетом этого.

S>А вот, кстати, если некая операция выполняется достаточно долго — за это время пользователь успел выйти из одного аккаунта и войти в другой — как быть в таком случае?

Не разрешать выходить. При выходе прерывать все операции. kill -9 ALL будет идеально.

S>Операция выполнилась, готова писать результат в базу — но только база теперь принадлежит другому пользователю и данные не его.

мем=я испытываю языковой барьер.jpg

как процесс продолжается при выходе из программы? это клиент-серверное приложение? почему тогда у пользователей одна единственная консоль? почему тогда у пользователей одна единственная "база"? почему тогда "база" все время удаляется? если "база" — кэш, временные файлы, сделай каждому пользователю свою "базу". %tmp%/md5(username+salt).sql

мем=недостаточно данных.jpg

Ты пытаешься буквально дословно выполнить кривое излишне детальное техническое задание?

Все проблемы от жадности и глупости

Здравствуйте, Stanislaw K, Вы писали:

SK>Не разрешать выходить. При выходе прерывать все операции. kill -9 ALL будет идеально.

Но выход из аккаунта — не подразумевает закрытие программы.

SK>как процесс продолжается при выходе из программы? это клиент-серверное приложение? почему тогда у пользователей одна единственная консоль? почему тогда у пользователей одна единственная "база"? почему тогда "база" все время удаляется? если "база" — кэш, временные файлы, сделай каждому пользователю свою "базу". %tmp%/md5(username+salt).sql

Ну ОК, пусть будет разная база. Но как по завершению операции программа узнает в какую базу писать? Она то будет писать в текущую открытую базу.

SK>мем=недостаточно данных.jpg
SK>Ты пытаешься буквально дословно выполнить кривое излишне детальное техническое задание?

Я думаю на ходу как решить проблему, детального Т.З. нет, конечно же.

Здравствуйте, Shmj, Вы писали:
S>Ну ОК, пусть будет разная база. Но как по завершению операции программа узнает в какую базу писать? Она то будет писать в текущую открытую базу.
Почему нельзя в контекст операции при её старте записать ID или путь к базе, в которую нужно положить результат?

S>Я думаю на ходу как решить проблему, детального Т.З. нет, конечно же.
Проблема тут явно в постановке задачи.

Здравствуйте, Sinclair, Вы писали:

S>>Ну ОК, пусть будет разная база. Но как по завершению операции программа узнает в какую базу писать? Она то будет писать в текущую открытую базу.
S>Почему нельзя в контекст операции при её старте записать ID или путь к базе, в которую нужно положить результат?

Вот тоже к такому же решению пришел — но хотел чтобы кто-то подтвердил.

После подключения устанавливать ID-сессии приложения (главное не путать с сессией пользователя — которая связана с сервером). И после каждой длительной операции прежде чем писать в базу — сравнивать ID глобальной сессии приложения и локальный ID, который сохранили на момент начала запроса.

S>>Я думаю на ходу как решить проблему, детального Т.З. нет, конечно же.
S>Проблема тут явно в постановке задачи.

У меня такого нет — никогда четкие задачи не ставили — нужно ко всему самому приходить.

Причем вот какая фишка. Текущее приложение — клон. Т.е. оно уже в таком же практически виде есть и работает. Но Т.З. нет. Код старого есть (на другом ЯП) — но в коде чужом ковыряться — чаще всего проще свое накатать.

Почему нет Т.З. после написания? Потому что работа не вполне устраивает и вдруг в процессе родится лучшее решение. Вот какова реальная жизнь.

Здравствуйте, Shmj, Вы писали:

S>Казалось бы мелочь — но на практике как всегда множество нюансов...

Кстати доблестная команда MSAL недавно этой несуществующей проблемой озадачилась и выкатила в V4 идиотское решение
Все данные пользователя шифруются сессионным ключом (который генерируется когда открываешь сайт или запускаешь программу)