Так роутер есть Archer MR600, но в регионе проживания оказалась перегружена сотовая вышка и в тех.поддержке предложили роутер перенести в другую часть дома, чтобы он на другую вышку переключился.
Но вот таскать оборудование, что через LAN подрублено возможности нет.
IseeCollapse, Не совсем понимаю где вы закопались. )) Но что мешает сделать public event который будет дергаться при нажатии на кнопку внутри вашего UserControl. И к нему уже привязать делегат там где будет использоваться ваш контрол.
rPman, async/await не делает переключения контекста потока.
И все замыкаемые переменные сохраняются в обьект State Machine, который создается в куче, а не на стеке.
rPman "Когда компилятор видит async он сохраняет состояние (стек) и передает выполнение к очереди для других кусков кода (помеченный async)"
Не делается это, async это директива для компилятора, чтобы из функции сделать State Machine
enchikiben, Тогда лучше класс поиска с методом BeginStart и event свойством OnComplete. Только нужно создать SynchronizationContext чтобы event отдавался только через него. Также вместо Thread можно использовать task через Run.
Передаете единый CancallationToken и передаете его в serialPort.BaseStream.ReadAsync(...)
Первый обнаруживший token.cancel(), но нужно перехватывать OperationCancelledException
У вас мало информации предоставлено. Какой тип приложения WinForm, WPF, консольное или сервис, от этого зависит как сообщить об найденом порту.
Используйте обьекты синхронизации, чтобы при обнаружении нужного другие потоки сразу завершали работу.
public class User
{
static public int Id;
static public string Name;
static public string Login;
static public string Password;
}
Form2_Load и button1_Click -- Не соответствует code style
Form1.user.Id = textBox1.Text; -- доступ не к членам класса.
Возьмите себе ментора и он все обьяснит очень подробно.
https://jwt.io/introduction "И как я понимаю, время жизни 6 значного кода будет ровняться жизни токена?" вы можете задать любое ValidUntil поле БД, где сохраняете отосланный код.
Heggi, "JWT может содержать что угодно, лишь бы не дергать сервис авторизации лишний раз (зачем его дергать, если в токене будет всё? Минус одна зависимость в пайлайне обработки запроса)"
Может. Но и GW может кешировать нужные данные по пользователю. Он может оперативно реагировать на состояние пользователя и оперативно блокировать токен или чать пользовательских пермишенов.
Поместив все в токен, вы увеличиваете сильно его размер и тем увеличивает лишний трафик, ведь большинство данных в токене может никогда и не пригодиться. Не можете оперативно прекратить время жизни токена.
"в токене хранятся эти данные или gateway на каждый запрос лазит в сервис авторизации" GW проводит валидацию токена и проверяет пользовательские пермишены. Зачем ему ваши группы и подразделения? Это все будет в сервисе.
" Как ограничить доступ к конкретной транзакции по принадлежности к группе и подразделению?" это уровень сервиса "Транзакций". Т.е. банальный фильтр.
EDA подразумевает, что описание групп, подразделений, правила на их CRUD будут в сервисе "Авторизаций", он источник правды по этим данным. А сервис "Транзакций" подписан на обновление состояний данных обьектов и просто обновляет минимальную копию этих данных, нужных для правильнй фильтрации ваших запросов. Для примера наменование группы/подразделений хранить не нужно если эти обьекты используются только для фильтрации и никогда не отдаются в GW
Heggi, JWT по факту должен содержать только UserID.
Gateway на себя берет валидацию токена, авторизацию пользователя и роутинг запросов к сервисам.
GW для админки будет иметь одни роутинги, для Dashboard другие.
Для запроса "Пользователь запрашивает транзакцию с id=7152522" GW проверяет имеет ли пользователь права на это действие и просто отправляет запрос в сервис "Транзакций" или "Поиска". Зависит от бизнес логики проекта (В GW нет БЛ).
"Если фильтрацию отдать на сторону Gateway, то получим не 30 записей"
GW не должен содержать бизнес логики, я тут выше описал для чего он.
"Следовательно сервис транзакций так или иначе должен обрабатывать содержимое JWT-токена или сходить в сервис авторизации и запросить что этому пользователю позволено." Сервис транзакций не должен знать об наличии сервиса "Авторизации". GW имеет прямой доступ к сервису Авторизации для получения "разрешений". А информация об группах и подразделениях приходит только через Message Broker.
Heggi, "Использование Gateway в качестве "объединятора" данных" - об этом не говорилось. Конечное разные запросы и никакой логики по обьединению в gateway нет.
"Проверять роли? Каждый сервис у нас и так проверяет роли". Gateway проверяет права доступа к данным. А сервис только отдает нужные данные в соответсвии с условиями, в том числе с условиями по доступу (группа, подразделение и т.д.). Еще gateway отсекает важные сервисы от внешнего мира, чтобы у вас не торчали сервисы наружу.
"Объединять несколько запросов в один? Смысл? Фронту проще сделать несколько запросов. Про обогащение уже писал."
Об этом не говорилось. Каждый сервис выполняет свои запросы, никаких обьединений данных от разных сервисов gateway не делает. Если нужны обьединения, то это доп.сервис "Поисковый", который содержит нужные копии данных.
Но вот таскать оборудование, что через LAN подрублено возможности нет.