¿Qué pasa con EF Core 2.2 Roadmap?

¿Qué pasa con EF Core 2.2 Roadmap?

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

La hoja de ruta se ve bien, en particular las comprobaciones de estado y HTTP 2.0. Sin embargo, de la manera más amable posible , no estoy de acuerdo con la necesidad de construir un servidor de autorización de Microsoft de primera parte simple. IdentityServer4 llena este vacío muy bien y el tiempo invertido en volver a implementar una versión más simple podría emplearse mejor en otra parte. Entiendo que el objetivo es proporcionar una solución simple, pero la autenticación es difícil e IdentityServer proporciona una API que es tan simple como parece. Si hay ideas para una abstracción más simple, podría construirse sobre IdentityServer para que las personas puedan usar la abstracción simple pero tengan el poder si lo necesitan.

Actualizar

En el standup de la Comunidad ASP.NET, se mencionó que el equipo de ASP.NET Core está hablando con el equipo de Identity Server sobre las opciones, incluida la construcción de algo sobre Identity Server. Creo que eso es lo que todos queremos, ¡bien hecho!

¿Cuáles son los planes actuales de ASP.NET Core WebHooks ?

En cuanto al despachador, ¿será esto posible entonces en el middleware? 😱
C# public async Task Invoke(HttpContext context, [FromRoute] SomeModel someModel)
^[FromQuery]?

Servidor de autenticación simple, pero también recuerda lo que sucedió con el servidor de autenticación simple de Katana

Quiero hacerme eco de las preocupaciones de @ RehanSaeed y me gustaría pedir algunas aclaraciones sobre qué casos de uso exactos se supone que debe llenar este nuevo servidor. Si esto es principalmente para que las API web tengan una forma de obtener su token de portador que sea válido dentro de la autenticación existente de la aplicación, entonces estaría bien. Pero todo lo demás probablemente sea mejor dejarlo en manos de las soluciones existentes que ya ofrecen muchas opciones de diferente complejidad y flexibilidad con productos como IdentityServer, OpenIddict y AspNet.Security.OpenIdConnect.Server.

¿Qué pasa con el alojamiento en proceso de IIS ?

¿Podría dar más detalles sobre la parte de TypeScript de "Generación de clientes API (C # y TypeScript)"?

Esto sería realmente algo que esperaría con ansias. Actualmente estoy usando NSwag para generar automáticamente mis servicios de API de cliente Angular. Pero hay tantas combinaciones diferentes posibles para las configuraciones del cliente que creo que esto podría ser problemático para complacer a todos.

En la parte superior de mi cabeza, algo que debería ser considerado (y si es posible debería ser configurable):

• ¿Solo un cliente de TypeScript con fetch o un servicio angular con HttpClient?
• Si es Angular, ¿qué versiones son compatibles (también es importante para RxJS)?
• manejo nulo / indefinido
• manejo de enumeración
• JS date o momentjs para tipos de fecha?
• Manejo de excepciones, manejo de errores de validación
• ¿Cómo extender el código generado en el cliente?
• Posibilidad de influir en la generación de nombres (por ejemplo, eliminar la parte DTO de xxxDTO para las clases de cliente generadas o ya en la definición de OpenAPI)

Si fuera posible votar por funciones, estas mejoras / correcciones para el middlware existente estarían en mi lista de deseos:

• Permite que Encrypt sea compatible con https://github.com/aspnet/Home/issues/1190.
• El middleware Response Cache básicamente no se puede utilizar como lo es hoy. Agregar un almacén de caché de respuestas de Redis y la extensibilidad para las operaciones de usuario de las respuestas en caché debería resolver https://github.com/aspnet/Home/issues/2606.
• Admite la publicación de archivos codificados pre-GZIP y pre-BR .
• Agregue un proveedor de compresión Brotli y solucione varios problemas con el middleware de compresión de respuesta.

También voto para omitir el producto Authorization Server. La seguridad es complicada y ha habido un gran impulso para pasar a los servicios en la nube para eliminar el mantenimiento, y cualquiera que quiera más control ya puede usar IdentityServer4, que está bien construido, probado, documentado y respaldado. Una configuración simple toma 5 minutos y tienen muchas muestras de inicio, videos y tutoriales.

No veo cómo se puede hacer que la seguridad funcione como "configuración cero" más de lo que ellos pueden. Parece que esto solo agregará más confusión (en el nombre y el uso), al tiempo que se convertirá en otra cosa más para respaldar y mantener durante años, lo que le quitará el esfuerzo a otras funciones continuamente. Por favor reconsidere esto.

También tengo curiosidad por saber por qué el alojamiento en proceso de IIS no está en esta hoja de ruta 2.2. Esta es una característica importante y es un factor importante en nuestra estrategia de liberación y horarios aquí en desbordamiento de pila y que ya se había eliminado último minuto antes de la liberación 2.1, con la promesa de un plazo 2.2 lugar . Por favor, dígame que esto es solo un descuido y no otro cambio de plan.

Editar: @DamianEdwards respondió en Twitter que esto fue realmente un descuido (lo que significa que está planeado para 2.2). ¡Uf!

Me haré eco de otros comentarios. Si va a invertir en Autorización / Política, específicamente para simplificarlo, personalmente preferiría ver una asociación con empresas como OpenIddict e IdentityServer en documentos e inversiones en andamios. No puedo evitar sentir que cualquier trabajo, no importa cuán simple sea, simplemente terminará duplicando esfuerzos fabulosos de terceros e incurriendo en un costo de mantenimiento innecesario en el equipo de aspnet.

Tal vez sea una vista impopular, pero me gustaría ver un servidor de autenticación de Microsoft, uno que esté construido para el público, con nuestro aporte y apoyo.

Los actuales, Id4, OpenIddict, son obviamente excelentes proyectos de OSS, y no puedo evitar sentir que uno con el apoyo de MS podría ser algo malo ...

Existe un límite en la cantidad de soporte disponible de un pequeño grupo de personas, y estos son productos de misión crítica después de todo.

Creo que es una lástima que el Código de conducta de MS OSS no incluya una línea que diga "No promocione funciones que dupliquen algo que se puede incorporar con una solicitud de Nuget y que casualmente aplastará un negocio de dos personas que contribuye a nuestro ecosistema ".

El cínico que hay en mí no puede evitar preguntarse si, para algunos conocedores, darles a Brock y Dominick una nariz ensangrentada era una característica de esta sugerencia en lugar de un error. ¿Es esto lo que les sucede a las pequeñas empresas que alguna vez han tenido la osadía de criticar cualquier cosa que haga el equipo de ASP?

También me pregunto qué hay de duplicar la funcionalidad de autenticación además de crear algo en la parte superior, como las interfaces de usuario y la documentación.

Además, una biblioteca JSON-LD 1.1 bien probada sería una buena adición específica a la hoja de ruta. :)

Repitiendo lo que otros han dicho: preferiría ver el trabajo de autorización traído de algo como IdentityServer4 que implementado de nuevo por ustedes mismos. Si hay brechas, seguramente cerrarlas a través de contribuciones, muestras y refinar los puntos de integración sería una mejor manera de hacerlo. Quizás también preste atención a su oferta de nube en este espacio (B2C) que se encuentra en un estado terrible.

Más allá de eso, si bien dice que el objetivo no es replicar la funcionalidad en las ofertas de código abierto existentes y mantener las cosas simples, esto es algo equivalente a la clásica trampa de reescritura: "esta solución es demasiado compleja y un poco desordenada, ¡reescribámosla! ". Es ingenuo y, en el tiempo de n versiones, apostaría dinero a que se haya ocupado de los muchos casos extremos que requieren las soluciones del mundo real y que algo como IdentityServer ya está tratando.

En términos más generales, con la adquisición de GitHub, ha habido mucha discusión recientemente sobre la actitud de Microsoft hacia el código abierto. Es fantástico que Microsoft esté haciendo tanto trabajo al aire libre, pero parte de ser un buen ciudadano del código abierto es aprovechar el código abierto existente cuando existe.

Esto es particularmente importante para los titulares de plataformas como ustedes: un titular de plataforma que duplica la funcionalidad en las ofertas de código abierto existentes _desalienta_ las contribuciones mientras se compromete con esas ofertas _alienta_ las contribuciones.

Yo tampoco veo el punto de esfuerzo que se está gastando en la autorización, pero me gustaría ver la _gestión_ de ASP.NET Core Identity mejorada. Damian Edwards fue bastante claro en live.asp.net que no deberíamos implementar nuestra propia seguridad pero, a menos que me lo haya perdido, ASP.NET Core Identity no contiene ninguna herramienta de administración de usuarios y, por lo tanto, tenemos que hacerlo. nuestra propia. Esto me parece un poco aterrador, ya que no soy un experto en seguridad y tengo un miedo mortal de dejar un agujero de seguridad que yo mismo he creado.

¿Qué tal mover los formateadores de contenido del nivel MVC a las abstracciones AspNetCore.Http en 2.2?

Tal vez el PM responsable podría redactar una descripción más detallada de este Identity Server Lite para aclarar exactamente qué deficiencias en las soluciones de código abierto de terceros existentes que el equipo ASP.NET está buscando abordar. Porque tal como está, estás hablando de reinventar una rueda pero quizás quitar algunos radios, y eso no tiene mucho sentido. Como alguien más ha dicho, arreglar AAD B2C y proporcionar una integración de primera clase con eso sería genial y tendría sentido comercial para MS.

Además, ¿ha considerado siquiera lo difícil que será obtener un nuevo producto de servidor de autenticación basado en cero más allá de @blowdart?

¿Algún plan para tener una API RESTful integrada como la que tiene django?
¡Porque es algo que todos los desarrolladores tienden a escribir todo el tiempo!

Recientemente construí algo que podría escribirse como un controlador de API RESTful genérico:

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

También estoy de acuerdo con "No veo cómo se puede hacer que la seguridad funcione como" configuración cero "más de lo que ellos pueden" y "estás hablando de reinventar una rueda, pero tal vez eliminar algunos radios", el servidor de identidad es un producto increíble, muy es fácil de comenzar y proporciona extensibilidad para escenarios más complicados, no estoy seguro de por qué necesitamos una versión "simplificada".

En una escala mucho más pequeña, ¿por qué necesitamos otra implementación de chequeo de salud? Ya existen varias soluciones de código abierto, p. Ej.

• https://github.com/Xabaril/BeatPulse , incluye un montón de cheques escritos previamente e incluso viene con una interfaz de usuario
• https://www.app-metrics.io/web-monitoring/aspnet-core/health/

¿Cuál será la diferencia de características con estos y qué se proporciona en 2.2?

@ 0xRumple Las mejoras en ApiController deberían ayudar a que esto sea menos detallado en general. Pero no, probablemente no verá algo que solo le brinde una API CRUD para sus entidades de forma predeterminada. Tal cosa tendría que hacer demasiadas suposiciones sobre su DAL y autorización.

Si sigue ciertos patrones en su aplicación, no hay nada de malo en crear sus propios tipos base o convenciones en 2.2 que generalizarán el trabajo para usted.

@kieronlanning

Los actuales, Id4, OpenIddict, son obviamente excelentes proyectos de OSS, y no puedo evitar sentir que uno con el apoyo de MS podría ser algo malo ... Existe un límite en la cantidad de soporte disponible de un pequeño grupo de personas, y estos son productos de misión crítica después de todo.

Desde que preguntaste si podría ser algo malo:

El equipo de ASP.NET también es relativamente pequeño y atiende a millones de desarrolladores con capacidad limitada, por lo que cualquier proyecto nuevo le quitará tiempo y esfuerzo a otras cosas. Significa que todos tenemos que esperar más para obtener funciones nuevas que probablemente ofrezcan más valor.

Mucho peor es que daña el ecosistema de terceros y desalienta nuevos productos debido a que Microsoft lanza un paquete "oficial", que muchas empresas se quedan atascadas eligiendo solo porque es de Microsoft, incluso si técnicamente (y en este caso se supone que es) menos capaz. ASP.NET ya integra Json.NET, Polly, AutoMapper y muchas otras bibliotecas, por lo que parece un paso en falso reconstruir un producto de seguridad tan complejo (que necesitará el 80% del mismo código base) cuando ya existen excelentes opciones, y con muchas más cosas interesantes en la hoja de ruta en las que trabajar.

@dar un toque
Tienes razón, escribir clases base de mis aplicaciones es una buena idea.

En realidad, creo que esas no están dentro de las responsabilidades del marco:

CRUD resources (repository responsibility)

Manipulating data (sieve responsibility)
    Paging
    Filtering
    Searching
    Sorting
    Shaping

Pero hay muchas cosas que pensé que AspNetCore podría haber hecho mejor (al tener un paquete AspNetCore.RestFramework):

1. HATEOAS (api autodescubierto)
2. Tipos de papel (configuración de tipos de papel personalizados)
3. Control de versiones (actualización de la versión del tipo de medio)
4. Metadatos de datos mainpulated (paginación en el encabezado de X-Pagination, metadatos de filtro ... etc.).
5. Tasa de limitación y estrangulamiento.

Sé que hay toneladas de bibliotecas, encontré algunas aquí: https: //github.com/thangchung/awesome-dotnet-core ... ¡ Pero las bibliotecas de terceros no son realmente una buena opción para las aplicaciones empresariales!

Lo mismo ocurre con el tamiz, si hay un paquete OFICIAL para paginación, filtrado ... etc, los desarrolladores no tenderán a escribir bibliotecas con errores o no mantenidas, utilicé este tamiz en mi aplicación que mencioné anteriormente: https: // github.com/Biarity/Sieve , pero esta biblioteca puede de mantenerse en cualquier segundo que el autor esté ocupado.

Creo que AspNetCore es lo suficientemente maduro como para comenzar a pensar en soluciones listas para usar como en django, de esta manera podemos tener el lujo del rendimiento asp y la agilidad de django .

¡Pero las bibliotecas de terceros no son realmente una buena opción para las aplicaciones empresariales!

^ Es por eso que no podemos tener cosas bonitas 😞

¡Pero las bibliotecas de terceros no son realmente una buena opción para las aplicaciones empresariales!

Sí, esa es exactamente la mentalidad que debe cambiar aquí. ASP.NET Core y .NET Core son de código abierto y su ecosistema _ está_ abrazando a la comunidad de código abierto y debería continuar haciéndolo. No solo con las soluciones de código abierto que forman parte de .NET Foundation, sino con cualquier solución.

pero esta biblioteca puede dejar de ser mantenida en cualquier segundo que el autor esté ocupado

Y de la misma manera, un paquete "oficial" puede quedar sin mantenimiento en cualquier momento en que la empresa cambie su interés. Esto ha sucedido antes con cosas específicas de Microsoft, incluidos varios paquetes de código abierto que publicaron, pero es realmente natural para cualquier empresa.

Si usted decide tomar una dependencia de otra biblioteca queridos, es su responsabilidad que se puede vivir con eso. Independientemente de quién sea el autor de eso. Lo bueno del código abierto es que incluso si el autor no responde, tienes todo el derecho a cambiarlo tú mismo.

Estoy totalmente en contra de esperar soluciones oficiales de Microsoft para todo lo que pueda surgir. No solo porque nunca existe una solución única para todos, lo que hace que esto sea muy difícil y, al mismo tiempo, es probable que se salga de control, sino también porque esto quita recursos de las partes del marco que realmente necesitan atención. Y al mismo tiempo le duele la idea de código abierto muy, muy mala.

Si está creando aplicaciones empresariales y todavía tiene problemas con este síndrome de los NIH (o “no inventado en <large-company>”), realmente debería despertar porque es 2018 y probablemente debería adoptar el código abierto ahora.

Tienes razón, Microsoft puede dejar de mantener cualquier paquete, pero al menos tienen un LTS específico: https://www.microsoft.com/net/support/policy

Por ejemplo, la compatibilidad con .NET Core 1.1 finaliza el 27 de junio de 2019 ... de esta manera puedo estar seguro de que si uso esta versión no quedaré lisiado en el medio.

Una vez usé un asistente de etiquetas de paginación de terceros, y no fue agradable, el autor básicamente me dijo que no lo arreglaría para .NET Core 1.1, y que debería actualizar el proyecto, era un sistema universitario, en 2.0 (y tiene todo el derecho a hacerlo porque escribió ese paquete GRATIS).

Aquí está el problema, en la empresa, esto no funciona ... no puede convencer a todo el equipo de que debe pasar a 2.0 mientras la aplicación está en funcionamiento solo porque el asistente de etiquetas de paginación no lo hace ' ¡Funciona!
Entonces, simplemente comience a piratear la fuente como lo hice yo usando un decorador: https://github.com/cloudscribe/cloudscribe.Web.Pagination/issues/37

Y sí, ¿quién dijo que no soy un gran admirador del código abierto: confundido:?

¿@ 0xRumple no es la idea de código abierto para contribuir y colaborar?

Si ese asistente de etiquetas de paginación de terceros no existiera, tendría que escribirlo usted mismo y mantenerlo de todos modos, "en la empresa".

Aquí está el problema, en la empresa, esto no funciona ... no puede convencer a todo el equipo de que debe pasar a 2.0 mientras la aplicación está en funcionamiento solo porque el asistente de etiquetas de paginación no lo hace ' ¡Funciona!

En lugar de tratar de "convencer a todo el equipo de que debe pasar a 2.0", contribuya con una actualización y ayude en lugar de depender de otra persona para hacer el trabajo o esperar a que Microsoft proporcione un equivalente. Si el propietario no quiere aceptar su contribución, siga adelante con un tenedor para sus necesidades.

Supongo que su tipo de pensamiento (sin ofender en absoluto) es una gran parte de por qué hay una discusión sobre "servidor de autorización de Microsoft" vs servidor de identidad. ¿Cómo funcionará el código abierto si los desarrolladores no quieren participar? ¿Deberíamos esperar a que Microsoft nos proporcione todo el código que necesitamos?

Estoy de acuerdo con muchos aquí en que Microsoft debería tener cuidado de no acabar con los buenos proyectos de código abierto en el ecosistema haciendo sus propios reemplazos para todo.

De hecho, soy el autor de la biblioteca de ayuda de etiquetas de paginación mencionada por @ 0xRumple , su problema fue realmente con un componente de lista de páginas, no con la ayuda de etiquetas, que de hecho tiene un nuget más antiguo que admite el núcleo aspnet 1.x. La lista paginada era realmente algo que formaba parte de una biblioteca de buscapersonas de código abierto anterior que informó el diseño de mi biblioteca y se usó en las páginas de demostración al mismo tiempo, pero el asistente de etiquetas del paginador no dependía de la implementación de la lista paginada y hay otros paginados implementaciones de listas que podría haber usado mientras aún usaba el taghelper del buscapersonas. De hecho, desde entonces eliminé la lista paginada por completo de esa biblioteca, ya que ni siquiera es parte del taghelper y nunca lo fue.

Realmente no es diferente usar paquetes nuget de desarrolladores de OSS que Microsoft, ya que si está atascado en aspnet core 1.1, entonces no puede obtener correcciones y mejoras de aspnet core 2.x a menos que actualice al nuevo marco.

@joeaudette
Acabo de mencionar ese ejemplo para ilustrar mi punto sobre las soluciones integradas frente a las de terceros, todavía estoy agradecido por su trabajo en ese asistente de etiquetas de paginación ... la universidad usa su paquete de paginación y están felices: corazón:

@alhardy

¿Deberíamos esperar a que Microsoft nos proporcione todo el código que necesitamos?

Este es el principal problema, creemos que cuando Microsoft trae una solución oficial, ellos lucharán contra cualquier otra solución de código abierto o escribirán cada línea de código por sí mismos: sonrisa:

Por supuesto que no, podemos lo mejor de ambos mundos, una solución oficial y una basada en la comunidad si Microsoft adopta las soluciones correctas y crea las soluciones que faltan, para que los desarrolladores puedan concentrarse en contribuir en ellas.

La comunidad de django lo hizo bien, proporcionan / adoptan oficialmente la solución inicial simple para un problema específico, por ejemplo, el marco RESTful, y la comunidad se basa en eso ... eche un vistazo aquí a su etapa inicial de construcción de django-rest- marco: https://www.djangoproject.com/weblog/2016/jun/22/django-rest-framework-funding/

Comenzaron el proyecto inicial, y la comunidad está mejorando / construyendo sobre eso, este es su repositorio: https: //github.com/encode/django-rest-framework ... ¡ alrededor de 800 contribuyentes!
Y la comunidad está impulsada a crear paquetes que resuelvan problemas además de ese paquete, como django-rest-auth o django-rest-framework-jwt .

Al menos proporcionan las "soluciones oficiales" que la mayoría de los desarrolladores necesitan, como django-admin-site o django-debug-toolbar . Esto también proviene de la filosofía de Python de "baterías incluidas". Al principio, pensé que era malo ya que se esfuerza por encontrar soluciones de mínimo común denominador, y luego me di cuenta de la brisa que trae.

* PD: Dapper (por StackExchange) y EFCore (por Microsoft) son ambos ORM, pero tienen como objetivo resolver el mismo problema en diferentes enfoques. Dapper se creó inicialmente en 2011, mientras que EFCore 2014 ... ¿EFCore afectó gravemente a los proyectos de código abierto? por supuesto que no, ¡y es una solución oficial!
La gente ya está construyendo sobre esas cosas increíbles, como esta: https://github.com/crhairr/EntityFrameworkCore.MongoDb/

¿EFCore afectó gravemente a los proyectos de código abierto?

Uuuh, ¿alguien recuerda NHibernate (que se acerca más a EF en funcionalidad)? No, probablemente no, porque está casi muerto después del lanzamiento de EF 😕

@ 0xRumple

Por supuesto que no, podemos lo mejor de ambos mundos, una solución oficial y una solución basada en la comunidad si Microsoft adopta las soluciones correctas y crea las soluciones que faltan,

En este caso, no se debe a que esté recreando una solución existente, pero con menos funcionalidad a propósito.

Entity Framework y Dapper son muy diferentes. EF siempre fue diseñado para ser un ORM con todas las funciones, y ambos llegaron años después del Linq-To-SQL original en 2007 .

Sin embargo, tampoco creo que te equivoques y parece que todos estamos hablando entre nosotros. El hilo es principalmente comentarios sobre el producto del servidor de autenticación mientras habla de bibliotecas relacionadas con REST, que parecen lo suficientemente pequeñas y enfocadas como para incluirlas en un marco web. Estoy de acuerdo en que sería útil tener incorporados parámetros search/paging/filter estandarizados para el código API web.

Esta discusión no reconoce la incómoda verdad de que en algunas organizaciones, los desarrolladores tienen que dar cuenta de cada paquete de código abierto introducido en su solución. En algunos casos, se trata de un análisis automático que producirá informes de "Riesgo" que, con frecuencia, un gestor de riesgos no técnico deberá revisar. Estas herramientas marcarán cualquier cosa que no se mantenga activamente y cualquier cosa que parezca una licencia copyleft.

También puede imaginar que en estas organizaciones contribuir al código abierto se considera una locura.

Sí, Identity Server 4 es asombroso. Pero para un administrador de riesgos no técnico es algo para lo que no tenemos garantía, algo respaldado por un puñado de personas y peor aún, algo con el código fuente disponible para que todos lo vean. Esta persona está equivocada, pero el desarrollador promedio en el terreno no va a ganar esta pelea.

Un "Identity Server Lite", como dice acertadamente marcar la diferencia entre poder usar .NET Core o no, especialmente si hay un arquitecto empresarial en la organización que insiste en que algunos $$ $$$ La basura empresarial de HP o IBM se usa en su lugar para la autenticación.

@edandersen

Pero para un administrador de riesgos no técnico es algo para lo que no tenemos garantía, algo respaldado por un puñado de personas y peor aún, algo con el código fuente disponible para que todos lo vean.

Estoy bastante seguro de que la gente de IdentityServer brindaría algún soporte si les pagara por ello, al igual que pagaría a Microsoft. OSS no equivale a gratis.

¿Qué le hace pensar que el equipo de ASP.NET Core en Microsoft no es "un puñado de personas"? Spoiler ... son como 20-30 personas en total. Solo un par trabajaría en un producto como ese.

Tengo mucha curiosidad por saber por qué "el código fuente disponible para que todos lo vean" es algo malo. ¿Y qué le hace pensar que este producto de Microsoft no será de código abierto? Es el nuevo valor predeterminado.

@khellang "el código fuente disponible para que todos lo vean" para que quede claro, ¡esto es algo bueno! Pero se sorprendería de los argumentos que algunos desarrolladores deben tener en el trabajo. Desafortunadamente, el punto "Microsoft lo escribió" es el único argumento aceptable a veces. Tenga en cuenta que estoy jugando al abogado del diablo para una compañía disfuncional hipotética pero típica.

Y, por supuesto, los mismos desarrolladores podrían defender que su empleador pague por el soporte de Identity Server, pero el proceso de adquisición probablemente les robará la voluntad de vivir.

Bueno, si comenzamos a usar estos argumentos de gerentes no tecnológicos, las cosas comenzarán a volverse locas. En mi humilde opinión, las personas que no son tecnológicas no deberían dictar qué se debe usar o no. Si quieren tener un dicho, al menos deberían saber de qué están hablando, y decir que un paquete bien conocido como IdentityServer es de menor calidad que uno de MS, para mí, es simplemente incorrecto. ¡Huiría de una empresa como esa!

Pero el punto aquí es que casi todos están de acuerdo en que pasar tiempo en algo que ya está ahí, es sólido y MUCHA gente lo está usando es un poco extraño. Me pregunto cuál es la verdadera razón detrás de esto ... No creo que fuera como: Oh, construyamos lo nuestro, solo porque podemos. ¿Los clientes realmente piden esto de lo que quizás no somos conscientes?

Personalmente, no veo a otro competidor en el espacio de OAuth-Server como un problema, pero es algo bueno.

Puede ayudar a impulsar el desarrollo en esta área, o simplemente servir como una solución rápida y sucia para las personas que no necesitan nada más que eso: una solución rápida y sucia.

Si desea o necesita más de un servidor OAuth, nada nos impide utilizar las soluciones existentes. O, si desea una plantilla de un clic para hacer OAuth básico _y nada más_, entonces este parece un objetivo digno, al menos para mí.

Creo que este hilo se ha convertido en un ojo por ojo sobre lo que es OSS, lo que MS es bueno para hacer y lo que MS no es bueno, en lugar de centrarse en lo que está en la hoja de ruta para .NET Core 2.2, que es lo que realmente importa aquí.

@khellang
"NHibernate está muerto", dijo quién? Veo que el proyecto sigue vivo e incluso tiene un mejor impulso que Dapper
https://github.com/nhibernate/nhibernate-core/graphs/contributors
https://github.com/StackExchange/Dapper/graphs/contributors

Ah, no mencioné IdentityServer hasta ahora para mantener mi punto de tener un marco RESTful dentro de los paquetes oficiales de aspcore ... aquí están mis pensamientos sobre IdentityServer, es realmente sólido y genial, PERO es un proyecto de 2 chicos, echa un vistazo a las métricas:
https://github.com/IdentityServer/IdentityServer4/graphs/contributors

Aproximadamente el 85% del trabajo lo realizan 2 personas y está bien para un proyecto relacionado con la seguridad, pero en la empresa muchas empresas piensan en la capacidad de mantenimiento de dichos proyectos en el futuro. Recientemente, una empresa me dijo que querían que usara React en lugar de Vus.Js en su proyecto solo porque dijeron "vue.js es más o menos Evan You" ... y creo que tienen razón. Y esto es lo que estoy tratando de decir desde el comienzo de la discusión sobre tener un paquete RESTful dentro de los paquetes oficiales, ninguna gran empresa no aceptará que lo use en un paquete "potencial" no mantenido en sus proyectos.

Lo mismo ocurre con la manipulación / cribado de datos (paginación, configuración, clasificación ... etc.) porque casi todos los proyectos contienen esos requisitos, y sí, como dijo @manigandham , están estandarizados y son sencillos.

@manigandham
Exactamente eso es lo que creo que es correcto ... adaptar y respaldar las soluciones oficialmente , ya sea financieramente o contribuyendo a través de github o al menos mencionándolas en sus documentos o cursos (ya he visto a Hanselman mencionar SwashBuckle en uno de sus cursos en Microsoft Virtual Academy, que es realmente genial, ¡y sería mejor ver una mayor adaptación a tales proyectos!).

@kieronlanning
Tienes razón, nos hemos alejado demasiado del tema principal ... pero como mencioné antes, asp core se ha vuelto muy maduro (eficiente y confiable), y creo que es hora de comenzar con lo que está fuera de lo común. -Caja de soluciones .

Creo que descontar un proyecto porque tiene dos contribuyentes principales es bastante tonto. IS4 está muy bien mantenido y esos dos muchachos pasan mucho tiempo respondiendo preguntas y ayudando a la gente. También está ampliamente considerado como una de las mejores soluciones FOSS para un servidor OAuth2 en el mercado.

"NHibernate está muerto", dijo quién? Veo que el proyecto sigue vivo e incluso tiene un mejor impulso que Dapper

@ 0xRumple Dije "casi muerto" 😉 Parece que tienes métricas muy extrañas sobre el estado y el uso de proyectos de OSS. ¿Es justo comparar el número de compromisos en un proyecto de 2003 con uno que ha estado en marcha desde 2011? También son bestias _muy_ diferentes (como se señaló anteriormente en el hilo); Dapper ha estado "completo" (eso no significa sin mantenimiento, abandonado, etc.) durante algún tiempo, mientras que NHibernate (y su conjunto de funciones) se ha quedado atrás.
Sé que el proyecto sigue avanzando, pero no recuerdo la última vez, en mis últimos 7 años consultando en el espacio .NET, donde me encontré con NHibernate en la naturaleza (donde no estaba en el proceso de migrando a Entity Framework). Todos los que han estado siguiendo este espacio los últimos años saben muy bien que NHibernate se ha quedado atrás y ha perdido participación de mercado frente a Entity Framework. Solo mire los números de descarga de NuGet: Entity Framework tiene 45.8M frente a NHibernate con 3.4M.

De todos modos, el punto no es Entity Framework vs NHibernate. Fue solo un ejemplo. Hemos tenido esta discusión una y otra vez; más recientemente, cuando Microsoft lanzó su propia implementación de contenedor IoC liviano en ASP.NET Core o cuando Microsoft estaba contemplando implementar su propio mapeador de objetos. Cada vez que Microsoft ingresa a un espacio en la comunidad OSS, aspira mucho (¿la mayoría?) Del aire de la habitación. A menudo, los proyectos más pequeños impulsados ​​por la comunidad se sofocan con el tiempo. Yo, y la mayor parte de la comunidad, lo sabemos demasiado bien; es imposible competir con Microsoft en el mundo de Microsoft (.NET). Entiendo perfectamente que tienen clientes de pago que necesitan satisfacer, por lo que no espero que estos comentarios cambien de opinión: sonríe:

Características impresionantes :)

¿Dónde puedo obtener más información sobre la función de verificación de estado?

Mejorar la gestión de certificados autofirmados

Al desarrollar aplicaciones web que llaman a las API web asociadas, llega un momento en el que resulta útil probarlas con usuarios internos a través de la red local. Es posible que hayas pasado todas las pruebas unitarias, funcionales y de integración, pero no hay nada como un humano para romper realmente las cosas.

Con el espíritu de desvincular las preocupaciones, mis aplicaciones web llaman a varias API web. En la primera instancia, desarrollo estas API web usando https: // localhost :. Una vez que una API web está lista (suficiente), la publico en IIS en mi máquina local. Cada sitio tiene un nombre de host apropiado que configuré en mi servidor DNS interno. En este punto, uso Barry Dorrans '- @blowdart - https://gist.github.com/blowdart/1cb907b68ed56bcf8498c16faff4221c para crear un certificado de servidor. Siempre que importe los certificados en todas las tiendas correctas, todo funciona en mi máquina sin alarmas.

Esto cambia cuando otras personas en la red acceden a las aplicaciones web (las llamadas a la API están todas dentro de mi cuadro de desarrollo). El usuario recibe advertencias nefastas. Les digo que ignoren estas advertencias y, cuando sea posible y lo suficientemente sencillo, que importen los certificados. Debido a que estos certificados autofirmados tienen el mismo nombre de emisor y el mismo nombre común, cada nueva aplicación web activa una página de advertencia.

No puedo evitar pensar que pedir a los usuarios de una organización que revisen las páginas de advertencia es una mala idea.

Como no especialista en seguridad, hay un par de cosas que me gustaría ver:

• la capacidad de tener un certificado raíz local para todos los certificados de desarrollo que creo y luego que me digan una forma autorizada de importarlo en PC, Mac, dispositivos Android, iPad y iPhone, para que estas páginas alarmantes ya no ocurran

• un método más fácil de generar certificados para API que se puede usar con IIS y Kestrel que llena todos los almacenes de certificados correctos correctamente

@CrispinH Para ser honesto, apoyar una CA raíz sería, bueno, una preocupación de hacer girar una CA raíz. Si se encuentra en ese punto, es hora de considerar la posibilidad de crear una CA raíz usted mismo y administrarla. El soporte autofirmado, ya sea a través de la herramienta global o mi script, es solo para eso, desarrollo. Una vez que comienzas a permitir que las personas se adjunten a él, estás fuera del alcance de esa función. Si está en una organización y desea que las personas accedan a los servicios, entonces la organización debe descubrir su estrategia de certificado, ejecutar una CA interna a través de Windows u OpenSSL y eliminar la raíz a través de la política de AD u otros medios.

@blowdart Una de las razones de mi balido fue que pasé un par de días tratando de hacer girar una CA raíz y no pude hacerlo bien debido a mi falta de competencia en esta área. Incluso intenté averiguar cómo modificar su esencia para aceptar una CA raíz local.
Toda la documentación que encontré era demasiado general; todo lo que quería era un proceso para crear certificados (idealmente basado en una CA raíz) únicamente para proteger las API y las aplicaciones web con un certificado de servidor. Quizás la documentación de casos específicos sea todo lo que se necesita.

@CrispinH Window Server viene con una autoridad de certificación que puede configurar, si desea ir por el camino completo.

Certificados en general no son un tema fácil y que tendrán que aprender un poco para hacerlo bien.

Para fines de desarrollo, los certificados autofirmados son totalmente correctos y fáciles de usar. Todo lo que vaya más allá de eso, incluida la configuración y la gestión de una CA, ya no es para fines de desarrollo y definitivamente está fuera del alcance y es demasiado complejo para un marco de aplicación web.

@CrispinH Como dijo @poke , es difícil hacerlo bien. Una vez que tenga máquinas que confíen en una CA raíz, todos los certificados emitidos serán confiables, y los desarrolladores ejecutan código que no es de confianza en sus cajas de desarrollo, eso es lo que son los paquetes nuget después de todo. Así que considere algo que robe su CA raíz. En la vida real, las CA raíz tienden a mantenerse fuera de línea, firman un segundo certificado, que está restringido en lo que puede hacer, los certificados de servidor y cliente generalmente, y luego los certificados se emiten por eso, por el control, muchas CA de desarrollo están restringidas, por lo que compromiso significaría la capacidad de emitir certificados de firma de código de confianza. Sin querer insultar terriblemente a una CA no es algo que un desarrollador deba ejecutar, es mejor dejarlo en manos de aquellos que comprenden las consecuencias, y las consecuencias pueden ser nefastas. Luego está la rotación de certificados, la revocación, OCSP y más a considerar. Tengo que tener una CA de prueba para mi middleware de autenticación de certificados, y está en una máquina virtual que está apagada. Me pongo muy nervioso cuando lo enciendo para obtener más certificados de prueba.

Si realmente, de verdad, desea bajar a esta raíz (juego de palabras intencionado), entonces https://infiniteloop.io/powershell-self-signed-certificate-via-self-signed-root-ca/ podría ayudarlo a comenzar en powershell, pero eso no le brinda CRL, OCSP o soporte de revocación. https://gist.github.com/Soarez/9688998 parece cubrir OpenSSL. Y si necesita CRL, entonces está la CA integrada en Windows, la configuración está documentada aquí https://leastprivilege.com/2008/08/14/how-to-build-a-developmenttestdemo-ca/

_Tenga en cuenta que no he utilizado ninguno de los enlaces anteriores (aunque confío en el autor del último), y de ninguna manera es este un tipo de recomendación oficial de MSFT. La recomendación oficial del equipo de seguridad de ASP.NET es permitir que alguien que conozca la infraestructura y los riesgos configure una CA corporativa para usted. Habla con tu departamento de TI_

@blowdart No, realmente _no_ quiero bajar esa 'raíz'. Es bueno saber por qué ahora.

Parece que mi prueba humanoide tendrá que realizarse en la Internet pública en un host de prueba utilizando certificados Let's Encrypt, pero con un muro de autenticación para mantener alejadas las miradas indiscretas.

Dependiendo de lo que necesite y su presupuesto, algunas empresas como DigiCert ofrecen servicios administrados de PKI. Eso puede usar una raíz privada o pública. No conozco los costos.

Y si solo es HTTPS, recuerde que obtiene un certificado para cada subdominio de azurewebsites.net.

Sopesando la nueva implementación de OpenID, en lugar de otra implementación más para aprender, abrazar e involucrarse con los esfuerzos de la comunidad de IdentityServer4 y contribuir a crear una versión "Lite" de IdentityServer obstinada que podría incluirse desde nuget y configurar con un esfuerzo mínimo.

Todos están exagerando.
El equipo de ASP.NET ya está pensando como todos ustedes. @DamianEdwards habló de ello en el Community Standup más reciente.

Aquí está la parte más relevante (pero te animo a que la escuches toda):

"De hecho, estamos hablando con la gente de IdentityServer sobre eso ahora".
https://youtu.be/Tzh2EXwgEk8?t=25m15s

Realmente interesante ver cuán apasionada es la discusión en torno al proyecto "Servidor de autorización MSFT": smile:

Por cierto, Vittorio Bertocci me contactó hace exactamente 2 años para charlar sobre este proyecto ya que estaban considerando usar OpenIddict (el servidor OIDC que desarrollo y mantengo) como base para este proyecto.
El año pasado, me dijeron que preferían ir con su propia implementación en lugar de aprovechar el OSS de terceros, ya que se consideraba "demasiado estratégico" desde una perspectiva comercial (que es algo que puedo entender).

Me alegra ver que cambiaron de opinión y finalmente están considerando usar una solución OSS existente como IdentityServer4 en lugar de crear otra cosa desde cero: es una muy buena señal enviada a la comunidad .NET: clap:

Esto se sale un poco del hilo, pero @CrispinH , parece que estás buscando un poco de https://stackoverflow.com/questions/51123289/how-to-generate-a-response-to-a-csr- in-net-core-ie-to-write-a-csr-signing-se. .NET Core 2.0 incluye otras facilidades para crear y trabajar con certificados también. Consulte también los comentarios sobre la ejecución de una entidad emisora ​​de certificados. Las herramientas de la biblioteca casi están disponibles y, dependiendo de su organización, es posible que pueda usar certificados de alguna manera controlada en algún servidor sin establecer mucha intraestructura. En ese token, leer las solicitudes de firma de certificados (CSR) (codificadas en DER) listas para usar sería una buena adición, junto con una biblioteca JSON-LD. Y más cripto en general. :)

Me encantaría ver algún middleware como soporte para LetsEncrypt, trabajando con App Services en Windows, Linux y Docker en Azure.

@kieronlanning Estoy de acuerdo, además de la codificación DER con respecto a la firma de RSE mencionada anteriormente (aunque agregar soporte sin casos extremos no parece tan difícil). Hay algunas bibliotecas para .NET (también enumeradas en las páginas de Let's Encrypt), pero también algunos problemas. Por ejemplo, el .NET que se mantiene más activamente con respecto a Let's Encryptc parece ser Certes , pero BouncyCastle . Sería bueno si alguien lo ayudara a ser solo .NET Standard 2.0. Una razón para mí es que BouncyCastle no funciona bien con Orleans TaskScheduler . :)

Sobre la mención de criptografía, aunque no es estrictamente un problema de ASP.NET Core, MS aparentemente está presionando mucho en blockchains, pero .NET carece de capacidad de criptografía. _En la superficie_ mucho de esto también tiene que ver con el núcleo de ASP.NET (como, por ejemplo, las diversas implementaciones del explorador de blockchain, como https://etherscan.io/) y sería bueno tener más soporte para bibliotecas como Inferno y más habilidades integradas en la plataforma. Un problema pendiente está en https://github.com/sdrapkin/SecurityDriven.Inferno/issues/10#issuecomment -395778931 (prestando algunos ojos aquí si alguien tiene las habilidades para ayudar).

Esta de @kieronlanning sería mi solicitud de función número uno:

"Me encantaría ver algún middleware como soporte para LetsEncrypt".

Aquí está el problema abierto: https://github.com/aspnet/Home/issues/1190. Por favor, ve y vota a favor.

¿Se considera que el paquete de mensajes está disponible en el núcleo de asp.net para todos los marcos y no solo en SignalR? Dado que el encuadre Http2 es binario, ¿está considerando el paquete de mensajes para eso?

¿servidor de autorización lanzado en preview3?

Ya existe. Https://IdentityServer.io

@privilegios mínimos
Me gusta y uso IdentityServer
Pero tengo mucha curiosidad por ver la implementación de Microsoft y entender por qué (microsoft) no incorporó el servidor de identidad en su núcleo

@ danroth27 - ¿puedes compartir las últimas novedades?

Microsoft está utilizando IdentityServer.

Entonces, ¿cómo está funcionando esto? ¿Microsoft usa el código IDS4 directamente? ¿Microsoft recorta las características de IDS4? ¿Cuál es el modelo aquí? ¿Cuáles deberían ser nuestras expectativas? ¿Existe una posible ruta de migración entre ellos?

Microsoft usará nuestro paquete nuget estándar y usará nuestra API de configuración para darle algunas configuraciones predeterminadas para jugar bien con la plantilla y la identidad ASP.NET. Eso es todo.

Ya puedes lograr exactamente lo mismo hoy.

Probablemente soy yo, pero me sorprende leer que IdentityServer4 llena el vacío del servidor de autorización de Microsoft. Según tengo entendido, la principal preocupación de IdentityServer es la autenticación, no la autorización.

Para mí, IdentityServer está bien como servidor de autenticación, pero no funciona como servidor de autorización. Supuse que esa era la razón por la que se creó PolicyServer.

@leastprivilege ¿Se ampliará IdentityServer con algo como PolicyServer?

@Ruard Entonces es confuso (y Dominick probablemente se encogerá o se meterá en mi explicación).

OAuth es autenticación, pero tiene autorización como primer paso, y luego emite una concesión basada en alcances, etc. Entonces, en nuestro paquete, Identity Server realizará el inicio de sesión, lo validará, validará los alcances requeridos (que en el caso inicial siempre tiene éxito porque estamos usando el alcance predeterminado), luego pasa un token a la persona que llama, que luego se envía a la API que lo validará, y luego, opcionalmente, puede ir más allá con las reglas de autorización dentro de la API. OIDC proporciona OIDC lo confunde aún más al ser una forma de adquirir información de identidad de un usuario, incluida la autorización de que la aplicación puede tenerla ...

Entonces, básicamente, Identity Server nos dará una identidad, autorizando que la aplicación pueda tenerla, y luego puede usar las piezas de autorización de ASP.NET para controlar aún más el acceso.

@MichelZ habrá una historia de

@blowdart Ya usamos IdentityServer (¡y estamos impresionados con las capacidades!), sin embargo, obtener el beneficio de las políticas de "soporte a largo plazo" de Microsoft también es una gran ventaja para nosotros. Por lo tanto, cualquier sinergia que pueda proporcionar aquí es muy bienvenida.
Amamos ambos productos, ASP.NET Core e IdentityServer (4) de la misma manera. Definitivamente es un paso en la dirección correcta en mi humilde opinión.
Sin embargo, también reconocemos que todos estos protocolos no son exactamente "sencillos". No son una ciencia de cohetes, los entiendes, pero aún así, tampoco son sencillos.

Desearía que alguien inventara un protocolo REALMENTE simple, dejando atrás TODAS las implementaciones heredadas y centrándose en el futuro.

Si ya lo está usando, entonces su uso no cambiará realmente, lo tiene funcionando :)

Nuestro objetivo es Archivo Nuevo> API web con autenticación individual, y luego agregamos otras API, y todo se basa en las convenciones. Eso no funcionará para las aplicaciones existentes, porque las convenciones serán nuevas. No planearía reemplazar tu configuración con la nuestra :)

Desearía que alguien inventara un protocolo REALMENTE simple, dejando atrás TODAS las implementaciones heredadas y centrándose en el futuro.

Este es el problema: las aplicaciones se están volviendo más complicadas, no menos. Para asegurarlos, la seguridad también es complicada. Siempre he rechazado cuando escucho a la gente decir que IdentityServer es complicado, no lo es. Son los requisitos de seguridad de su aplicación los que son complicados. A menudo, la gente no tiene la perspectiva para reconocer eso.

Sí, está funcionando, y está funcionando bien, pero aún así, esa seguridad adicional que (puede) brindarle cuando Microsoft "respalda" oficialmente y, en última instancia, "respalda" una tecnología, es oro puro ...!
¡Has sido elevado a un nivel completamente nuevo!

@brockallen Sí, las aplicaciones probablemente complican MUCHO las cosas. Sin embargo, es innegable que el protocolo OIDC heredó algunas cosas de OAuth 2.0 de las que mejor se habría desprendido. Algunos de los miembros de su equipo (creo que fue @leastprivilege) dijeron que si OIDC se desarrollara desde cero, probablemente se vería bastante diferente de lo que tenemos ahora.

No estoy diciendo que lo que tenemos ahora sea "malo", realmente aprecio lo que tenemos y es realmente funcional para nuestros propósitos, ¡y espero que todos los involucrados en la creación estén orgullosos del trabajo que hicieron!

@Equipo;
Para la vista previa 3, ¿podría proporcionar algunos documentos detallados sobre el "Servidor de autorización" y cómo funcionará con la API web y JS del lado del cliente, como Vue?
Necesitamos tomar una decisión y esta vista previa en el servidor de autorización es una vista previa crítica y cualquier documento detallado nos dará información sobre nuestra decisión.

¡Gracias!

Como se discutió antes

https://identityserver.io

Acabo de notar que también las API de datos abiertos de EE. UU. Están en JSON-LD: https://project-open-data.cio.gov/v1.1/schema/. Esta parece ser una tendencia de rápido crecimiento, por lo que una biblioteca JSON-LD .NET con recursos suficientes utilizada con ASP.NET estaría bien. :)

@veikkoeeva También lo son (al menos parte de) las API de NuGet. Están usando json-ld.net , no necesitan otra biblioteca.

@khellang Y también hay otras bibliotecas, esta biblioteca en particular podría usar mantenedores (https://github.com/linked-data-dotnet/json-ld.net/issues/26). Me doy cuenta de que es de código abierto y, en teoría, podría intervenir para contribuir, pero por el momento al menos estoy demasiado disperso para ayudar con esto. Dicho de otra manera, quizás, me gustaría llamar la atención sobre el hecho de que muchos conjuntos de datos parecen estar avanzando hacia formatos semánticos y no está claro cómo trabajar de manera eficiente con eso usando .NET.

En mi humilde opinión, agregar IdentityServer4 al núcleo de ASP.Net Core es una mala idea.
No convierta .NetCore en un marco monolítico.
.NetCore está ahí e IdentityServer4 está ahí, la gente hace que la arquitectura se base en sus propias necesidades de autenticación y autorización.

@mikeandersun El plan es solo tener una configuración predeterminada fácil que pueda agregar a su proyecto para que funcione de inmediato.

Aún no puedes usarlo y no te afectará. Aún puede usar IdSrv y configurarlo completamente usted mismo. Aún puede elegir qué componentes incluir en su proyecto. Nada de esto hace que ASP.NET Core sea monolítico.

ASP.NET Core! = .NET Core por cierto.

¿Será 2.2 una versión LTS? (Preguntar si ya se anunció, no pedirle que haga un nuevo anuncio).

@yzorg no que no ha sido anunciado. A menudo, esa determinación se realiza después del lanzamiento en función de la calidad / estabilidad.

@blowdart , ¿esta plantilla proporcionaría al servidor de identidad un cliente MVC de aplicación web en lugar de una API?

@Ponant No. Está dirigido solo a API. Reevaluaremos eso en la línea de tiempo 3.x.

Interesante ... Esta pregunta surgió en una reunión ayer. Si construimos un proyecto "MVC" completo sin el uso de API web, ¿podemos usar la nueva plantilla ASP.Net 2.2 IS4 que está integrada en 2.2?
Parece que el gran jefe (Barry) acaba de responder la pregunta.

@blowdart allias big boss: ¿por qué no se hace de una sola vez? Parece trivial a primera vista usar un cliente mvc o una api web hablando con un servidor IS4 de identidad central de asp.net.

@Ponant Porque no tenemos recursos infinitos. ¿Qué características le hubiera gustado que elimináramos para que todos cambiaran una parte importante del flujo de MVC que no daría ninguna característica nueva, solo cambiaría la forma en que funciona una existente? Una API autenticada individual ha sido una brecha entre el marco completo y ASP.NET Core. El trabajo se centró en llenar ese vacío. Identity Server ya tiene plantillas funcionales para MVC con Identity Server como "núcleo".

@CrispinH @blowdart Estoy esto: hay 7 tickets de Uservoice que se quejan de este centenar de desarrolladores y empresas. Lamentablemente, muchas otras tecnologías como el portal Java blueRay JSR 182 o 173 ¡un trabajo tan hermoso aquí!

-> Tantas solicitudes de gestión de usuarios / grupos / inquilinos

-> OTRA VEZ aquí la gente se queja ... continúa, incluso en twitter y facebook ... esta es la razón - ¡por qué otras plataformas como WP y PHP son más fáciles!

Si bien @manigandham cree que el servidor de identidad es una gran cobran MUCHO por la herramienta de administración de GUI y no es barata para muchos países y desarrolladores, también va en contra del desarrollador de bajo TCO. ¿Cuántas personas realmente pueden pagar esto? Ha sido un obstáculo ENORME y un paso atrás, se necesita una funcionalidad básica de vainilla y una GUI para administrar los usuarios / roles / roles-grupos de usuarios / inquilinos , que luego pueden ser mejorados por el desarrollador

@papyr ¿Por qué no comienzas un proyecto de código abierto para esto? No es necesario incorporar una GUI completa para todo en el marco (plantillas). Y viendo lo difícil que ya es para el equipo mantener las actualizaciones de las plantillas, por ejemplo, con cambios en Bootstrap, no quiero que gasten más esfuerzo en eso. Pero por otro lado, entiendo totalmente que esto sería algo útil para existir, así que ¿por qué no lo conviertes en un esfuerzo comunitario?

@papyr @poke no es necesario un nuevo proyecto de código abierto, hay excelentes proyectos existentes.

Si desea algo de código abierto de MS diseñado para competir con WordPress, mire Orchard:
https://github.com/OrchardCMS/OrchardCore

Si desea más un enfoque de biblioteca en lugar de un marco, consulte cloudscribe, que tiene nugets para multi-tenancy y usuario y gestión de roles y reclamos ui preconstruida con una integración de identityserver4 opcional y cms opcional (cloudscribe.Simple / content) como nugets adicionales.
https://www.cloudscribe.com/docs/introduction
https://github.com/cloudscribe/cloudscribe
https://github.com/cloudscribe/cloudscribe.SimpleContent

Si desea algo de código abierto de MS diseñado para competir con WordPress, mire Orchard:
https://github.com/OrchardCMS/OrchardCore

Apoyo esta recomendación.

Y Orchard Core está diseñado para ser extremadamente modular. Por ejemplo, es posible extraer solo su módulo de tenencia múltiple y usarlo en sus propios proyectos . También ya tiene módulos para administrar usuarios y roles, y estoy seguro de que agradecerían tu contribución para hacerlo aún mejor.

Puedes ver muchas demostraciones de sus diversas funciones en su canal .

@papyr ¿Por qué no comienzas un proyecto de código abierto para esto?

https://github.com/IdentityManager/IdentityManager2

Esta cosa de la interfaz de usuario puede ser complicada, aunque útil para obtener cosas básicas rápidamente. Parece que recientemente me encontré con casos de creación de la interfaz de usuario no es la tarea más importante, pero averiguar cómo satisfacer las "necesidades del proceso", como aprobar previamente algunos correos electrónicos (que hacen algo específico de la aplicación), llamar a las API que llaman a las API , algunos de los cuales pueden significar uniones en la base de datos o llamadas a otro lugar, etc. y luego agregarlas a los tokens y la lógica de la interfaz de usuario.

Por lo tanto, tener buenos tutoriales como https://mcguirev10.com/2018/01/28/login-identity-management-best-practices.html o los de https://mcguirev10.com/page2/ se siente más importante que la interfaz de usuario ( especialmente si uno no puede o no quiere usar EF). Luego, tal vez busque la interfaz de usuario para la tecnología elegida (Aurelia / Angular / Razor / React / Vue, etc.) y cómo implementan el manejo de datos.

Al nombrar proyectos y nombres, además de @ scottbrady91 , me ha resultado muy educativo comprobar @LindaLawton , https://github.com/abergs/fido2-net-lib ( @abergs , @aseigler), @TomCJones , @ mackie1001 (Gitter), etc.para proporcionar explicaciones adicionales y código para echar un vistazo cuando se sale incluso un poco de la necesidad básica. Olvidé agregar algunos nombres y proyectos. :)

¿Por qué .net core no puede tener páginas web normales de razor? Cuando hago informes complejos, me gusta hacer todo desde una sola página de maquinilla de afeitar (c #). O al menos la capacidad de usar solo una vista a veces solo sin modelo o controlador.

En otras palabras, la capacidad básica de conectarse a sql en la vista y recibir solicitudes GET y POST, desinfectada, por supuesto, actualmente uso una clase llamada Striptag.cs.

¿Por qué .net core no puede tener páginas web normales de razor?

Puede usar las páginas de Razor para esto https://docs.microsoft.com/en-us/aspnet/core/razor-pages/?view=aspnetcore-2.1&tabs=visual-studio

Tener una clase de modelo de página de respaldo es opcional; puedes tener una sola página

benaadams gracias por la respuesta, ¿cómo usaría la solicitud GET y POST directamente en una página de afeitar y realizar una conexión básica con el servidor SQL? La conexión para consultas regulares, no entidades ado, linq u ORM. Siempre prefiero las consultas normales.

Igual que:

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

Sé que la cadena de conexión está en un archivo json ahora, pero no sé cómo usarla a la vista. Algunas cosas no están profundamente documentadas.

Bueno, tiene una curva de aprendizaje. Si desea obtener datos _antes_ de cargar la vista, hágalo en la acción correspondiente. Entonces, para HomeController.ViewReports acción y Views/Home/ViewReports.cshtml página, escribe:

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

Si desea obtener datos _después_ de la carga de la página, generalmente usa solicitudes AJAX para algún punto final GET / POST puro que devuelve datos con formato JSON.

Todavía puede hacerlo en una página sin ningún controlador o acción; algo como

<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>
    }
}

He usado mvc asp.net y formularios web y páginas antiguas de razor, por lo que no soy nuevo en esto. He pasado 3 horas y todavía no puedo hacer que funcione una página de prueba simple, tengo:

<!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>

Solo una página html y se carga.

Modelo

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"];
        }
    }
}

Vista:

<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 horas y todo lo que obtengo es una página en blanco. Probé una declaración de devolución, etc.

Si escribo http: // localhost : 51307 / pets / razdb3, obtengo las segundas divisiones "hola", pero
el @ Model.myvar no obtengo nada.

Soy nuevo en .net core y nunca hubiera imaginado que sería o podría ser tan difícil mostrar una página de afeitar.

En la comunidad VS 2017

el @ Model.myvar no obtengo nada.

Establece el myvar en una solicitud de publicación ( OnPost ) con el valor del formulario psearch ; ¿Entonces necesitarías hacer una solicitud POST con ese valor para configurarlo?

En la solicitud GET ( OnGet ) que se obtiene simplemente al navegar a la URL desde el navegador; en lugar de un formulario de devolución de datos, no se establece en nada.

Intente configurarlo en un valor predeterminado para que aparezca cuando no lo configure para confirmar que el modelo está fluyendo:

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

Cambiado a

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

Y sigue siendo una página en blanco. ¿Es @ Model.myvar correcto?

incluso cambiado a

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>

Se construye bien sin errores, pero una página en blanco no importa lo que intente.

Comentarios / pensamientos educados: parece que esta discusión sobre "páginas de afeitar normales" está comenzando a salirse un poco del tema con respecto al tema de este hilo.

😊 😊

Lo siento, me doy cuenta de que debería haber usado el foro. Gracias @benaadams, su código me puso en el camino correcto y encontré esto:

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

De todos modos, así es como normalmente hacía las cosas, usando la palabra clave "nueva", como

EmployeeDataAccessLayer objemployee = new EmployeeDataAccessLayer();

Fue reconfortante ver que aún podía usar clases personalizadas en .net core.

Debe admitir que .net core tiene una curva de aprendizaje más pronunciada que algunos frameworks anteriores de asp.net. Muchas gracias.

Las notas de la versión hablan de una función de "Servidor de autorización" que se espera como complemento en los próximos meses. ¿Hay más información disponible sobre esta función? Estoy tratando de decidir si deberíamos esperarlo. O cree nuestra propia solución.

Las notas de la versión hablan de una función de "Servidor de autorización" que se espera como complemento en los próximos meses. ¿Hay más información disponible sobre esta función? Estoy tratando de decidir si deberíamos esperarlo. O cree nuestra propia solución.

Creo que el plan actual es utilizar https://github.com/IdentityServer/IdentityServer4 de forma "preempaquetada".

Siguiendo las notas del equipo de IS4 y el equipo de seguridad de MS, parecía que MS simplemente estaba tratando de hacer un empaquetado rápido y sucio de IS4 y terminarlo. Pero parece que alguien con más sabiduría decidió reprimirse y hacerlo de la manera correcta, ya que la seguridad puede crear un efecto dominó cuando no se hace correctamente.

Espero que se realice una integración completa entre IS4 y ASP para admitir AMBAS API web y MVC.

En estos días, la autenticación / autorización de fuerza industrial se requiere como mínimo. El código abierto (OSS) está bien para la mayoría de las cosas, pero ha habido serios recelos en algunos productos de seguridad de OSS que no son aceptables en ningún sitio web empresarial. El 85% de los proyectos utilizan bibliotecas obsoletas que representan un riesgo de seguridad inaceptable. Por ejemplo, el 45% de los servidores web utilizan Apache (https://www.cvedetails.com/vendor/45/Apache.html), que tiene muchas más vulnerabilidades que IIS (https://www.cvedetails.com/product/3436/ Microsoft-IIS.html? Vendor_id = 26). Los productos como Identity Server pueden estar bien, pero los ajustes del desarrollador pueden hacerlos completamente inseguros. Necesitamos una solución integrada en Net Core que sea siempre segura ...

En estos días, la autenticación / autorización de fuerza industrial se requiere como mínimo. El código abierto (OSS) está bien para la mayoría de las cosas, pero ha habido serios recelos en algunos productos de seguridad de OSS que no son aceptables en ningún sitio web empresarial. El 85% de los proyectos utilizan bibliotecas obsoletas que representan un riesgo de seguridad inaceptable. Por ejemplo, el 45% de los servidores web utilizan Apache (https://www.cvedetails.com/vendor/45/Apache.html), que tiene muchas más vulnerabilidades que IIS (https://www.cvedetails.com/product/3436/ Microsoft-IIS.html? Vendor_id = 26). Los productos como Identity Server pueden estar bien, pero los ajustes del desarrollador pueden hacerlos completamente inseguros. Necesitamos una solución integrada en Net Core que sea siempre segura ...

Tu punto es absolutamente correcto. Pero en algunos videos, el personal de MS dijo que no van a reinventar las ruedas [de seguridad] y usar un sistema de terceros [IS4]. Así que espero que esta sea una situación en la que todos ganemos.

En estos días, la autenticación / autorización de fuerza industrial se requiere como mínimo. El código abierto (OSS) está bien para la mayoría de las cosas, pero ha habido serios recelos en algunos productos de seguridad de OSS que no son aceptables en ningún sitio web empresarial. El 85% de los proyectos utilizan bibliotecas obsoletas que representan un riesgo de seguridad inaceptable. Por ejemplo, el 45% de los servidores web utilizan Apache (https://www.cvedetails.com/vendor/45/Apache.html), que tiene muchas más vulnerabilidades que IIS (https://www.cvedetails.com/product/3436/ Microsoft-IIS.html? Vendor_id = 26). Los productos como Identity Server pueden estar bien, pero los ajustes del desarrollador pueden hacerlos completamente inseguros. Necesitamos una solución integrada en Net Core que sea siempre segura ...

Nada es "siempre seguro", especialmente nada de Microsoft;)
Siempre está en manos del usuario de estas cosas hacerlas y mantenerlas seguras.

IdentityServer se incluirá en las nuevas plantillas de envío post 2.2. El enfoque inicial será el control de acceso a la API, pero hay planes para expandirlo en el futuro.

ASP.NET Core se enviará con una API de configuración simplificada que cubre solo los escenarios de la plantilla, pero será muy fácil comenzar. En cualquier momento, puede realizar la transición al sistema de configuración nativo de IS, que le brinda escenarios avanzados.

IdentityServer se incluirá en las nuevas plantillas de envío post 2.2. El enfoque inicial será el control de acceso a la API, pero hay planes para expandirlo en el futuro.

ASP.NET Core se enviará con una API de configuración simplificada que cubre solo los escenarios de la plantilla, pero será muy fácil comenzar. En cualquier momento, puede realizar la transición al sistema de configuración nativo de IS, que le brinda escenarios avanzados.

Gracias por la información Dominick;
Creo que este "trampolín" ayudará a muchos a comenzar y luego hacer la transición a un IS completo. Buen movimiento.

IdentityServer se incluirá en las nuevas plantillas de envío post 2.2. El enfoque inicial será el control de acceso a la API, pero hay planes para expandirlo en el futuro.

ASP.NET Core se enviará con una API de configuración simplificada que cubre solo los escenarios de la plantilla, pero será muy fácil comenzar. En cualquier momento, puede realizar la transición al sistema de configuración nativo de IS, que le brinda escenarios avanzados.

¡Bueno saber! Gracias.

Supongo que este control de acceso a la API se basará en los alcances de OAuth.
¿No hay soporte directo para permisos de usuario más volátiles como se describe en policyserver.io?

IdentityServer se incluirá en las nuevas plantillas de envío post 2.2. El enfoque inicial será el control de acceso a la API, pero hay planes para expandirlo en el futuro.
ASP.NET Core se enviará con una API de configuración simplificada que cubre solo los escenarios de la plantilla, pero será muy fácil comenzar. En cualquier momento, puede realizar la transición al sistema de configuración nativo de IS, que le brinda escenarios avanzados.

¡Bueno saber! Gracias.

Supongo que este control de acceso a la API se basará en los alcances de OAuth.
¿No hay soporte directo para permisos de usuario más volátiles como se describe en policyserver.io?

PolicyServer es una solución comercial

Supongo que este control de acceso a la API se basará en los alcances de OAuth.
¿No hay soporte directo para permisos de usuario más volátiles como se describe en policyserver.io?

"Sólo" IdentityServer. ASP.NET Core tiene una API incorporada para la autorización del usuario, y si PolicyServer (el producto) le parece interesante, hágamelo saber.

Cerrando este problema porque se ha enviado ASP.NET Core 2.2.

¿No debería actualizarse a ASP 3.0?

¿Alguna actualización sobre cuándo se enviarán las mejoras del servidor de autorización?