Server-side Blazor, аутентификация/авторизация

@kotelok · Регистрация: 08.08.2014

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

Задайте, пожалуйста, хотя бы общие направления (может подробные мануалы есть?). По туториалам и по стандартным шаблонам Студии да, можно сделать, чтобы работало. Можно то же самое прочитать в документации и сделать по шагам. Но совершенно не понятно, как оно внутри устроено.

Для самостоятельного фронтэнд-приложения, код которого выполняется в браузере, всё понятно. Приложение тем или иным образом (через прямое обращение к методу API, через редирект на страницу IS4, и т.п.) по логину/паролю получает токен доступа (и, возможно, рефреш-токен), сохраняет его где-то у себя в памяти (или в куках, если требуется) и далее, при обращении к методам API включает токен в HTTP-заголовок. На стороне сервера, где живёт API, токен проверяется согласно каким-то правилам и далее даётся/запрещается доступ к указанному API-методу.

А как оно происходит в случае с server-side? И какие варианты реализации вообще есть?

И общая архитектура и логика в этом случае какая?
1. В браузере только вспомогательный JS, который создаётся и поддерживается без участия программиста и который прозрачно для разработчика взаимодействует с логикой фронтэнда на сервере через SignalR.
2. На сервере, где фронтэнд-логика находится, для каждого подключенного пользователя автоматически создаётся своя сессия (и поддерживается соединение), в рамках которой и нужно хранить полученные токены? Т.е. пользователь запросил страницу, сервер проверил в его сессии наличие валидного токена, если нет, то редиректнул на страницу аутентификации (в самом простом случае на свою же, или модальное окно показал), там пользователь ввёл логин/пароль, нажал "вход", на сервере (в сессии данного клиента) по кнопке "вход" отработал код проверки логина пароля по базе (или, скажем, через прямое обращение к IS4 по Resource Owner Password Flow), был получен токен, который сохранился в сессию пользователя. Далее этот токен используется для обращений к API, для получения от API набора прав пользователя, для кастомизации интерфейса в зависимости от уровня доступа, который вернул API. При этом API может быть как какой-нибудь внешний, с доступом по HTTP, так и виде зависимой сборки, сервисы которой доступны через DI.

@Usaga · 26.06.2019, 12:35

kotelok, насколько я понял, авторизацию прикрутили в Preview6. Добавили некие компоненты-обёртки, которые пробрасывают информацию о пользователе, где и можно узнать авторизован пользователь, али нет. Авторизация, судя по всему (предположение), происходит перед установкой соединения по SignalR (или соединение переустанавливается после авторизации классическим образом) и токен (или что там) первым делом отсылается на сервер и просто держится в ОЗУ.

Вопрос интересный, я бы тоже его поисследовал как время появится.

Официально доступная информация по этой теме в release notes

@sau · 26.06.2019, 13:28

https://github.com/aspnet/AspN... s/src/Auth
- аутентификация в блазор.

- на сколько я понял , нужно писать наследника для AuthenticationStateProvider.cs и реализовать свою логику авторизации.
В приложениях Blazor на стороне сервера реализация AuthenticationStateProvider может брать данные пользователя из Http контекста (которые сами же и передаем в запросе),
В клиентских приложениях Blazor (те , что выполняются в контексте WebAssembly) реализация AuthenticationStateProvider может обращаться к какому либо апи сервису или хранить данные в хранилищах браузера - свобода реализации в общем.
В плане визуализации , они сделали вью.компоненту , которая анализирует результат работы нашей реализации AuthenticationStateProvider и решает какой контент показывать или нет (привет веб.формы LoginView)

@kotelok · 26.06.2019, 19:41 **[ТС]**

Как-то очень тяжеловесно получается на предлагаемых MS решениях.

Если делать на базе 'ASP.NET Core Identity' (дефолтный шаблон из preview-6), то он по умолчанию привязывается к EF-контексту и требует базу специфичной структуры для хранения пользователей. А у меня древняя легаси-база со своими таблицами безопасности и лепить рядом ещё одну, и как-то поддерживать синхронизацию пользователей с ней совершенно не хочется.

Если от EF отказаться, но оставить тот же сценарий с Identity, то приходится реализовывать громоздкую кучку интерфейсов (хранилище пользователей, хранилище ролей, класс уравления пользователями и т.п.).

Вероятно, можно отказаться от 'Identity' и реализовать свой кастомный мидлвар (со своей страничкой) для аутентификации с последующей инициализацией 'User.Identity' в текущем HTTP-контексте из которого потом данные будут извлекаться для отрисовки верхней плашки и для реализации 'AuthenticationStateProvider' (через который будут корректно работать встроенные механизмы авторизации компонентов Blazor). Но тут я пока совершенно не понимаю, как это правильно и безопасно реализовывать.

Дефолтная реализация по кнопке логина редиректится на отдельную статик-страницу (отдельным HTTP-запросом), после успешного логина устанавливает/обновляет две какие-то куки (одна для AspIdentity, вторая для antiforgery), после чего редиректит обратно на приложение, которое заново подключается к серверу уже с правильными куками, после чего устанавливает коннект SignalR и больше HTTP-запросов не шлёт. Но по кнопке 'Logout' кука 'Identity' почему-то не обновляется и не удаляется, только модифицируется кука antiforgery.
Так же не понятно, как заставить браузерную сторону при установлении соединения отправлять какую-то кастомную куку на сервер.

@yurickas · 26.06.2019, 20:06

1. Выбираешь ASP.Core Host. Получаешь 2 проекта: клиент и сервер
2. Прикручиваешь туда jwt

Вот сейчас пытаюсь сие забабахать, ибо то что работало в Core 2.2 напрочь отказывается в 3.0

И кстати, Identity к авторизации вообще-то никаким боком, если есть своя база с пользователями - используй ее.

@kotelok · 26.06.2019, 20:12 **[ТС]**

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

Выбираешь ASP.Core Host

Так это же client-side будет, а я про server-side спрашиваю.

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

используй ее

Я, собственно, так и хотел, но пока вот только пытаюсь разобраться как для server-side это вообще реализовать, и как реализовать правильно с точки зрения безопасности.

@kotelok · 27.06.2019, 08:44 **[ТС]**

Ещё вопрос общего характера - как самому себе обосновать выбор в пользу server/client-side Blazor? Проект - небольшая внутренняя система учёта на пару сотен пользователей (и локальные, и через инет). Требование пользовательского уровня - отзывчивый интерфейс (без рефрешей всего при каждом клике), вероятно, встроенный чатик, плюс различные уведомления пользователей о событиях сервера.

Раньше выбор был очевиден - приложение в браузере и API на сервере.

Но теперь server-side-версия, с точки зрения поведения UI, вообще ничем не отличается от client-side. Более того, при тестах в рамках одной машины (т.е. без влияния пинга) у меня вообще получается, что server-side работает более отзывчиво, и это заметно даже просто на глаз. Т.е. одно и то же базовое приложение из стандартного шаблона:
1. При начальной загрузке: client-side - несколько секунд, server-side - мгновенно.
2. При переходе на страницу, где запрашиваются данные для отображения в таблице: client-side - видна пауза перед отображением (при каждом переходе), server-side - мгновенно. Здесь, очевидно, сказываются накладные расходы client-side, которому надо - установить коннект на API-сервер, сформировать/отправить HTTP-запрос, на сервере разобрать HTTP-запрос, сериализовать данные в JSON, на клиенте десериализовать полученные данные и подготовить для отображения. А для server-side всё проще - соединение (SignalR) уже установлено и поддерживается, сериализовывать/десериализовывать данные в JSON не нужно. Однако, это самый простой сценарий, вероятно, в каких-то случаях картина будет иная.

Из минусов client-side:
1. На данный момент не известно когда оно вообще в релиз уйдёт и в каком виде.
2. Ограничено 'netstandard' (но тут я не могу оценить, насколько это вообще имеет значение).
3. Лишний код для общения с API (даже если автогенерируемый, даже если расшарить DTO).

Из возможных минусов server-side:
1. Не известно, как оно будет держать коннект в условиях плохого инета (большой пинг, потери пакетов). И не только держать коннет, но и просто откликаться на действия пользователя.
2. Не могу оценить масштабы, но очевидно, что нагрузка на сервер будет выше, чем при client-side. Хотя, вероятно, в условиях пары сотен вялых пользователей это вообще значения не имеет.
3. Пока не видится возможным реализовать красивую аутентификацию без перезагрузки приложения при login/logout.

@Usaga · 27.06.2019, 10:04

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

Из минусов client-side:

4. Требуется современный браузер. IE и всякие старенькие IPad'ы отсекаются. Важно это для вашего применения или нет решать вам, но забывать про это не стоит.

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

Из возможных минусов server-side:
1. Не известно, как оно будет держать коннект в условиях плохого инета (большой пинг, потери пакетов). И не только держать коннет, но и просто откликаться на действия пользователя.

Оно умеет переподключаться при обрыве связи. Трафик, вроде бы, не особо серьёзный (я на учебных примерах баловался).

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

2. Не могу оценить масштабы, но очевидно, что нагрузка на сервер будет выше, чем при client-side. Хотя, вероятно, в условиях пары сотен вялых пользователей это вообще значения не имеет.

Тут можно самостоятельно попробовать оценить понаоткрывав пару десяток вкладок и посмотрев разницу в потреблении памяти между одним пользователем и двумя десятками. Дальше уже прикидывать можно.

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

3. Пока не видится возможным реализовать красивую аутентификацию без перезагрузки приложения при login/logout.

Может к релизу доведут до ума. Авторизация только-только появилась.

Самое страшное, что я вижу в server side - это любители понаоткрывать вкладок и уйти на обед\домой. Какой-нибудь ВКонтакте я бы побоялся на этой технологии строить) А вот ИС... Если честно, то я бы попробовал. Очень уж интересная и перспективная технология. Везде C#, никаких тебе ангуляров и прочих jQuery.

Добавлено через 48 минут
kotelok, я думаю, что вы можете поизвести простой "краш-тест". Можно взять какую-нибудь базу (совершенно любую) и вытащить из неё справочник на сотню (больше, думаю, не стоит) значений. Список клиентов там из учебной базы Northwind или ещё чего. Лишь бы данных было достаточно, чтобы выглядело как настоящее. Потом в компоненте в список выгрузить (чтобы в памяти торчало) и отрендерить в виде таблицы. И прикрутить какую-нибудь кнопку, чтобы сортировать можно было записи (по одной колонке - больше не надо). И потыкать это дело. Сразу будет видно какой трафик идёт по WS.

И таких вкладок двадцать отркыть можно, чтобы потребление ОЗУ на сервере оценить.

Т.е. я предлагаю макет сделать, чтобы лично посмотреть на что server side способен.

Было бы классно, если бы вы такое провернули и результаты нам озвучили.

@kotelok · 27.06.2019, 12:14 **[ТС]**

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

Релизная сборка, селф-хост:
1. Стартовые 10 закладок: память с нуля выросла до 160МБ и там стабилизировалось.
2. Ещё +10 закладок (итого 20). Память сервера подросла до 164МБ.
3. Ещё +10 закладок (итого 30). Память сервера снизилась до 150МБ.
4. Ещё +10 закладок (итого 40). Память сервера попрыгала в разные стороны и упала до 92МБ.
5. Ещё +10 закладок (итого 50). Память сервера выросла до 150МБ.

В целом, память ведёт себя весьма странно, вероятно, это связано с работой сборщика мусора, который подчищает тысячи брошенных массивов 'WeatherForecast[]' по какой-то своей логике. Например (при открытых 50 закладках) в какой-то момент память упала до 102МБ и осталась на этом уровне минут на 10. Потом быстро выросла до 150МБ и тоже стабилизировалась. Потом плавный рост до 180МБ, очистка до 82МБ и снова плавный рост.

Потребление процессора на всех этапах:
1. Сервер (селф-хост-экзешник): 0-2%.
2. Хром-процессы с закладками: 0-1% (памяти каждый из них потребляет по 20-50МБ).

Генерация данных

C#
1
2
3
4
5
6
7
8
9
10
11
        public WeatherForecast[] GetForecast(DateTime startDate)
        {
            var rng = new Random();
 
            return Enumerable.Range(1, 100).Select(index => new WeatherForecast
            {
                Date = startDate.AddDays(index),
                TemperatureC = rng.Next(-20, 55),
                Summary = Summaries[rng.Next(Summaries.Length)]
            }).ToArray();
        }

Код страницы

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
WeatherForecast[] forecasts;
System.Timers.Timer timer = null;
 
 
protected override void OnInit()
{
    base.OnInit();
 
    timer = new Timer(982);
 
    timer.Elapsed += TimerTick;
    timer.AutoReset = false;
    timer.Start();
}
 
void TimerTick(object sender, ElapsedEventArgs e)
{
    forecasts = ForecastService.GetForecast(DateTime.Now);
    Invoke(() => { StateHasChanged(); });
    timer.Start();
}

Разметка

HTML5
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
    <table class="table">
        <thead>
            <tr>
                <th>Date</th>
                <th>Temp. (C)</th>
                <th>Temp. (F)</th>
                <th>Summary</th>
            </tr>
        </thead>
        <tbody>
            @foreach (var forecast in forecasts)
            {
                <tr>
                    <td>@forecast.Date.ToShortDateString()</td>
                    <td>@forecast.TemperatureC</td>
                    <td>@forecast.TemperatureF</td>
                    <td>@forecast.Summary</td>
                </tr>
            }
        </tbody>
    </table>

Добавлено через 4 минуты
А трафик я не нашёл как посмотреть. В Хроме на закладке 'Network' засвечивается 'wss://localhost:5001/_blazor?id=6uyGySTWUHRSn1kHcyBGDQ' в состоянии 'Pending', но никакой активности/статистики по нему не отображается.

@Usaga · 27.06.2019, 12:21

kotelok, память себя так ведёт из-за сборки мусора. Это нормально. В общем и целом, потребление ниочём.

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

А трафик я не нашёл как посмотреть. В Хроме на закладке 'Network' засвечивается 'wss://localhost:5001/_blazor?id=6uyGySTWUHRSn1kHcyBGDQ' в состоянии 'Pending', но никакой активности/статистики по нему не отображается.

Надо щёлкнуть на строку с wss и перейти на вкладку Messages. Там будет отражаться список пакетов, их содержимое и размер.

@kotelok · 27.06.2019, 12:29 **[ТС]**

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

Надо щёлкнуть на строку с wss и перейти на вкладку Messages

На каждое событие рефреша данных прилетает два 'binary frame' - один входящий на ~24 КБайт, второй исходящий на 28 байт. В обновляемой таблице 100 коротких строк (дата, число, число, строка 4-10 знаков). Содержимое пакетов через Хром посмотреть не получается.

@Usaga · 27.06.2019, 13:49

kotelok, ну, вполне себе нормально. Прилетают сами данные, плюс какой-то diff для DOM'а. Что-то среднее между чистым JSON и классическим серверным рендерингом.

@kotelok · 27.06.2019, 22:22 **[ТС]**

[1]
С кастомной аутентификацией разобрался. Но красиво не получается, только через редиректы.

Кратко суть:
1. По кнопке логина делается редирект на обычную статичную razor-страницу ввода логина/пароля (и прочего логин-функционала).
2. Там пользователь вводит логин/пароль и обычным POST-запросом выполняет аутентификацию, которая в ответ возвращает HTTP-куку, в которую сложены данные об аккаунте. Браузер сохраняет куку и при последующих коннектах включает её в соответствующий HTTP-заголовок.
3. После этого происходит обычный редирект обратно на Blazor-приложение. Приходит HTTP-коннект с полученной в п.2. кукой аутентификации, которая через дефолтный мидлвар аутентификации разбирается и раскладывается в объект 'HttpContext.User' текущей сессии (Scope). То же самое происходит при открытии новых вкладок, полном рефреше странице или переоткрытии браузера.

В п.2., для непосредственной проверки логина/пароля, можно использовать что угодно - прямой запрос к базе, логин/пароль-аутентификация на IS4. Так же можно этот п.2. заменить вовсе на редирект на какой-нибудь сторонний сервер аутентификации, который точно так же установит куку в случае успеха.

Авторизацию пока не разбирал, но там, вроде, уже не должно сложностей возникнуть.

[2]
Как грамотно избавиться от редиректа и от необходимости для аутентификации покидать blazor-приложение пока не знаю. Т.е. в теории можно, но только с понижением уровня безопасности:
1. В рамках текущего приложения отобразить страничку аутентификации (или модальное окно). По кнопке "вход" проверить логин/пароль по базе/сервису.
2. Самостоятельно сформировать куку и положить её в качестве обычной (не защищённой) в хранилище браузера.
3. В рамках текущего коннекта распарсить созданную куку в 'HttpContext.User' (то же самое, что делает мидлвар из п.4). Сгенерировать какое-нибудь событие, что юзер залогинился. Вероятно, через свою реализацию 'AuthenticationStateProvider'.
4. Реализовать свой мидлвар аутентификации, где как-то запрашивать (возможно ли?) эту пользовательскую куку от браузера, разбирать и самостоятельно формировать 'HttpContext.User' (так же, как в п.3). Это для повторых заходов в приложение после закрытия браузера или при открытии новых вкладок.

Основная проблема - те куки, что возвращаются в рамках POST-запросов (обычная аутентификация через редирект), сохраняются в хранилище браузера с флагом HTTP-only. Насколько я понял, они защищены от доступа через JS, а потому украсть/модифицировать их сложнее, чем обычные куки (без флага HTTP), которые предполагается использовать в п.2. Т.е. в п.2. я в принципе не смогу сохранить защищённую куку на стороне браузера, только обычную доступную через JS.

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

@Usaga · 28.06.2019, 08:23

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

Как грамотно избавиться от редиректа и от необходимости для аутентификации покидать blazor-приложение пока не знаю.

Скорее всего, без помощи со стороны разработчиков у вас красиво и не получится. Варианты какие:
1. Вы классическим образом авторизируетесь, при установлении WebSocket-соединения прилетает и кука, данные из которой потом висят в сессии и используются в вашем Blazor-приложении. Плюсы: при перезагрузке страницы\переустановке соединения или открытии новой вкладки авторизация подтягивается автоматически.

2. Вы придумываете авторизацию в самом Blazor-приложении. Меняете route на свою страницу авторизации, запоминаете в сессии результаты авторизации. Плюсы: нет редиректа. Минусы: при разрыве соединения\перезагрузке\новой вкладке пользователя опять придётся пнуть на авторизацию.

Добавлено через 4 минуты
Мне кажется, что редирект на страницу авторизации не такое уж и неудобство)

Новые блоги и статьи Все статьи Все блоги /
PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Access VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .
Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .

@kotelok 1338 / 918 / 264 Регистрация: 08.08.2014 Сообщений: 2,759

	Server-side Blazor, аутентификация/авторизация 25.06.2019, 23:04. Показов 11853. Ответов 13 Метки нет (Все метки) Задайте, пожалуйста, хотя бы общие направления (может подробные мануалы есть?). По туториалам и по стандартным шаблонам Студии да, можно сделать, чтобы работало. Можно то же самое прочитать в документации и сделать по шагам. Но совершенно не понятно, как оно внутри устроено. Для самостоятельного фронтэнд-приложения, код которого выполняется в браузере, всё понятно. Приложение тем или иным образом (через прямое обращение к методу API, через редирект на страницу IS4, и т.п.) по логину/паролю получает токен доступа (и, возможно, рефреш-токен), сохраняет его где-то у себя в памяти (или в куках, если требуется) и далее, при обращении к методам API включает токен в HTTP-заголовок. На стороне сервера, где живёт API, токен проверяется согласно каким-то правилам и далее даётся/запрещается доступ к указанному API-методу. А как оно происходит в случае с server-side? И какие варианты реализации вообще есть? И общая архитектура и логика в этом случае какая? 1. В браузере только вспомогательный JS, который создаётся и поддерживается без участия программиста и который прозрачно для разработчика взаимодействует с логикой фронтэнда на сервере через SignalR. 2. На сервере, где фронтэнд-логика находится, для каждого подключенного пользователя автоматически создаётся своя сессия (и поддерживается соединение), в рамках которой и нужно хранить полученные токены? Т.е. пользователь запросил страницу, сервер проверил в его сессии наличие валидного токена, если нет, то редиректнул на страницу аутентификации (в самом простом случае на свою же, или модальное окно показал), там пользователь ввёл логин/пароль, нажал "вход", на сервере (в сессии данного клиента) по кнопке "вход" отработал код проверки логина пароля по базе (или, скажем, через прямое обращение к IS4 по Resource Owner Password Flow), был получен токен, который сохранился в сессию пользователя. Далее этот токен используется для обращений к API, для получения от API набора прав пользователя, для кастомизации интерфейса в зависимости от уровня доступа, который вернул API. При этом API может быть как какой-нибудь внешний, с доступом по HTTP, так и виде зависимой сборки, сервисы которой доступны через DI. 0

@Usaga 14087 / 9305 / 1348 Регистрация: 21.01.2016 Сообщений: 34,929
	26.06.2019, 12:35
	kotelok, насколько я понял, авторизацию прикрутили в Preview6. Добавили некие компоненты-обёртки, которые пробрасывают информацию о пользователе, где и можно узнать авторизован пользователь, али нет. Авторизация, судя по всему (предположение), происходит перед установкой соединения по SignalR (или соединение переустанавливается после авторизации классическим образом) и токен (или что там) первым делом отсылается на сервер и просто держится в ОЗУ. Вопрос интересный, я бы тоже его поисследовал как время появится. Официально доступная информация по этой теме в release notes 1

@sau 2773 / 2073 / 386 Регистрация: 22.07.2011 Сообщений: 7,820
	26.06.2019, 13:28
	https://github.com/aspnet/AspN... s/src/Auth - аутентификация в блазор. - на сколько я понял , нужно писать наследника для AuthenticationStateProvider.cs и реализовать свою логику авторизации. В приложениях Blazor на стороне сервера реализация AuthenticationStateProvider может брать данные пользователя из Http контекста (которые сами же и передаем в запросе), В клиентских приложениях Blazor (те , что выполняются в контексте WebAssembly) реализация AuthenticationStateProvider может обращаться к какому либо апи сервису или хранить данные в хранилищах браузера - свобода реализации в общем. В плане визуализации , они сделали вью.компоненту , которая анализирует результат работы нашей реализации AuthenticationStateProvider и решает какой контент показывать или нет (привет веб.формы LoginView) 1

@kotelok 1338 / 918 / 264 Регистрация: 08.08.2014 Сообщений: 2,759
	26.06.2019, 19:41 [ТС]
	Как-то очень тяжеловесно получается на предлагаемых MS решениях. Если делать на базе 'ASP.NET Core Identity' (дефолтный шаблон из preview-6), то он по умолчанию привязывается к EF-контексту и требует базу специфичной структуры для хранения пользователей. А у меня древняя легаси-база со своими таблицами безопасности и лепить рядом ещё одну, и как-то поддерживать синхронизацию пользователей с ней совершенно не хочется. Если от EF отказаться, но оставить тот же сценарий с Identity, то приходится реализовывать громоздкую кучку интерфейсов (хранилище пользователей, хранилище ролей, класс уравления пользователями и т.п.). Вероятно, можно отказаться от 'Identity' и реализовать свой кастомный мидлвар (со своей страничкой) для аутентификации с последующей инициализацией 'User.Identity' в текущем HTTP-контексте из которого потом данные будут извлекаться для отрисовки верхней плашки и для реализации 'AuthenticationStateProvider' (через который будут корректно работать встроенные механизмы авторизации компонентов Blazor). Но тут я пока совершенно не понимаю, как это правильно и безопасно реализовывать. Дефолтная реализация по кнопке логина редиректится на отдельную статик-страницу (отдельным HTTP-запросом), после успешного логина устанавливает/обновляет две какие-то куки (одна для AspIdentity, вторая для antiforgery), после чего редиректит обратно на приложение, которое заново подключается к серверу уже с правильными куками, после чего устанавливает коннект SignalR и больше HTTP-запросов не шлёт. Но по кнопке 'Logout' кука 'Identity' почему-то не обновляется и не удаляется, только модифицируется кука antiforgery. Так же не понятно, как заставить браузерную сторону при установлении соединения отправлять какую-то кастомную куку на сервер. 0

@yurickas 163 / 138 / 35 Регистрация: 25.11.2015 Сообщений: 910
	26.06.2019, 20:06
	1. Выбираешь ASP.Core Host. Получаешь 2 проекта: клиент и сервер 2. Прикручиваешь туда jwt Вот сейчас пытаюсь сие забабахать, ибо то что работало в Core 2.2 напрочь отказывается в 3.0 И кстати, Identity к авторизации вообще-то никаким боком, если есть своя база с пользователями - используй ее. 1

@kotelok 1338 / 918 / 264 Регистрация: 08.08.2014 Сообщений: 2,759
	27.06.2019, 08:44 [ТС]
	Ещё вопрос общего характера - как самому себе обосновать выбор в пользу server/client-side Blazor? Проект - небольшая внутренняя система учёта на пару сотен пользователей (и локальные, и через инет). Требование пользовательского уровня - отзывчивый интерфейс (без рефрешей всего при каждом клике), вероятно, встроенный чатик, плюс различные уведомления пользователей о событиях сервера. Раньше выбор был очевиден - приложение в браузере и API на сервере. Но теперь server-side-версия, с точки зрения поведения UI, вообще ничем не отличается от client-side. Более того, при тестах в рамках одной машины (т.е. без влияния пинга) у меня вообще получается, что server-side работает более отзывчиво, и это заметно даже просто на глаз. Т.е. одно и то же базовое приложение из стандартного шаблона: 1. При начальной загрузке: client-side - несколько секунд, server-side - мгновенно. 2. При переходе на страницу, где запрашиваются данные для отображения в таблице: client-side - видна пауза перед отображением (при каждом переходе), server-side - мгновенно. Здесь, очевидно, сказываются накладные расходы client-side, которому надо - установить коннект на API-сервер, сформировать/отправить HTTP-запрос, на сервере разобрать HTTP-запрос, сериализовать данные в JSON, на клиенте десериализовать полученные данные и подготовить для отображения. А для server-side всё проще - соединение (SignalR) уже установлено и поддерживается, сериализовывать/десериализовывать данные в JSON не нужно. Однако, это самый простой сценарий, вероятно, в каких-то случаях картина будет иная. Из минусов client-side: 1. На данный момент не известно когда оно вообще в релиз уйдёт и в каком виде. 2. Ограничено 'netstandard' (но тут я не могу оценить, насколько это вообще имеет значение). 3. Лишний код для общения с API (даже если автогенерируемый, даже если расшарить DTO). Из возможных минусов server-side: 1. Не известно, как оно будет держать коннект в условиях плохого инета (большой пинг, потери пакетов). И не только держать коннет, но и просто откликаться на действия пользователя. 2. Не могу оценить масштабы, но очевидно, что нагрузка на сервер будет выше, чем при client-side. Хотя, вероятно, в условиях пары сотен вялых пользователей это вообще значения не имеет. 3. Пока не видится возможным реализовать красивую аутентификацию без перезагрузки приложения при login/logout. 0

@Usaga 14087 / 9305 / 1348 Регистрация: 21.01.2016 Сообщений: 34,929
	27.06.2019, 13:49
	kotelok, ну, вполне себе нормально. Прилетают сами данные, плюс какой-то diff для DOM'а. Что-то среднее между чистым JSON и классическим серверным рендерингом. 0

@kotelok 1338 / 918 / 264 Регистрация: 08.08.2014 Сообщений: 2,759
	27.06.2019, 22:22 [ТС]
	[1] С кастомной аутентификацией разобрался. Но красиво не получается, только через редиректы. Кратко суть: 1. По кнопке логина делается редирект на обычную статичную razor-страницу ввода логина/пароля (и прочего логин-функционала). 2. Там пользователь вводит логин/пароль и обычным POST-запросом выполняет аутентификацию, которая в ответ возвращает HTTP-куку, в которую сложены данные об аккаунте. Браузер сохраняет куку и при последующих коннектах включает её в соответствующий HTTP-заголовок. 3. После этого происходит обычный редирект обратно на Blazor-приложение. Приходит HTTP-коннект с полученной в п.2. кукой аутентификации, которая через дефолтный мидлвар аутентификации разбирается и раскладывается в объект 'HttpContext.User' текущей сессии (Scope). То же самое происходит при открытии новых вкладок, полном рефреше странице или переоткрытии браузера. В п.2., для непосредственной проверки логина/пароля, можно использовать что угодно - прямой запрос к базе, логин/пароль-аутентификация на IS4. Так же можно этот п.2. заменить вовсе на редирект на какой-нибудь сторонний сервер аутентификации, который точно так же установит куку в случае успеха. Авторизацию пока не разбирал, но там, вроде, уже не должно сложностей возникнуть. [2] Как грамотно избавиться от редиректа и от необходимости для аутентификации покидать blazor-приложение пока не знаю. Т.е. в теории можно, но только с понижением уровня безопасности: 1. В рамках текущего приложения отобразить страничку аутентификации (или модальное окно). По кнопке "вход" проверить логин/пароль по базе/сервису. 2. Самостоятельно сформировать куку и положить её в качестве обычной (не защищённой) в хранилище браузера. 3. В рамках текущего коннекта распарсить созданную куку в 'HttpContext.User' (то же самое, что делает мидлвар из п.4). Сгенерировать какое-нибудь событие, что юзер залогинился. Вероятно, через свою реализацию 'AuthenticationStateProvider'. 4. Реализовать свой мидлвар аутентификации, где как-то запрашивать (возможно ли?) эту пользовательскую куку от браузера, разбирать и самостоятельно формировать 'HttpContext.User' (так же, как в п.3). Это для повторых заходов в приложение после закрытия браузера или при открытии новых вкладок. Основная проблема - те куки, что возвращаются в рамках POST-запросов (обычная аутентификация через редирект), сохраняются в хранилище браузера с флагом HTTP-only. Насколько я понял, они защищены от доступа через JS, а потому украсть/модифицировать их сложнее, чем обычные куки (без флага HTTP), которые предполагается использовать в п.2. Т.е. в п.2. я в принципе не смогу сохранить защищённую куку на стороне браузера, только обычную доступную через JS. Ну и второй момент - надо как-то заставить бразер автоматически включать в инициализирующий запрос эту пользовательскую куку. По умолчанию он, почему-то, этого не делает, включает только HTTP-куки. 0

Server-side Blazor, аутентификация/авторизация

Решение