Что насчет дорожной карты EF Core 2.2?

Что насчет дорожной карты EF Core 2.2?

https://github.com/aspnet/Announcements/issues/308

Дорожная карта выглядит хорошо, особенно проверки работоспособности и HTTP 2.0. Однако в самом лучшем случае я не согласен с необходимостью создания простого первого сервера авторизации Microsoft. IdentityServer4 прекрасно заполняет этот пробел, и время, потраченное на повторную реализацию более простой версии, можно было бы лучше потратить в другом месте. Я понимаю, что цель состоит в том, чтобы предоставить простое решение, но аутентификация сложна, а IdentityServer предоставляет API, который настолько прост, насколько это возможно. Если есть идеи для более простой абстракции, ее можно было бы построить поверх IdentityServer, чтобы люди могли использовать простую абстракцию, но при этом имели возможность, если она им нужна.

Обновлять

В ходе выступления сообщества ASP.NET было упомянуто, что группа ASP.NET Core обсуждает с командой Identity Server варианты, включая создание чего-либо поверх Identity Server. Я думаю, что все мы этого хотим, молодец!

Каковы текущие планы в отношении веб-перехватчиков ASP.NET Core ?

Что касается диспетчера, то это будет возможно в мидлваре? 😱
C# public async Task Invoke(HttpContext context, [FromRoute] SomeModel someModel)
^[FromQuery]?

Простой сервер аутентификации, но также помните, что произошло с простым сервером аутентификации Katana.

Я хочу повторить опасения @RehanSaeed и попросить уточнить, какие именно варианты использования должен выполнять этот новый сервер. Если это в первую очередь для того, чтобы у веб-API был способ получить свой токен-носитель, действительный в рамках существующей аутентификации приложения, тогда это будет нормально. Но все остальное, вероятно, лучше оставить существующим решениям, которые уже предлагают множество вариантов разной сложности и гибкости с такими продуктами, как IdentityServer, OpenIddict и AspNet.Security.OpenIdConnect.Server.

А как насчет внутрипроцессного хостинга IIS ?

Не могли бы вы подробнее рассказать о TypeScript части «Создание клиента API (C # и TypeScript)»?

Это было бы действительно то, чего я бы с нетерпением ждал. В настоящее время я использую NSwag для автоматического создания своих служб Angular Client API. Но существует так много различных комбинаций, которые возможны для клиентских конфигураций, что я думаю, что угодить всем может быть проблематично.

Я сразу же подумал о том, что следует учитывать (и, если возможно, следует настраивать):

• Просто клиент TypeScript с выборкой или сервис Angular с HttpClient?
• Если это Angular, какие версии вы поддерживаете (также важно для RxJS)?
• обработка null / undefined
• обработка перечисления
• Дата или момент JS для типов даты?
• Обработка исключений, обработка ошибок валидации
• Как расширить сгенерированный код в клиенте?
• Возможность влиять на генерацию имени (например, удаление части DTO из xxxDTO для сгенерированных клиентских классов или уже в определении OpenAPI)

Если бы можно было проголосовать за функции, эти улучшения / исправления существующего промежуточного программного обеспечения были бы в моем списке желаний:

• Обеспечивает поддержку шифрования https://github.com/aspnet/Home/issues/1190.
• Промежуточное ПО Response Cache в основном непригодно для использования, как сейчас. Добавление хранилища кэша ответов Redis и возможность расширения для пользовательских операций с кешированными ответами должно решить проблему https://github.com/aspnet/Home/issues/2606.
• Поддержка обслуживания файлов с кодировкой pre-GZIP и pre-BR .
• Добавьте Brotli Compression Provider, а также исправьте несколько проблем с промежуточным программным обеспечением для сжатия ответов.

Я также голосую за то, чтобы пропустить продукт Authorization Server. Безопасность сложна, и был большой толчок к переходу на облачные сервисы для устранения обслуживания, и любой, кто хочет большего контроля, уже может использовать IdentityServer4, который хорошо построен, протестирован, задокументирован и поддерживается. Простая установка занимает 5 минут, и у них есть множество начальных примеров, видео и руководств.

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

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

Изменить: @DamianEdwards ответил в Твиттере, что это действительно недосмотр (это означает, что он запланирован на 2.2). Уф!

Я повторю другие комментарии. Если вы собираетесь инвестировать в авторизацию / политику, в частности, в ее упрощение, я лично предпочел бы сотрудничество с такими, как OpenIddict и IdentityServer, в отношении документации и инвестиций в строительные леса. Я не могу не чувствовать, что любая работа, какой бы простой она ни была, просто приведет к дублированию потрясающих сторонних усилий и к ненужным затратам на обслуживание для команды aspnet.

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

Текущие - Id4, OpenIddict - очевидно, отличные проекты OSS, и я не могу избавиться от ощущения, что тот, за которым стоит поддержка MS, может когда-либо быть плохим ...?

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

Мне жаль, что Кодекс поведения MS OSS не включает строку, которая гласит: «Не продвигайте функции, которые дублируют то, что может быть добавлено с помощью запроса Nuget, и которые случайно разрушат бизнес двух человек, который вносит свой вклад в нашу экосистему ".

Циник во мне не может не задаться вопросом, было ли для некоторых инсайдеров кровавый нос Броку и Доминику особенностью этого предложения, а не ошибкой. Это то, что происходит с малыми предприятиями, которые когда-либо имели смелость критиковать все, что делает команда ASP?

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

Кроме того, хорошо протестированная библиотека JSON-LD 1.1 была бы хорошим конкретным дополнением к дорожной карте. :)

Повторяя то, что говорили другие, я бы предпочел, чтобы работа по авторизации выполнялась из чего-то вроде IdentityServer4, чем выполнялась заново вами. Если есть пробелы, то наверняка их устранение с помощью вкладов, выборок и уточнения точек интеграции было бы лучшим способом. Возможно, также обратите внимание на ваше облачное предложение в этой сфере (B2C), которое находится в ужасающем состоянии.

Помимо этого, хотя вы заявляете, что цель состоит не в том, чтобы воспроизвести функциональность существующих предложений с открытым исходным кодом, а для простоты, это в некоторой степени эквивалентно классической ловушке перезаписи: «это решение слишком сложное и немного запутанное, давайте его перепишем! ". Это наивно, и во время n версий я бы положил деньги на вас, разобравшись со многими крайними случаями, которые требуются для реальных решений и с которыми что-то вроде IdentityServer уже имеет дело.

В более широком смысле, с приобретением GitHub в последнее время было много дискуссий по поводу отношения Microsoft к открытому исходному коду. Замечательно, что Microsoft делает так много работы в открытом доступе, но часть того, чтобы быть хорошим гражданином открытого исходного кода, заключается в использовании существующего открытого исходного кода, когда он существует.

Это особенно важно для владельцев платформ, таких как вы, - владелец платформы, дублирующий функциональность в существующих предложениях с открытым исходным кодом, _ не одобряет_ вклады, одновременно участвуя в этих предложениях _ поощряет_ вклад.

Я тоже не вижу смысла затрат на авторизацию, но хотел бы, чтобы _management_ ASP.NET Core Identity улучшился. Дэмиан Эдвардс совершенно ясно дал понять на live.asp.net, что мы не должны разворачивать собственную безопасность, но - если я не пропустил это - ASP.NET Core Identity не содержит каких-либо инструментов управления пользователями, и поэтому мы должны свернуть наш. Это меня немного пугает, поскольку я не эксперт по безопасности и смертельно боюсь оставить дыру в безопасности, созданную мной.

Как насчет переноса средств форматирования контента с уровня MVC на абстракции AspNetCore.Http в версии 2.2?

Возможно, ответственный руководитель проекта мог бы написать более подробное описание этого Identity Server Lite, чтобы точно прояснить, какие недостатки в существующих сторонних решениях с открытым исходным кодом команда ASP.NET стремится устранить. Потому что в нынешнем виде вы говорите о том, чтобы заново изобрести колесо, но, возможно, удалите некоторые спицы, а это не имеет особого смысла. Как уже сказал кто-то другой, исправление AAD B2C и обеспечение первоклассной интеграции с ним было бы замечательно и имело бы смысл с точки зрения бизнеса для MS.

Кроме того, задумывались ли вы, насколько сложно будет получить новый продукт Auth server после @blowdart?

Есть ли планы иметь встроенную поддержку RESTful API, такую ​​как у django?
Потому что это то, что каждый раз пишут все разработчики!

Недавно я построил что-то, что можно было бы написать как универсальный контроллер RESTful API:

https://github.com/0xRumple/dorm-portal/blob/master/DormPortal.Web/Controllers/StudentsController.cs

Также согласен с тем, что «я не понимаю, как вы можете заставить систему безопасности работать с« нулевой конфигурацией »больше, чем они могут» и «вы говорите о изобретении колеса, но, возможно, удалении некоторых спиц», сервер идентификации - отличный продукт, очень прост в использовании и обеспечивает расширяемость для более сложных сценариев, не знаю, зачем нам нужна «упрощенная» версия.

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

• https://github.com/Xabaril/BeatPulse , включает в себя множество предварительно написанных проверок и даже поставляется с пользовательским интерфейсом
• https://www.app-metrics.io/web-monitoring/aspnet-core/health/

В чем будет разница в функциях и в том, что предусмотрено в 2.2?

@ 0xRumple Усовершенствования ApiController должны помочь сделать это менее подробным в целом. Но нет, вы, вероятно, не увидите чего-то, что по умолчанию просто предоставляет вам CRUD API для ваших сущностей. Такая вещь должна сделать слишком много предположений о вашем DAL и авторизации.

Если вы следуете определенным шаблонам в своем приложении, нет ничего плохого в создании ваших собственных базовых типов или соглашений в 2.2, которые обобщат вашу работу.

@kieronlanning

Текущие - Id4, OpenIddict - очевидно, отличные проекты OSS, и я не могу избавиться от ощущения, что тот, за которым стоит поддержка MS, может когда-либо быть плохим ...? Существует ограничение на объем поддержки, доступной для небольшой группы людей, и, в конце концов, это критически важные продукты.

Поскольку вы спросили, может ли это быть плохим:

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

Гораздо хуже то, что это вредит сторонней экосистеме и препятствует выпуску новых продуктов из-за того, что Microsoft выпускает «официальный» пакет, который многие компании застревают, выбирая только потому, что он от Microsoft, даже если он технически (а в данном случае должен быть) меньше способный. ASP.NET уже интегрирует Json.NET, Polly, AutoMapper и многие другие библиотеки, поэтому кажется ошибкой перестроить такой сложный продукт безопасности (которому потребуется 80% того же базового кода), когда уже существуют отличные варианты и с так много еще интересных вещей в дорожной карте, над которыми нужно работать.

@poke
Вы правы, писать базовые классы моих приложений - хорошая идея.

На самом деле я считаю, что это не входит в рамки ответственности:

CRUD resources (repository responsibility)

Manipulating data (sieve responsibility)
    Paging
    Filtering
    Searching
    Sorting
    Shaping

Но есть много вещей, которые, как я думал, AspNetCore мог бы сделать лучше (имея пакет AspNetCore.RestFramework):

1. HATEOAS (самообнаруживаемый api)
2. Типы медиа (настройка пользовательских типов медиа)
3. Управление версиями (обновление версии mediatype)
4. Основные метаданные данных (разбивка на страницы в заголовке X-Pagination, фильтрация метаданных и т. Д.).
5. Ограничение скорости и дросселирование.

Я знаю, что существует множество библиотек, я нашел некоторые здесь: https: //github.com/thangchung/awesome-dotnet-core ... Но сторонние библиотеки на самом деле не очень хороший вариант для корпоративных приложений!

То же самое касается сита, если есть ОФИЦИАЛЬНЫЙ пакет для разбивки на страницы, фильтрации ... и т. Д., Разработчики не будут стремиться писать библиотеки с ошибками или не поддерживаемые, я использовал это сито в своем приложении, о котором я упоминал выше: https: // github.com/Biarity/Sieve , но эта библиотека может перестать обслуживаться в любую секунду, когда автор был занят.

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

Но сторонние библиотеки на самом деле не лучший вариант для корпоративных приложений!

^ Вот почему у нас не может быть хороших вещей 😞

Но сторонние библиотеки на самом деле не лучший вариант для корпоративных приложений!

Да, это именно тот образ мышления, который здесь необходимо изменить. ASP.NET Core и .NET Core - это открытый исходный код, и их экосистема _is_ охватывает сообщество открытого исходного кода, и оно должно продолжать это делать. Не только с решениями с открытым исходным кодом, которые являются частью .NET Foundation, но и с любыми другими решениями.

но эта библиотека может перестать обслуживаться в любую секунду, когда автор был занят

Точно так же «официальный» пакет может остаться незамеченным в любую секунду, когда компания изменит свой интерес. Это уже происходило с конкретными вещами Microsoft и раньше, включая несколько опубликованных ими пакетов с открытым исходным кодом, но это действительно естественно для любой компании.

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

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

Если вы создаете корпоративные приложения и все еще боретесь с этим синдромом NIH (или «изобретено не в <large-company>»), вам действительно стоит проснуться, потому что сейчас 2018 год, и вам, вероятно, следует принять открытый исходный код сейчас.

Вы правы, Microsoft может прекратить поддержку любого пакета, но, по крайней мере, у них есть конкретный LTS: https://www.microsoft.com/net/support/policy

Например, поддержка .NET Core 1.1 заканчивается 27 июня 2019 года ... таким образом, я могу быть уверен, что если я буду использовать эту версию, я не пострадаю посередине.

Однажды я использовал сторонний помощник по тегам разбиения на страницы, и это было неприятно, автор в основном сказал мне, что он не будет исправлять его для .NET Core 1.1, и я должен обновить проект, это была университетская система, в 2.0 (и он имеет на это полное право, потому что он написал этот пакет БЕСПЛАТНО).

Вот проблема: на предприятии это не работает ... вы не можете убедить всю команду, что вам следует перейти на 2.0, пока приложение работает, только потому, что помощник тега разбиения на страницы не работает. т работать!
Итак, вы просто начинаете взламывать исходный код, как я, используя декоратор: https://github.com/cloudscribe/cloudscribe.Web.Pagination/issues/37

И да, кто сказал, что я не большой поклонник open-source: confused:?

@ 0xRumple - это не идея открытого исходного кода для участия и сотрудничества?

Если бы этого стороннего помощника тега нумерации страниц не существовало, вам пришлось бы написать его самостоятельно и в любом случае поддерживать его «на предприятии».

Вот проблема: на предприятии это не работает ... вы не можете убедить всю команду, что вам следует перейти на 2.0, пока приложение работает, только потому, что помощник тега разбиения на страницы не работает. т работать!

Вместо того, чтобы пытаться «убедить всю команду в том, что вам следует перейти на 2.0», внесите обновление и помогите, а не полагайтесь на кого-то еще, чтобы сделать работу или ждать, пока Microsoft предоставит эквивалент. Если владелец не хочет принимать ваш взнос, используйте вилку для ваших нужд.

Я предполагаю, что ваш тип мышления (совсем не оскорбительный) - большая часть того, почему идет дискуссия между «сервером авторизации Microsoft» и сервером идентификации. Как когда-нибудь будет работать открытый исходный код, если разработчики не захотят участвовать. Стоит ли ждать, пока Microsoft предоставит весь необходимый нам код?

Я согласен со многими здесь, что Microsoft должна быть осторожна, чтобы не уничтожить хорошие проекты с открытым исходным кодом в экосистеме, сделав свои собственные замены для всего.

На самом деле я являюсь автором библиотеки taghelper разбиения на страницы, упомянутой @ 0xRumple , его проблема действительно была связана с компонентом pagedlist, а не с taghelper, который на самом деле имеет более старый nuget, который поддерживает ядро ​​aspnet 1.x. Страничный список действительно был частью предыдущей библиотеки пейджера с открытым исходным кодом, которая использовалась в дизайне моей библиотеки и когда-то использовалась на демонстрационных страницах, но пейджер taghelper не зависел от реализации страничного списка, и есть другие постраничные страницы. список реализаций, которые он мог бы использовать, все еще используя taghelper пейджера. Фактически, с тех пор я полностью удалил выгружаемый список из этой библиотеки, поскольку он даже не является частью taghelper и никогда не был.

На самом деле, использование пакетов nuget от разработчиков OSS ничем не отличается от использования Microsoft в том, что если вы застряли на aspnet core 1.1, вы не сможете получить исправления и улучшения от aspnet core 2.x, если вы не обновитесь до новой структуры.

@joeaudette
Я только что упомянул этот пример, чтобы проиллюстрировать свою точку зрения на встроенные и сторонние решения, я все еще благодарен за вашу работу над этим тегом пагинации ... университет использует ваш пакет нумерации страниц, и они счастливы: heart:

@alhardy

Стоит ли ждать, пока Microsoft предоставит весь необходимый нам код?

Это основная проблема, мы думаем, что когда Microsoft представит официальное решение, они будут бороться с любым другим решением с открытым исходным кодом или будут писать каждую строчку кода самостоятельно: smile:

Конечно, нет, мы можем получить лучшее из обоих миров, официальное решение и базе сообщества, если Microsoft примет правильные решения и создаст недостающие решения, чтобы разработчики могли сосредоточиться на них.

Сообщество django поняло это правильно, они предоставляют / официально принимают первоначальное простое решение для конкретной проблемы, например, фреймворк RESTful, и сообщество строит поверх этого ... взгляните здесь на их начальный этап создания django-rest- фреймворк: https://www.djangoproject.com/weblog/2016/jun/22/django-rest-framework-funding/

Они начали первоначальный проект, и сообщество улучшается / строится на вершине этого, это их репо: https: //github.com/encode/django-rest-framework ... около 800 участников!
И сообщество стремится создавать пакеты, которые решают проблемы поверх этого пакета, например django-rest-auth или django-rest-framework-jwt .

По крайней мере, они предоставляют такие «официальные решения», которые нужны большинству разработчиков, например django-admin-site или django-debug-toolbar . Это также происходит из философии Python «батареи включены», сначала я подумал, что это плохо, поскольку он стремится к решениям с наименьшим общим знаменателем, а позже я понял, какую легкость это приносит.

* PS: Dapper (от StackExchange) и EFCore (от Microsoft) являются ORM, но они стремятся решить одну и ту же проблему с помощью разных подходов. Первоначально Dapper был создан в 2011 году, в то время как EFCore 2014 ... сильно ли EFCore повлиял на проекты с открытым исходным кодом? конечно, нет, но это официальное решение!
Люди уже строят на этом удивительном материале, например: https://github.com/crhairr/EntityFrameworkCore.MongoDb/

EFCore сильно повлиял на проекты с открытым исходным кодом?

Ууух, кто-нибудь помнит NHibernate (который по функционалу ближе всего к EF)? Нет, наверное, нет, потому что после выхода EF он почти мертв

@ 0xRumple

Конечно, нет, мы сможем получить лучшее из обоих миров, официальное решение и решение на уровне сообщества, если Microsoft примет правильные решения и создаст недостающие решения,

В данном случае это не так, потому что оно воссоздает существующее решение, но с намеренно меньшей функциональностью.

Entity Framework и Dapper очень разные. EF всегда разрабатывался как полнофункциональная ORM, и оба появились спустя годы после оригинального Linq-To-SQL в 2007 году .

Однако я тоже не думаю, что ты ошибаешься, и кажется, мы все говорим мимо друг друга. Тема - это в основном комментарии о продукте сервера аутентификации, в то время как вы говорите о библиотеках, связанных с REST, которые кажутся небольшими и достаточно сфокусированными, чтобы их можно было включить в веб-фреймворк. Я согласен с тем, что стандартизованные параметры search/paging/filter были бы полезны, если бы они были встроены в код веб-API.

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

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

Да, Identity Server 4 великолепен. Но для нетехнического риск-менеджера это то, на что у нас нет гарантии, что-то, что поддерживается горсткой людей, и, что еще хуже, что-то с исходным кодом, доступным для всеобщего обозрения. Этот человек заблуждается, но средний разработчик на земле не выиграет эту битву.

«Identity Server Lite», как метко выразился @markrendle , в первую очередь написанный сотрудниками Microsoft, может стать

@edandersen

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

Я почти уверен, что сотрудники IdentityServer предоставят некоторую поддержку, если вы заплатите им за это - так же, как вы платите Microsoft. OSS не означает бесплатного.

Что заставляет вас думать, что команда ASP.NET Core в Microsoft - это не «горстка людей»? Спойлер ... Их всего 20-30 человек. Только пара могла бы работать над таким продуктом.

Мне действительно любопытно, почему «исходный код, доступный для всеобщего обозрения» - это плохо? И почему вы думаете, что этот продукт в Microsoft не будет открытым исходным кодом? Это новый вариант по умолчанию.

@khellang "исходный код, доступный для всеобщего

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

Что ж, если мы начнем использовать эти аргументы, не связанные с техническими менеджерами, все начнет сходить с ума. ИМХО, люди, не являющиеся техническими специалистами, не должны диктовать, что использовать, а что нет. Если они хотят иметь высказывание, по крайней мере, они должны знать, о чем они говорят, и сказать, что хорошо известный пакет, такой как IdentityServer, менее качественный, чем пакет MS, для меня это совершенно неправильно. Я бы сбежал из такой компании!

Но дело в том, что практически все согласны с тем, что тратить время на то, что уже есть, это надежно, и МНОГО людей используют это, это немного странно. Интересно, какова настоящая причина этого ... Я не думаю, что это было просто так: О, давайте создадим нашу собственную вещь, просто потому, что мы можем. Действительно ли клиенты просят об этом, о чем мы, возможно, не знаем?

Лично я не рассматриваю другого претендента в области OAuth-Server как проблему, но это хорошо.

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

Если вы хотите или вам нужно больше от сервера OAuth, ничто не мешает никому из нас использовать существующие решения. Или, если вы хотите, чтобы шаблон с одним щелчком выполнял базовый OAuth _ и ничего больше_, то это кажется достойной целью, по крайней мере, для меня.

Я думаю, что этот тред превратился в око за око о том, что такое OSS, что MS хорошо делает и что MS не умеет, вместо того, чтобы сосредоточиться на том, что находится в дорожной карте для .NET Core 2.2, что на самом деле имеет значение здесь.

@khellang
«NHibernate мертв», - сказал кто? Я вижу, что проект все еще жив, и даже имеет лучшую динамику, чем Dapper.
https://github.com/nhibernate/nhibernate-core/graphs/contributors
https://github.com/StackExchange/Dapper/graphs/contributors

Ах, я не упомянул IdentityServer до сих пор, чтобы придерживаться своей точки зрения о наличии фреймворка RESTful в официальных пакетах aspcore ... вот мои мысли об IdentityServer, он действительно солидный и отличный, НО это проект двух парней, взгляните на показатели:
https://github.com/IdentityServer/IdentityServer4/graphs/contributors

Около 85% работы выполняют 2 человека, и это нормально для проекта, связанного с безопасностью, но на предприятии многие компании думают о ремонтопригодности таких проектов в будущем. Недавно одна компания сказала мне, что они хотят, чтобы я использовал React вместо Vus.Js в их проекте только потому, что они сказали, что «vue.js - это в значительной степени Evan You» ... и я думаю, что они правы. И это то, что я пытаюсь сказать с самого начала обсуждения наличия пакета RESTful в официальных пакетах, ни одна крупная компания не согласится с тем, чтобы вы использовали «потенциальный» неподдерживаемый пакет в своих проектах.

То же самое касается обработки / просеивания данных (разбиение на страницы, формирование, сортировка и т. Д.), Потому что почти каждый проект содержит эти требования, и да, как сказал @manigandham , они стандартизированы и просты.

@manigandham
Именно это я считаю правильным ... официально адаптировать и поддерживать решения, будь то финансовая поддержка или участие через github, или, по крайней мере, упоминание их в их документах или курсах (я уже видел, как Хансельман упоминал SwashBuckle на одном из своих курсов в Microsoft Virtual Academy, что действительно здорово, и хотелось бы увидеть больше адаптации к таким проектам!).

@kieronlanning
Вы правы, мы ушли слишком далеко от основной темы ... но, как я уже упоминал ранее, ядро ​​asp только что стало очень зрелым (производительным и надежным), и я думаю, что пора начать с нестандартных решений. -коробочные решения .

Я думаю, что сбрасывать со счетов проект из-за того, что в нем два основных участника, чертовски глупо. IS4 очень хорошо поддерживается, и эти два парня проводят много времени, отвечая на вопросы и помогая людям. Он также широко известен как одно из лучших решений FOSS для сервера OAuth2 на рынке.

«NHibernate мертв», - сказал кто? Я вижу, что проект все еще жив, и даже имеет лучшую динамику, чем Dapper.

@ 0xRumple Я сказал «почти мертв» 😉 Кажется, у вас есть очень странные показатели работоспособности и использования проектов OSS. Справедливо ли сравнивать количество коммитов проекта с 2003 года с количеством коммитов, совершенных с 2011 года? Они также очень разные звери (как отмечалось ранее в ветке); Dapper был «завершенным» (это не означает, что его не обслуживают, заброшены и т. Д.) В течение некоторого времени, в то время как NHibernate (и его набор функций) отставал.
Я знаю, что проект все еще продолжается, но я не могу вспомнить последний раз, когда я консультировал последние 7 лет в пространстве .NET, где я столкнулся с NHibernate в дикой природе (где он не находился в процессе переносится на Entity Framework). Все, кто следил за этим пространством последние пару лет, очень хорошо знают, что NHibernate отстает и теряет долю рынка в пользу Entity Framework. Посмотрите только на количество загрузок NuGet: Entity Framework имеет 45,8 МБ, а NHibernate - 3,4 МБ.

В любом случае, дело не в Entity Framework и NHibernate. Это был всего лишь один пример. Мы обсуждали это снова и снова; совсем недавно, когда Microsoft развернула свою собственную облегченную реализацию контейнера IoC в ASP.NET Core или когда Microsoft рассматривала возможность развертывания собственного средства сопоставления объектов. Каждый раз, когда Microsoft входит в какое-либо пространство в сообществе OSS, он высасывает из него много (большую часть?) Воздуха. Часто бывает достаточно, чтобы небольшие проекты, реализуемые сообществом, со временем задохнулись. Я и большая часть сообщества слишком хорошо это знаю; невозможно конкурировать с Microsoft в мире Microsoft (.NET). Я полностью понимаю, что у них есть платные клиенты, которых они должны удовлетворить, поэтому я не ожидаю, что эта обратная связь изменит их мнение: smile:

Потрясающие возможности :)

Где я могу получить дополнительную информацию о функции проверки работоспособности?

Улучшение управления самозаверяющими сертификатами

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

В духе разделения проблем мои веб-приложения вызывают несколько веб-API. В первую очередь я разрабатываю эти веб-API, используя https: // localhost :. Когда веб-API готов (достаточно), я публикую его в IIS на моем локальном компьютере. У каждого сайта есть соответствующее имя хоста, которое я установил на своем внутреннем DNS-сервере. На этом этапе я использую - @blowdart - gist Барри https://gist.github.com/blowdart/1cb907b68ed56bcf8498c16faff4221c для создания сертификата сервера. Я импортирую сертификаты во все нужные хранилища, все работает на моей машине без аварийных сигналов.

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

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

Как неспециалист по безопасности, я хотел бы кое-что увидеть:

• возможность иметь локальный корневой сертификат для всех сертификатов разработки, которые я создаю, а затем получить авторизованный способ импорта его на ПК, Mac, устройства Android, iPad и iPhone, чтобы эти тревожные страницы больше не появлялись

• более простой метод создания сертификатов для API-интерфейсов, который можно использовать с IIS и Kestrel, который правильно заполняет все правильные хранилища сертификатов

@CrispinH Если честно, поддержка корневого ЦС была бы проблемой при развертывании корневого ЦС. Если вы находитесь в этой точке, пора подумать о том, чтобы самостоятельно развернуть корневой центр сертификации и управлять им. Самоподписанная поддержка, будь то глобальный инструмент или мой скрипт, предназначена только для этой разработки. Как только вы начнете позволять людям прикрепляться к нему, вы выходите за рамки этой функции. Если вы работаете в организации и хотите, чтобы люди имели доступ к службам, ей необходимо определить свою стратегию сертификатов, запустить внутренний центр сертификации через Windows или OpenSSL и вытолкнуть корень с помощью политики AD или других средств.

@blowdart Одной из причин моего блеяния было то, что я потратил пару дней, пытаясь развернуть корневой центр сертификации, и не смог сделать это правильно, хотя и не имел достаточной компетенции в этой области. Я даже пытался придумать, как изменить вашу суть, чтобы принять локальный корневой центр сертификации.
Вся документация, которую я нашел, была слишком общей - все, что мне нужно, это процесс создания сертификатов (в идеале на основе корневого центра сертификации) исключительно для защиты API и веб-приложений с помощью сертификата сервера. Возможно, документация по конкретному случаю - это все, что нужно.

@CrispinH Window Server поставляется с сертификации, который вы можете настроить, если хотите пройти полный путь.

Сертификаты в целом не легкая тема , и вы должны будете узнать совсем немного , чтобы сделать это правильно.

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

@CrispinH Как сказал @poke, это сложно сделать правильно. Если у вас есть машины, доверяющие корневому ЦС, то любые выданные сертификаты будут доверенными. И разработчики запускают ненадежный код в своих ящиках для разработчиков, в конце концов, это и есть пакеты nuget. Так что подумайте о том, что крадет ваш корневой ЦС. В реальной жизни корневые ЦС, как правило, остаются в автономном режиме, они подписывают второй сертификат, который ограничен в том, что он может делать, обычно это сертификаты сервера и клиента, а затем сертификаты выдаются этим, контру, многие ЦС разработчиков ограничены, поэтому Компрометация будет означать возможность выпускать доверенные сертификаты подписи кода. Не желая ужасно оскорблять, разработчик не должен запускать центр сертификации, лучше оставить его на усмотрение тех, кто понимает последствия, а последствия могут быть ужасными. Затем следует рассмотреть ротацию сертификатов, отзыв, OCSP и многое другое. У меня должен быть тестовый ЦС для промежуточного ПО для проверки подлинности сертификата, и он находится на выключенной виртуальной машине. Я очень нервничаю, когда включаю его, чтобы получить больше тестовых сертификатов.

Если вы действительно хотите спуститься в этот корень (каламбур), тогда https://infiniteloop.io/powershell-self-signed-certificate-via-self-signed-root-ca/ может помочь вам начать работу в PowerShell, но это не дает вам ни CRL, ни OCSP, ни поддержки отзыва. https://gist.github.com/Soarez/9688998, похоже, охватывает OpenSSL. И если вам нужны списки отзыва сертификатов, тогда в Windows встроен ЦС, настройка которого задокументирована здесь https://leastprivilege.com/2008/08/14/how-to-build-a-developmenttestdemo-ca/

_Обратите внимание, что я не использовал ни одну из приведенных выше ссылок (хотя я доверяю автору последней) и никоим образом не является официальной рекомендацией MSFT. Официальная рекомендация группы безопасности ASP.NET - позволить тому, кто разбирается в инфраструктуре и рискует, создать для вас корпоративный центр сертификации. Поговорите со своим ИТ-отделом_

@blowdart Нет, я действительно _ не_ хочу спускаться в этот «корень». Приятно знать, почему именно сейчас.

Похоже, что мое гуманоидное тестирование нужно будет проводить в общедоступном Интернете на тестовом хосте с использованием сертификатов Let's Encrypt, но с установленной стеной аутентификации, чтобы не допустить посторонних глаз.

В зависимости от того, что вам нужно, и вашего бюджета, некоторые компании, такие как DigiCert, предлагают услуги управляемой PKI. Это может использовать частный корень или их общедоступный. Я не знаю затрат.

И если это только HTTPS, помните, что вы получаете сертификат для каждого поддомена azurewebsites.net.

Взвешивание новой реализации OpenID вместо еще одной реализации, чтобы изучить, принять и принять участие в усилиях сообщества IdentityServer4 и внести свой вклад в создание самоуверенной версии IdentityServer «Lite», которую можно было бы включить из nuget и настроить с минимальными усилиями.

Вы все слишком остро реагируете.
Команда ASP.NET уже думает так же, как и все вы. @DamianEdwards говорил об этом в последней

Вот самая важная часть (но я призываю вас послушать ее полностью):

«Мы на самом деле сейчас говорим об этом с людьми из IdentityServer».
https://youtu.be/Tzh2EXwgEk8?t=25m15s

Действительно интересно наблюдать, насколько бурно обсуждается проект "Сервер авторизации MSFT": smile:

Между прочим, Витторио Берточчи связался со мной ровно 2 года назад, чтобы поговорить об этом проекте, поскольку они рассматривали возможность использования OpenIddict (сервер OIDC, который я разрабатываю и поддерживаю) в качестве основы для этого проекта.
В прошлом году мне сказали, что они предпочли использовать собственную реализацию вместо использования стороннего OSS, поскольку это было сочтено «слишком стратегическим» с точки зрения бизнеса (это то, что я мог понять).

Я рад видеть, что они передумали и, наконец, рассматривают возможность использования существующего решения OSS, такого как IdentityServer4, вместо того, чтобы создавать что-то с нуля: это очень хороший сигнал, посланный сообществу .NET: clap:

Это немного выходит за рамки темы , но https://stackoverflow.com/questions/51123289/how-to-generate-a-response-to-a-csr- in-net-core-ie-to-write-a-csr-signed-se. .NET Core 2.0 также включает другие средства для создания сертификатов и работы с ними. См. Также комментарии о запуске центра сертификации. Инструменты библиотеки почти есть, и в зависимости от вашей организации вы можете каким-то образом контролировать сертификаты на каком-то сервере, не устанавливая много внутренней структуры. На этом токене чтение (в кодировке DER) запросов на подпись сертификатов (CSR) из коробки было бы хорошим дополнением - вместе с библиотекой JSON-LD. И еще криптовалюта в целом. :)

Мне бы хотелось увидеть промежуточное ПО, такое как поддержка LetsEncrypt - работа со службами приложений в Windows, Linux и Docker в Azure.

@kieronlanning Я согласен, в дополнение к кодировке DER в отношении подписания CSR, упомянутого ранее (хотя добавление поддержки без крайних случаев не выглядит таким сложным). Есть несколько библиотек для .NET (также перечисленных на страницах Let's Encrypt), но также есть небольшие проблемы. Например, наиболее активно поддерживаемый .NET в отношении Let's Encryptc выглядит как Certes , но требует зависимости от BouncyCastle . Было бы неплохо, если бы кто-то помог ему стать только .NET Standard 2.0. Одна из причин для меня в том, что BouncyCastle плохо работает с Orleans TaskScheduler . :)

Что касается упоминания криптовалюты, хотя это и не является строго проблемой ASP.NET Core, MS, по-видимому, сильно продвигает блокчейны, но .NET не хватает криптостойкости. _На первый взгляд_ многое из этого также связано с ядром ASP.NET (например, с различными реализациями проводника блокчейна, такими как https://etherscan.io/), и было бы неплохо иметь больше поддержки для библиотеки, такие как Inferno, и просто дополнительные возможности, встроенные в платформу. Одна нерешенная проблема находится на https://github.com/sdrapkin/SecurityDriven.Inferno/issues/10#issuecomment -395778931 (если кто-то хочет помочь).

Это от @kieronlanning будет моим запросом функции номер один:

«Я бы хотел увидеть промежуточное ПО, например, поддержку LetsEncrypt».

Вот открытый вопрос: https://github.com/aspnet/Home/issues/1190. Пожалуйста, идите и проголосуйте за это.

Считается ли пакет сообщений доступным в ядре asp.net для всех фреймворков, а не только в SignalR? Поскольку кадрирование Http2 является двоичным, рассматриваете ли вы для этого пакет сообщений?

сервер авторизации выпущен на preview3?

Он уже существует. Https://IdentityServer.io

@leastprivilege
Мне нравится и использую IdentityServer
Но мне очень любопытно увидеть реализацию Microsoft и понять, почему (Microsoft) не включила сервер идентификации в ваше ядро.

@ danroth27 - можешь поделиться последними?

Microsoft использует IdentityServer.

Так как это работает? Microsoft напрямую использует код IDS4? Microsoft сокращает возможности IDS4? Какая здесь модель? Каковы должны быть наши ожидания? Есть ли возможный путь миграции между ними?

Microsoft будет использовать наш стандартный пакет nuget и использовать наш API конфигурации, чтобы предоставить вам некоторые настройки по умолчанию, чтобы хорошо работать с шаблоном и идентификатором ASP.NET. Это все.

Вы можете добиться того же уже сегодня.

Вероятно, это я, но я с удивлением прочитал, что пробел в сервере авторизации Microsoft заполняется IdentityServer4. Насколько я понимаю, основной задачей IdentityServer является аутентификация, а не авторизация.

Для меня IdentityServer подходит как сервер аутентификации, но не работает как сервер авторизации. Я предположил, что это было причиной создания PolicyServer.

@leastprivilege Будет ли IdentityServer расширен чем-то вроде PolicyServer?

@Ruard Так что это сбивает с толку (и Доминик, вероятно, съежится или придет к моему объяснению).

OAuth - это аутентификация, но он имеет авторизацию на первом этапе, а затем выдает грант на основе областей и т. Д. Итак, в нашей упаковке Identity Server выполнит вход, подтвердит его, подтвердит требуемые области (что в первоначальном случае будет всегда успешно, потому что мы используем область действия по умолчанию), затем передаем токен обратно вызывающей стороне, который затем отправляется в API, который будет его проверять, а затем, при желании, вы можете пойти дальше с правилами авторизации в API. OIDC предоставляет OIDC, что еще больше запутало его, поскольку это способ получить идентификационную информацию пользователя, включая разрешение на то, что приложению разрешено ее иметь ...

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

@MichelZ будет история взросления. Мы настроим простые сценарии, и как только вы выйдете за рамки этих сценариев, вы сможете изучить всю мощь модели конфигурации IdentityServer.

@blowdart Мы уже используем IdentityServer (и впечатлены возможностями!), однако получение выгоды от политики «долгосрочной поддержки» Microsoft также является для нас большим плюсом. Так что любые возможности взаимодействия, которые вы можете здесь предоставить, очень приветствуются.
Нам одинаково нравятся оба продукта, ASP.NET Core и IdentityServer (4). ИМХО, это определенно шаг в правильном направлении.
Однако мы также понимаем, что все эти протоколы не совсем «прямые». Это не ракетостроение, как вы их понимаете, но все же они не прямолинейны.

Я бы хотел, чтобы кто-нибудь изобрел ДЕЙСТВИТЕЛЬНО простой протокол, оставив позади ВСЕ устаревшие реализации и сосредоточившись на будущем.

Если вы уже используете его, то ваше использование практически не изменится, оно у вас работает :)

Мы стремимся к созданию файла> Веб-API с индивидуальной аутентификацией, а затем добавляем другие API, и все основано на соглашениях. Это не сработает для существующих приложений, потому что соглашения будут новыми. Я бы не стал заменять ваш конфиг на наш :)

Я бы хотел, чтобы кто-нибудь изобрел ДЕЙСТВИТЕЛЬНО простой протокол, оставив позади ВСЕ устаревшие реализации и сосредоточившись на будущем.

В этом проблема - приложения усложняются не меньше. Чтобы обезопасить их, также усложняется безопасность. Я всегда сопротивлялся, когда слышал, как люди говорят, что IdentityServer сложен, но это не так. Сложны требования к безопасности вашего приложения. Часто люди не имеют возможности осознать это.

Да, он работает - и он работает хорошо - но все же эта дополнительная гарантия, которую он (может) дать вам, когда Microsoft официально «одобряет» и в конечном итоге «поддерживает» технологию, - чистое золото ....!
Вы поднялись на совершенно новый уровень!

@brockallen Да, приложения, вероятно,

Я не говорю, что то, что у нас есть сейчас, «плохо», я действительно ценю то, что у нас есть, и это действительно функционально для наших целей, и я надеюсь, что все, кто участвовал в его создании, гордятся своей работой!

@Команда;
Для предварительного просмотра 3 не могли бы вы предоставить некоторые подробные документы о «Сервере авторизации» и о том, как он будет работать с веб-API и JS на стороне клиента, например Vue?
Нам нужно принять решение, и этот предварительный просмотр на сервере авторизации является важным предварительным просмотром, и любые подробные документы предоставят нам информацию о нашем решении.

Спасибо!

Как обсуждалось ранее

https://identityserver.io

Только что заметил, что API открытых данных США находятся в JSON-LD: https://project-open-data.cio.gov/v1.1/schema/. Похоже, это быстрорастущая тенденция, поэтому было бы неплохо использовать хорошо оснащенную библиотеку JSON-LD .NET, используемую с ASP.NET. :)

@veikkoeeva Таковы (по крайней мере, часть) API NuGet. Они используют json-ld.net , нет необходимости в другой библиотеке.

@khellang Есть и другие библиотеки, эта конкретная библиотека может использовать сопровождающих (https://github.com/linked-data-dotnet/json-ld.net/issues/26). Я понимаю, что это открытый исходный код, и теоретически я мог бы вмешаться, чтобы внести свой вклад, но пока, по крайней мере, я слишком разбросан, чтобы помочь с этим. Другими словами, возможно, я хотел бы обратить внимание на то, что многие наборы данных, похоже, движутся в сторону семантических форматов, и неясно, как эффективно работать с ними, используя .NET.

IMHO, добавлять IdentityServer4 в ядро ​​ASP.Net Core - плохая идея.
Пожалуйста, не превращайте .NetCore в монолитный фреймворк.
Есть .NetCore и есть IdentityServer4, люди создают архитектуру на основе собственных требований аутентификации и авторизации.

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

Вы по-прежнему не можете его использовать, и это не повлияет на вас. Вы по-прежнему можете использовать IdSrv и полностью настроить его самостоятельно. Вы по-прежнему можете выбрать, какие компоненты включить в свой проект. Ничто из этого не делает ASP.NET Core монолитным.

ASP.NET Core! = .NET Core, кстати.

Будет ли 2.2 выпуск LTS? (Спрашивать, было ли это уже объявлено, а не просить вас сделать новое объявление.)

@yzorg ни о чем не сообщалось. Это определение часто делается после выпуска на основе качества / стабильности.

@blowdart , будет ли этот шаблон предоставлять серверу удостоверений клиент MVC веб-приложения вместо API?

@Ponant Нет. Он предназначен только для API. Мы пересмотрим это на временной шкале 3.x.

Интересно ... Этот вопрос возник вчера на встрече. Если мы создадим полный проект «MVC» без использования веб-API, сможем ли мы использовать новый шаблон ASP.Net 2.2 IS4, интегрированный в 2.2?
Похоже, большой босс (Барри) только что ответил на вопрос.

@blowdart allias big boss: почему это не делается одним выстрелом? На первый взгляд кажется тривиальным использовать клиент mvc или веб-api для связи с сервером IS4 основной идентификации asp.net.

@Ponant Потому что у нас нет бесконечных ресурсов. Какие функции вы бы хотели, чтобы мы отказались от нас, чтобы заставить всех изменить основную часть потока MVC, которая не даст никаких новых функций, а просто изменит работу существующей? Отдельный API с проверкой подлинности был разрывом между полной платформой и ASP.NET Core. Основная работа была направлена ​​на восполнение этого пробела. Identity Server уже имеет рабочие шаблоны для MVC с Identity Server в качестве «ядра».

@CrispinH @blowdart Я полностью с вами согласен. Администрирование пользователей, роли, аренда и группы пользователей крайне необходимы. Посмотрите на это - есть 7 билетов Uservoice, все жалуются на сотни разработчиков и компаний. К сожалению, многие другие технологии, такие как портал Java blueRay JSR 182 или 173, здесь такая прекрасная работа!

-> Так много запросов на управление пользователями / группами / арендаторами

-> СНОВА здесь люди жалуются ... это продолжается, даже в твиттере и фейсбуке ... это причина - почему другие платформы, такие как WP и PHP, проще!

Хотя @manigandham считает, что сервер идентификации отлично подходит, они БЕСПЛАТНО берут плату за инструмент администрирования с графическим интерфейсом, и это недешево для многих стран и разработчиков, а также противоречит низкой совокупной стоимости владения для разработчиков. Сколько людей действительно могут себе это позволить. Это было ОГРОМНОЕ препятствие и шаг назад, необходимы базовые функциональные возможности и графический интерфейс для управления пользователями / ролями / ролями-пользовательскими_группами / арендаторами , которые затем могут быть улучшены разработчиком.

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

@papyr @poke нет необходимости в новом проекте с открытым исходным кодом, есть отличные существующие проекты.

Если вы хотите что-то с открытым исходным кодом от MS, предназначенное для конкуренции с WordPress, посмотрите на Orchard:
https://github.com/OrchardCMS/OrchardCore

Если вам нужен более библиотечный подход вместо инфраструктуры, обратите внимание на cloudcribe, в котором есть nugets для мультитенантности и пользовательского интерфейса, а также пользовательский интерфейс управления ролями и утверждениями, предварительно созданный с дополнительной интеграцией identityserver4 и дополнительным cms (cloudcribe.Simple / content) as дополнительные nugets.
https://www.cloudscribe.com/docs/introduction
https://github.com/cloudscribe/cloudscribe
https://github.com/cloudscribe/cloudscribe.SimpleContent

Если вы хотите что-то с открытым исходным кодом от MS, предназначенное для конкуренции с WordPress, посмотрите на Orchard:
https://github.com/OrchardCMS/OrchardCore

Я поддерживаю эту рекомендацию.

И Orchard Core спроектирован так, чтобы быть чрезвычайно модульным. Например, можно извлечь только его мультитенантный модуль и использовать его в своих собственных проектах . В нем также уже есть модули для управления пользователями и ролями, и я уверен, что они оценят ваш вклад, чтобы сделать его еще лучше.

Вы можете посмотреть множество демонстраций его различных функций на их канале .

@papyr Почему бы вам просто не начать для этого проект с открытым исходным кодом?

https://github.com/IdentityManager/IdentityManager2

Эта штука с пользовательским интерфейсом может быть сложной, хотя и полезной для быстрого получения базовых вещей. Кажется, в последнее время я сталкивался со случаями, когда создание пользовательского интерфейса - не самая большая задача, но выяснение того, как удовлетворить «потребности процесса», такие как предварительное одобрение некоторых электронных писем (которые делают что-то конкретное для приложения), вызов API-интерфейсов, которые вызывают API-интерфейсы. , некоторые из которых могут означать присоединение к базе данных или вызовы в другое место и т. д., а затем добавление их к токенам и логике пользовательского интерфейса.

Поэтому наличие хороших руководств, таких как https://mcguirev10.com/2018/01/28/login-identity-management-best-practices.html или https://mcguirev10.com/page2/, кажется более важным, чем UI ( особенно если вы не можете или не хотите использовать EF). Затем, возможно, поиск пользовательского интерфейса для выбранной технологии (Aurelia / Angular / Razor / React / Vue и т. Д.) И того, как они реализуют некоторую обработку данных.

Что касается именования проектов и имен, помимо полезным проверить https://github.com/abergs/fido2-net-lib ( @abergs , @aseigler), @TomCJones , @ mackie1001 (Gitter) и т. Д., Чтобы предоставить дополнительные объяснения и код, в который можно заглянуть при выходе даже немного за пределы основной потребности. Я забыл добавить несколько имен и проектов. :)

Почему не может .net core иметь нормальные веб-страницы бритвы? Когда я делаю сложные отчеты, мне нравится делать все на одной странице (c #). Или, по крайней мере, возможность использовать только представление время от времени только без модели или контроллера.

Другими словами, базовая возможность подключаться к sql в представлении и получать запросы GET и POST, очищенные, конечно, в настоящее время я использую класс под названием Striptag.cs.

Почему не может .net core иметь нормальные веб-страницы бритвы?

Вы можете использовать для этого страницы Razor https://docs.microsoft.com/en-us/aspnet/core/razor-pages/?view=aspnetcore-2.1&tabs=visual-studio

Наличие класса модели вспомогательной страницы необязательно; у вас может быть только одна страница

benaadams, спасибо за ответ, как мне использовать запросы GET и POST непосредственно на странице бритвы и выполнить базовое подключение к серверу sql. Соединение для обычных запросов, а не для ado-сущностей, linq или ORM. Я всегда предпочитаю обычные запросы.

Нравиться:

var msql = "SELECT * FROM customerss WHERE lastname LIKE <strong i="7">@0</strong> ORDER BY lastname OFFSET " + thisoffset + " ROWS FETCH NEXT 5 ROWS ONLY";

Я знаю, что строка подключения сейчас находится в файле json, но не знаю, как ее использовать. Некоторые вещи глубоко не задокументированы.

Что ж, у этого есть кривая обучения. Если вы хотите получить данные _ перед_ загрузкой представления, вы делаете это в соответствующем действии. Итак, для HomeController.ViewReports action и Views/Home/ViewReports.cshtml page вы пишете:

public class HomeController
{
  public ActionResult ViewReports()
  {
    // fetch data from the SQL using...something...
    return View(data);
  }
}

Если вы хотите получить данные _после_ загрузки страницы, вы обычно используете запросы AJAX к какой-то чистой конечной точке GET / POST, которая возвращает данные в формате JSON.

Все еще может делать это на странице без какого-либо контроллера или действия; что-то вроде

<strong i="6">@page</strong>
<strong i="7">@using</strong> System.Data.SqlClient
<strong i="8">@using</strong> Microsoft.AspNetCore.Http
<strong i="9">@using</strong> Microsoft.Extensions.Configuration
<strong i="10">@inject</strong> IConfiguration Configuration

@{
    var lastname = Request.Query["lastname"];
    if (!string.IsNullOrEmpty(lastname))
    {
        var offset = 0;
        var count = 5;
        if (Request.Method == HttpMethods.Post)
        {
            int.TryParse(Request.Form["offset"], out offset);
            int.TryParse(Request.Form["count"], out count);
            count = Math.Min(count, 50);
        }

        var connectionString = Configuration.GetConnectionString("MyConnectionString");
        using (var conn = new SqlConnection(connectionString))
        {
            using (var cmd = new SqlCommand(@"
            SELECT * FROM customers
            WHERE lastname LIKE <strong i="11">@lastname</strong>
            ORDER BY lastname
                OFFSET (@offset) ROWS
                FETCH NEXT (@count) ROWS ONLY"))
            {
                cmd.Parameters.AddWithValue("@lastname", lastname);
                cmd.Parameters.AddWithValue("@offset", offset);
                cmd.Parameters.AddWithValue("@count", count);

                await conn.OpenAsync();
                using (var reader = await cmd.ExecuteReaderAsync())
                {
                    while (await reader.ReadAsync())
                    {
                        <div>@reader["lastname"]</div>
                    }
                }
            }
        }
    }
    else
    {
        <div>Nothing chosen</div>
    }
}

Я использовал mvc asp.net и веб-формы и старые страницы бритвы, поэтому я не новичок в этом. Я провел 3 часа и все еще не могу заставить работать простую тестовую страницу бритвы, у меня есть:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title></title>
</head>
<body>
    <form id="petform" method="post" action="pets/razdb3">
        <input type="text" name="psearch" id="psearch" />
        <input type="submit" />
    </form>

</body>
</html>

Просто страница html и загружается.

Модель

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.RazorPages;

namespace petnewtry.Pages.pets
{
    public class razdb3Model : PageModel
    {
        public string myvar { get; set; }

        public void OnGet()
        {

        }

        public void OnPost()
        {
            myvar = Request.Form["psearch"];
        }
    }
}

Вид:

<strong i="13">@page</strong>
<strong i="14">@model</strong> petnewtry.Pages.pets.razdb3Model
@{
    Layout = null;
}

<!DOCTYPE html>

<html>
<head>
    <meta name="viewport" content="width=device-width" />
    <title>razdb3</title>
</head>
<body>
    <div>@Model.myvar</div>
    <div>hello</div>
</body>
</html>

3 часа, и все, что я получаю, - это пустая страница. Я пробовал заявление о возврате и т. Д.

Если я просто наберу http: // localhost : 51307 / pets / razdb3, я получу второе деление «привет», но
the @ Model.myvar я ничего не получаю.

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

В сообществе VS 2017

the @ Model.myvar я ничего не получаю.

Вы устанавливаете значение myvar в почтовом запросе ( OnPost ) с помощью значения формы psearch ; так что вам нужно будет сделать запрос POST с этим значением, чтобы установить его?

В запросе GET ( OnGet ), который вы получаете, просто переходя по URL-адресу из браузера; вместо обратной передачи формы ничего не устанавливается.

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

public string myvar { get; set; } = "Not Set";

Изменился на

public string myvar { get; set; } = "Not Set";

И все еще пустая страница. Правильно ли @ Model.myvar?

даже изменился на

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.RazorPages;

namespace petnewtry.Pages.pets
{
    public class razdb3Model : PageModel
    {
        [BindProperty]
        public string psearch { get; set; }

        public void OnGet()
        {

        }

        public void OnPost(string psearch)
        {
            psearch = Request.Form["psearch"];
        }
    }
}

<strong i="12">@page</strong>
<strong i="13">@model</strong> petnewtry.Pages.pets.razdb3Model
@{
    Layout = null;
}

<!DOCTYPE html>

<html>
<head>
    <meta name="viewport" content="width=device-width" />
    <title>razdb3</title>
</head>
<body>
    <div>@Model.psearch</div >
        <div>hello</div>
</body>
</html>

Он строит нормально, без ошибок, но с пустой страницей, что бы я ни пытался.

Вежливые комментарии / мысли: кажется, что это обсуждение на "обычных страницах бритвы" начинает немного отклоняться от темы по отношению к теме этой ветки.

😊 😊

Извините, я понимаю, что мне следовало использовать форум. Спасибо @benaadams, ваш код

https://www.c-sharpcorner.com/article/razor-page-web-application-with-asp-net-core-using-ado-net/

В любом случае я обычно так поступал, используя "новое" ключевое слово, например

EmployeeDataAccessLayer objemployee = new EmployeeDataAccessLayer();

Было обнадеживающе видеть, что вы все еще можете использовать пользовательские классы в ядре .NET.

Вы должны признать, что ядро ​​.net требует более крутого обучения, чем некоторые предыдущие фреймворки asp.net. Огромное спасибо.

В примечаниях к выпуску говорится о функции «Сервер авторизации», которую следует ожидать в качестве надстройки в ближайшие месяцы. Есть ли дополнительная информация об этой функции? Я пытаюсь решить, стоит ли его ждать. Или создайте собственное решение.

В примечаниях к выпуску говорится о функции «Сервер авторизации», которую следует ожидать в качестве надстройки в ближайшие месяцы. Есть ли дополнительная информация об этой функции? Я пытаюсь решить, стоит ли его ждать. Или создайте собственное решение.

Я думаю, что текущий план состоит в том, чтобы использовать https://github.com/IdentityServer/IdentityServer4 "заранее упакованным" способом.

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

Я надеюсь, что полная интеграция между IS4 и ASP обеспечит поддержку ОБЕИХ веб-API и MVC.

В наши дни аутентификация / авторизация промышленных мощностей требуется как минимум. Открытый исходный код (OSS) подходит для большинства вещей, но были серьезные опасения в отношении некоторых продуктов безопасности OSS, которые неприемлемы на любом корпоративном веб-сайте. 85% проектов используют устаревшие библиотеки, представляющие неприемлемый риск для безопасности. Например, 45% веб-серверов используют Apache (https://www.cvedetails.com/vendor/45/Apache.html), который имеет гораздо больше уязвимостей, чем IIS (https://www.cvedetails.com/product/3436/ Microsoft-IIS.html? Vendor_id = 26). Такие продукты, как Identity Server, могут подойти, но настройки разработчика могут сделать их полностью небезопасными. Нам нужно решение, встроенное в Net Core, которое всегда безопасно ...

В наши дни аутентификация / авторизация промышленных мощностей требуется как минимум. Открытый исходный код (OSS) подходит для большинства вещей, но были серьезные опасения в отношении некоторых продуктов безопасности OSS, которые неприемлемы на любом корпоративном веб-сайте. 85% проектов используют устаревшие библиотеки, представляющие неприемлемый риск для безопасности. Например, 45% веб-серверов используют Apache (https://www.cvedetails.com/vendor/45/Apache.html), который имеет гораздо больше уязвимостей, чем IIS (https://www.cvedetails.com/product/3436/ Microsoft-IIS.html? Vendor_id = 26). Такие продукты, как Identity Server, могут подойти, но настройки разработчика могут сделать их полностью небезопасными. Нам нужно решение, встроенное в Net Core, которое всегда безопасно ...

Ваша точка зрения абсолютно верна. Но в некоторых видеороликах сотрудники MS сказали, что они не собираются изобретать колеса [безопасности] и использовать стороннюю систему [IS4]. Так что я надеюсь, что это будет беспроигрышная ситуация для всех нас.

В наши дни аутентификация / авторизация промышленных мощностей требуется как минимум. Открытый исходный код (OSS) подходит для большинства вещей, но были серьезные опасения в отношении некоторых продуктов безопасности OSS, которые неприемлемы на любом корпоративном веб-сайте. 85% проектов используют устаревшие библиотеки, представляющие неприемлемый риск для безопасности. Например, 45% веб-серверов используют Apache (https://www.cvedetails.com/vendor/45/Apache.html), который имеет гораздо больше уязвимостей, чем IIS (https://www.cvedetails.com/product/3436/ Microsoft-IIS.html? Vendor_id = 26). Такие продукты, как Identity Server, могут подойти, но настройки разработчика могут сделать их полностью небезопасными. Нам нужно решение, встроенное в Net Core, которое всегда безопасно ...

Нет ничего "всегда безопасного", особенно от Microsoft;)
Изготовить и сохранить в безопасности всегда в руках пользователя этих вещей.

IdentityServer будет включен в новую рассылку шаблонов 2.2. Первоначально основное внимание будет уделяться контролю доступа к API, но в будущем его планируется расширить.

ASP.NET Core будет поставляться с упрощенным API конфигурации, который охватывает только сценарии шаблонов, но будет очень легко начать работу. Вы можете в любой момент перейти к собственной системе конфигурации IS, которая предоставляет вам расширенные сценарии.

IdentityServer будет включен в новую рассылку шаблонов 2.2. Первоначально основное внимание будет уделяться контролю доступа к API, но в будущем его планируется расширить.

ASP.NET Core будет поставляться с упрощенным API конфигурации, который охватывает только сценарии шаблонов, но будет очень легко начать работу. Вы можете в любой момент перейти к собственной системе конфигурации IS, которая предоставляет вам расширенные сценарии.

Спасибо за информацию Доминик;
Я считаю, что эта «ступенька» поможет многим начать работу, а затем перейти к полной IS. Хороший ход.

IdentityServer будет включен в новую рассылку шаблонов 2.2. Первоначально основное внимание будет уделяться контролю доступа к API, но в будущем его планируется расширить.

ASP.NET Core будет поставляться с упрощенным API конфигурации, который охватывает только сценарии шаблонов, но будет очень легко начать работу. Вы можете в любой момент перейти к собственной системе конфигурации IS, которая предоставляет вам расширенные сценарии.

Хорошо знать! Спасибо.

Я предполагаю, что этот контроль доступа к API будет основан на областях действия OAuth?
Нет прямой поддержки более изменчивых разрешений пользователей, как описано на policyserver.io?

IdentityServer будет включен в новую рассылку шаблонов 2.2. Первоначально основное внимание будет уделяться контролю доступа к API, но в будущем его планируется расширить.
ASP.NET Core будет поставляться с упрощенным API конфигурации, который охватывает только сценарии шаблонов, но будет очень легко начать работу. Вы можете в любой момент перейти к собственной системе конфигурации IS, которая предоставляет вам расширенные сценарии.

Хорошо знать! Спасибо.

Я предполагаю, что этот контроль доступа к API будет основан на областях действия OAuth?
Нет прямой поддержки более изменчивых разрешений пользователей, как описано на policyserver.io?

PolicyServer - коммерческое решение

Я предполагаю, что этот контроль доступа к API будет основан на областях действия OAuth?
Нет прямой поддержки более изменчивых разрешений пользователей, как описано на policyserver.io?

«Только» IdentityServer. ASP.NET Core имеет встроенный API для авторизации пользователей - и если PolicyServer (продукт) вам интересен, дайте мне знать.

Закрытие этой проблемы, поскольку уже выпущен ASP.NET Core 2.2.

если это не будет обновлено до ASP 3.0

Есть какие-нибудь новости о том, когда будут выпущены усовершенствования сервера авторизации?