Qu'en est-il de la feuille de route EF Core 2.2 ?

Qu'en est-il de la feuille de route EF Core 2.2 ?

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

La feuille de route semble bonne, en particulier les vérifications de l'état et HTTP 2.0. Cependant, de la manière la

Mettre à jour

Dans le standup de la communauté ASP.NET, il a été mentionné que l'équipe ASP.NET Core discutait avec l'équipe Identity Server des options, notamment la création de quelque chose au-dessus d'Identity Server. Je pense que c'est ce que nous voulons tous, bravo !

Quels sont les plans actuels concernant les WebHooks ASP.NET Core ?

Concernant le dispatcher, cela sera-t-il possible dans le middleware alors ? ??
C# public async Task Invoke(HttpContext context, [FromRoute] SomeModel someModel)
^{[À partir de la requête] ?}

Simple Auth Server mais rappelez-vous aussi ce qui s'est passé avec Katana simple Auth Server

Je veux faire écho aux préoccupations de @RehanSaeed et j'aimerais demander des éclaircissements sur les cas d'utilisation exacts que ce nouveau serveur est censé remplir. Si c'est principalement pour que les API Web aient un moyen d'obtenir leur jeton de support qui soit valide dans l'authentification existante de l'application, alors ce serait bien. Mais tout en plus de cela est probablement mieux laissé aux solutions existantes qui offrent déjà de nombreuses options de complexité et de flexibilité différentes avec des produits comme IdentityServer, OpenIddict et AspNet.Security.OpenIdConnect.Server.

Qu'en est -il de l'hébergement in-process IIS ?

Pourriez-vous en dire plus sur la partie TypeScript de la « génération de client API (C# et TypeScript) » ?

Ce serait vraiment quelque chose que j'attendrais avec impatience. Actuellement, j'utilise NSwag pour générer automatiquement mes services d'API client angulaire. Mais il y a tellement de combinaisons différentes possibles pour les configurations client que je pense que cela pourrait être problématique pour plaire à tout le monde.

Juste au-dessus de ma tête, quelque chose qui devrait être pris en compte (et si possible devrait être configurable):

• Juste un client TypeScript avec fetch ou un service angulaire avec HttpClient ?
• S'il s'agit d'Angular, quelles versions prenez-vous en charge (également important pour RxJS) ?
• gestion nulle/indéfinie
• traitement enum
• Date JS ou momentjs pour les types de date ?
• Gestion des exceptions, Gestion des erreurs de validation
• Comment étendre le code généré dans le client ?
• Possibilité d'influencer la génération de nom (par exemple en supprimant la partie DTO de xxxDTO pour les classes client générées ou déjà à la définition OpenAPI)

S'il était possible de voter pour des fonctionnalités, ces améliorations/corrections apportées au middleware existant seraient sur ma liste de souhaits :

• Lets Encrypt prend en charge https://github.com/aspnet/Home/issues/1190.
• Le middleware Response Cache n'est fondamentalement pas utilisable comme il l'est aujourd'hui. L'ajout d'un magasin de cache de réponse Redis et l' extensibilité des opérations utilisateur des réponses mises en cache devraient résoudre https://github.com/aspnet/Home/issues/2606.
• Prise en charge de la diffusion de fichiers encodés pré-GZIP et pré-BR .
• Ajoutez un fournisseur de compression Brotli et corrigez plusieurs problèmes avec le middleware de compression de réponse.

Je vote également pour ignorer le produit Authorization Server. La sécurité est compliquée et il y a eu une forte poussée pour passer aux services cloud pour supprimer la maintenance, et quiconque souhaite plus de contrôle peut déjà utiliser IdentityServer4 qui est bien construit, testé, documenté et pris en charge. Une configuration simple prend 5 minutes et ils ont beaucoup d'échantillons de démarrage, de vidéos et de didacticiels.

Je ne vois pas comment vous pouvez faire fonctionner la sécurité en tant que "configuration zéro" plus qu'eux. Il semble que cela ne fera qu'ajouter plus de confusion (dans la dénomination et l'utilisation), tout en devenant une autre chose à prendre en charge et à maintenir pendant des années, en supprimant continuellement les efforts des autres fonctionnalités. Veuillez repenser ceci.

Je suis également curieux de savoir pourquoi l'hébergement en cours IIS ne figure pas sur cette feuille de route 2.2. Ceci est une caractéristique importante et est un facteur important dans notre stratégie de diffusion et horaires ici au débordement de la pile et il a été déjà enlevé toute dernière minute avant la version 2.1, promettant un délai 2.2 à la

Edit: @DamianEdwards a répondu sur Twitter qu'il s'agissait bien d'un oubli (ce qui signifie que c'est prévu pour 2.2). Phew!

Je ferai écho aux autres commentaires. Si vous envisagez d'investir dans l'autorisation/la politique, en particulier pour simplifier les choses, je préférerais personnellement de loin un partenariat avec OpenIddict et IdentityServer sur les documents et les investissements dans l'échafaudage. Je ne peux m'empêcher de penser que tout travail, aussi simple soit-il, finira par dupliquer de formidables efforts de tiers et entraîner des coûts de maintenance inutiles pour l'équipe aspnet.

C'est peut-être un point de vue impopulaire, mais j'aimerais voir un serveur Microsoft Auth, construit aux yeux du public, avec notre contribution et notre soutien.

Les projets actuels - Id4, OpenIddict - sont évidemment d'excellents projets OSS, et je ne peux m'empêcher de penser qu'un projet avec le soutien de MS pourrait être une mauvaise chose...?

Il y a une limite à la quantité d'assistance disponible pour un petit groupe de personnes, et ce sont des produits essentiels à la mission après tout.

Je pense qu'il est dommage que le code de conduite de MS OSS n'inclue pas une ligne qui dit "Ne faites pas la promotion de fonctionnalités qui dupliquent quelque chose qui peut être apporté avec une demande Nuget et qui écrasera avec désinvolture une entreprise à deux qui contribue à notre écosystème".

Le cynique en moi ne peut s'empêcher de se demander si, pour certains initiés, donner à Brock et Dominick un nez en sang était une caractéristique de cette suggestion plutôt qu'un bug. Est-ce ce qui arrive aux petites entreprises qui ont jamais la témérité de critiquer tout ce que fait l'équipe ASP ?

Je me pose également la question de la duplication de la fonctionnalité d'authentification autre que la construction de quelque chose au-dessus, comme les interfaces utilisateur et la documentation.

De plus, une bibliothèque JSON-LD 1.1 bien testée serait un ajout intéressant et spécifique à la feuille de route. :)

En répétant ce que d'autres ont dit, je préférerais de loin que le travail d'autorisation soit apporté par quelque chose comme IdentityServer4 que mis en œuvre à nouveau par vous-mêmes. S'il y a des lacunes, alors les combler par des contributions, des échantillons et des points d'intégration affinés serait une meilleure façon de procéder. Faites peut-être aussi attention à votre offre cloud dans cet espace (B2C) qui est dans un état déplorable.

Au-delà de cela, alors que vous indiquez que l'objectif n'est pas de reproduire la fonctionnalité dans les offres open source existantes et de garder les choses simples, cela équivaut en quelque sorte au piège de la réécriture classique : « cette solution est trop complexe et un peu brouillonne, réécrivons-la ! ". C'est naïf et dans n versions, je mettrais de l'argent sur vous pour avoir traité les nombreux cas extrêmes que les solutions du monde réel nécessitent et que quelque chose comme IdentityServer traite déjà.

Plus largement, avec l'acquisition de GitHub, il y a eu beaucoup de discussions récemment autour de l'attitude de Microsoft envers l'open source. C'est formidable que Microsoft fasse autant de travail en open source, mais pour être un bon citoyen open source, il faut tirer parti de l'open source existant lorsqu'il existe.

Ceci est particulièrement important pour les détenteurs de plate-forme tels que vous - un détenteur de plate-forme dupliquant des fonctionnalités dans des offres open source existantes _décourage_ les contributions tout en s'engageant avec ces offres _encourage_ les contributions.

Moi non plus, je ne vois pas l'intérêt des efforts déployés pour l'autorisation, mais j'aimerais voir la _gestion_ d'ASP.NET Core Identity améliorée. Damian Edwards a été assez clair sur live.asp.net que nous ne devrions pas déployer notre propre sécurité mais - à moins que je ne l'aie manqué - ASP.NET Core Identity ne contient aucun outil de gestion des utilisateurs et nous devons donc déployer notre propre. Je trouve cela un peu terrifiant car je ne suis pas un expert en sécurité et j'ai mortellement peur de laisser un trou de sécurité de ma propre fabrication.

Que diriez-vous de déplacer les formateurs de contenu du niveau MVC vers les abstractions AspNetCore.Http en 2.2 ?

Peut-être que le PM responsable pourrait rédiger une description plus détaillée de cet Identity Server Lite pour préciser exactement les lacunes des solutions open source tierces existantes que l'équipe ASP.NET cherche à combler. Parce qu'en l'état, vous parlez de réinventer une roue mais peut-être de supprimer des rayons, et cela n'a pas beaucoup de sens. Comme quelqu'un d'autre l'a dit, réparer AAD B2C et fournir une intégration de première classe avec cela serait formidable et aurait un sens commercial pour MS.

De plus, avez-vous même pensé à quel point il sera difficile d'obtenir un nouveau produit de serveur Auth de base après @blowdart ?

Avez-vous l'intention d'avoir un support API RESTful intégré comme celui de Django ?
Parce que c'est quelque chose que tous les développeurs ont tendance à écrire à chaque fois !

J'ai récemment construit quelque chose qui pourrait être écrit en tant que contrôleur d'API RESTful générique :

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

Je suis également d'accord avec "Je ne vois pas comment vous pouvez faire fonctionner la sécurité en tant que "configuration zéro" plus qu'ils ne le peuvent" et "vous parlez de réinventer une roue mais peut-être de supprimer certains rayons", le serveur d'identité est un produit génial, très simple à utiliser et offre une extensibilité pour des scénarios plus compliqués, je ne sais pas pourquoi nous avons besoin d'une version "simplifiée".

À une échelle beaucoup plus petite, pourquoi avons-nous besoin d'une autre mise en œuvre du bilan de santé. Il existe déjà plusieurs solutions open source par exemple

• https://github.com/Xabaril/BeatPulse , comprend un tas de chèques pré-écrits et est même livré avec une interface utilisateur
• https://www.app-metrics.io/web-monitoring/aspnet-core/health/

Quelle sera la différence de fonctionnalité avec ceux-ci et qu'est-ce qui est fourni dans 2.2 ?

@0xRumple Les améliorations apportées à ApiController devraient aider à rendre cela moins verbeux en général. Mais non, vous ne verrez probablement pas quelque chose qui vous donne simplement une API CRUD pour vos entités par défaut. Une telle chose devrait faire beaucoup trop d'hypothèses sur votre DAL et votre autorisation.

Si vous suivez certains modèles dans votre application, il n'y a rien de mal à créer vos propres types de base ou conventions en 2.2 qui généraliseront le travail pour vous.

@kieronlanning

Les projets actuels - Id4, OpenIddict - sont évidemment d'excellents projets OSS, et je ne peux m'empêcher de penser qu'un projet avec le soutien de MS pourrait être une mauvaise chose...? Il y a une limite à la quantité d'assistance disponible pour un petit groupe de personnes, et ce sont des produits essentiels à la mission après tout.

Puisque vous avez demandé si cela pouvait être une mauvaise chose :

L'équipe ASP.NET est également relativement petite, servant des millions de développeurs avec une capacité limitée, donc tout nouveau projet prendra du temps et des efforts pour d'autres choses. Cela signifie que nous devons tous attendre plus longtemps pour obtenir de nouvelles fonctionnalités qui offriraient probablement plus de valeur.

Bien pire, cela nuit à l'écosystème tiers et décourage les nouveaux produits à cause de la publication par Microsoft d'un package "officiel", que de nombreuses entreprises sont obligées de choisir simplement parce qu'il provient de Microsoft, même si techniquement (et dans ce cas censé être) moins capable. ASP.NET intègre déjà Json.NET, Polly, AutoMapper et de nombreuses autres bibliothèques, il semble donc être un faux pas de reconstruire un produit de sécurité aussi complexe (qui nécessitera 80% du même code de base) alors que d'excellentes options existent déjà, et avec tant de choses plus intéressantes sur la feuille de route sur lesquelles travailler.

@poussée
Vous avez raison, écrire des classes de base de mes applications est une bonne idée.

En fait, je pense que cela ne fait pas partie des responsabilités du cadre :

CRUD resources (repository responsibility)

Manipulating data (sieve responsibility)
    Paging
    Filtering
    Searching
    Sorting
    Shaping

Mais il y a beaucoup de choses que je pensais que l' AspNetCore aurait pu faire mieux (en ayant un package AspNetCore.RestFramework):

1. HATEOAS (API auto-décelable)
2. Types de médias (configuration de types de médias personnalisés)
3. Gestion des versions (mettre à jour la version du type de média)
4. Métadonnées de données traitées (pagination dans l'en-tête X-Pagination, métadonnées de filtre... etc).
5. Limitation de débit et étranglement.

Je sais qu'il existe des tonnes de bibliothèques, j'en ai trouvé ici : https://github.com/thangchung/awesome-dotnet-core... Mais les bibliothèques tierces ne sont pas vraiment une bonne option pour les applications d'entreprise !

Il en va de même pour le tamis, s'il existe un package OFFICIEL pour la pagination, le filtrage... etc, les développeurs n'auront pas tendance à écrire des bibliothèques boguées ou non maintenues, j'ai utilisé ce tamis dans mon application que j'ai mentionnée ci-dessus : https:// github.com/Biarity/Sieve , mais cette bibliothèque peut ne pas être maintenue à chaque seconde où l'auteur est occupé.

Je pense qu'AspNetCore est suffisamment mature pour commencer à penser à des solutions prêtes à l'emploi comme dans Django, de cette façon nous pouvons avoir le luxe des performances asp et l' agilité de Django .

Mais les bibliothèques tierces ne sont pas vraiment une bonne option pour les applications d'entreprise !

^ C'est pour ça qu'on ne peut pas avoir de belles choses

Mais les bibliothèques tierces ne sont pas vraiment une bonne option pour les applications d'entreprise !

Oui, c'est exactement l'état d'esprit qui doit changer ici. ASP.NET Core et .NET Core sont open source et leur écosystème _est_ englobant la communauté open source et il devrait continuer à le faire. Non seulement avec les solutions open source qui font partie de la fondation .NET, mais vraiment toutes les solutions.

mais cette bibliothèque peut ne pas être maintenue à tout moment, l'auteur s'est occupé

Et de la même manière, un package "officiel" peut devenir non maintenu à chaque seconde où l'entreprise déplace son intérêt. Cela s'est déjà produit avec des choses spécifiques à Microsoft, y compris plusieurs packages open source qu'ils ont publiés, mais c'est vraiment naturel pour toute entreprise.

Si vous décidez de prendre une dépendance sur une autre bibliothèque, il est de votre responsabilité de pouvoir vivre avec cela. Peu importe qui en est l'auteur. La bonne chose à propos de l'open source est que même si l'auteur finit par ne pas répondre, vous avez pleinement le droit de le modifier vous-même.

Je suis fermement opposé à ce que vous attendiez des solutions Microsoft officielles pour tout ce que vous pourriez proposer. Non seulement parce qu'il n'y a jamais de solution universelle, ce qui rend cela très difficile et en même temps susceptible de devenir incontrôlable, mais surtout aussi parce que cela enlève des ressources à des parties du cadre qui ont vraiment besoin d'attention. Et en même temps , ça fait mal l'idée open source vraiment vraiment mauvais.

Si vous développez des applications d'entreprise et que vous êtes toujours aux prises avec ce syndrome du NIH (ou « non inventé dans une <grande entreprise> »), vous devriez vraiment vous réveiller car nous sommes en 2018 et vous devriez probablement adopter l'open source maintenant.

Vous avez raison, Microsoft peut arrêter de maintenir n'importe quel package mais au moins ils ont un LTS spécifique : https://www.microsoft.com/net/support/policy

Par exemple, la prise en charge de .NET Core 1.1 se termine le 27 juin 2019... de cette façon, je peux être sûr que si j'utilise cette version, je ne serai pas paralysé au milieu.

Une fois, j'ai utilisé un assistant de balise de pagination tiers, et ce n'était pas agréable, l'auteur m'a essentiellement dit qu'il ne le corrigerait pas pour .NET Core 1.1, et je devrais mettre à jour le projet, c'était un système universitaire, en 2.0 (et il a tout le droit de le faire car il a écrit ce paquet GRATUITEMENT).

Voici le problème, dans l'entreprise, cela ne fonctionne pas... vous ne pouvez pas convaincre toute l'équipe que vous devriez passer en 2.0 pendant que l'application est opérationnelle simplement parce que le pagination-tag-helper ne fonctionne pas. ça marche pas !
Il vous suffit donc de commencer à pirater la source comme je l'ai fait en utilisant un décorateur : https://github.com/cloudscribe/cloudscribe.Web.Pagination/issues/37

Et oui, qui a dit que je n'étais pas un grand fan de l'open-source :confused: ?

@0xRumple n'est-il pas l'idée de l'open source pour contribuer et collaborer ?

Si cet assistant de pagination tiers n'existait pas, vous devriez l'écrire vous-même et le maintenir de toute façon, "dans l'entreprise".

Voici le problème, dans l'entreprise, cela ne fonctionne pas... vous ne pouvez pas convaincre toute l'équipe que vous devriez passer en 2.0 pendant que l'application est opérationnelle simplement parce que le pagination-tag-helper ne fonctionne pas. ça marche pas !

Plutôt que d'essayer de "convaincre toute l'équipe que vous devriez passer à la version 2.0", contribuez une mise à jour et aidez plutôt que de compter sur quelqu'un d'autre pour faire le travail ou d'attendre que Microsoft fournisse un équivalent. Si le propriétaire ne veut pas accepter votre contribution, avancez avec une fourchette pour vos besoins.

Je suppose que votre type de pensée (sans vouloir vous offenser du tout) explique en grande partie pourquoi il y a une discussion autour du "serveur d'autorisation Microsoft" par rapport au serveur d'identité. Comment l'open source fonctionnera-t-il si les développeurs ne veulent pas participer. Doit-on attendre que Microsoft fournisse tout le code dont nous avons besoin ?

Je suis d'accord avec beaucoup ici pour dire que Microsoft doit faire attention à ne pas tuer les bons projets open source dans l'écosystème en faisant leurs propres remplacements pour tout.

Je suis en fait l'auteur de la bibliothèque de taghelper de pagination mentionnée par @0xRumple , son problème était vraiment avec un composant de liste de pages et non avec le taghelper qui a en fait un ancien nuget qui prend en charge le noyau 1.x aspnet. La liste paginée était vraiment quelque chose qui faisait partie d'une bibliothèque de pager open source précédente qui a informé la conception de ma bibliothèque et a été utilisée dans les pages de démonstration à un moment donné, mais le taghelper de pager ne dépendait pas de l'implémentation de la liste paginée et il y a d'autres pages lister les implémentations qu'il aurait pu utiliser tout en utilisant le taghelper du pager. En fait, j'ai depuis supprimé entièrement la liste paginée de cette bibliothèque car elle ne fait même pas partie du taghelper et ne l'a jamais été.

L'utilisation des packages nuget des développeurs OSS n'est vraiment pas différente de celle de Microsoft en ce sens que si vous êtes bloqué sur aspnet core 1.1, vous ne pouvez pas obtenir de correctifs et d'améliorations à partir d'aspnet core 2.x à moins que vous ne mettiez à jour le nouveau framework.

@joeaudette
Je viens de mentionner cet exemple pour illustrer mon propos sur les solutions intégrées par rapport aux solutions tierces, je suis toujours reconnaissant pour votre travail sur ce taghelper de pagination... l'université utilise votre package de pagination et ils sont heureux :heart:

@alhardy

Doit-on attendre que Microsoft fournisse tout le code dont nous avons besoin ?

C'est le problème principal, nous pensons que lorsque Microsoft apporte une solution officielle, ils combattront toute autre solution open source ou ils écriront chaque ligne de code par eux-mêmes :smile:

Bien sûr que non, nous pouvons le meilleur des deux mondes, une solution officielle et une communautaire si Microsoft adopte les bonnes solutions et crée les solutions manquantes, afin que les développeurs puissent se concentrer pour contribuer à celles-ci.

La communauté django a bien compris, elle fournit/adopte officiellement la solution simple initiale pour un problème spécifique, par exemple le framework RESTful, et la communauté s'appuie sur cela... regardez ici leur étape initiale de construction de django-rest- cadre : https://www.djangoproject.com/weblog/2016/jun/22/django-rest-framework-funding/

Ils ont commencé le projet initial, et la communauté s'améliore/construit en plus de ça, voici leur repo :
Et la communauté est amenée à créer des packages qui résolvent les problèmes en plus de ce package comme django-rest-auth ou django-rest-framework-jwt .

Au moins, ils fournissent des "solutions officielles" dont la plupart des développeurs ont besoin, comme django-admin-site ou django-debug-toolbar . Cela vient également de la philosophie Python des "batteries incluses", au début, je pensais que c'était mauvais car il s'efforce de trouver des solutions au plus petit dénominateur commun, et j'ai réalisé plus tard la brise qu'il apporte.

*PS : Dapper (par StackExchange) et EFCore (par Microsoft) sont tous deux des ORM, mais ils visent à résoudre le même problème dans des approches différentes. Dapper a été initialement créé en 2011 tandis que EFCore 2014... EFCore a-t-il eu un impact négatif sur les projets open-source ? bien sûr que non, et c'est pourtant une solution officielle !
Les gens construisent déjà sur ces trucs incroyables, comme ceci : https://github.com/crhairr/EntityFrameworkCore.MongoDb/

EFCore a-t-il mal affecté les projets open-source ?

Uuuh, quelqu'un se souvient de NHibernate (qui est le plus proche de EF en termes de fonctionnalité) ? Non, probablement pas, car c'est presque mort après la sortie d'EF 😕

@0xRumple

Bien sûr que non, nous pouvons le meilleur des deux mondes, une solution officielle et une solution communautaire si Microsoft adopte les bonnes solutions et crée les solutions manquantes,

Dans ce cas, ce n'est pas non plus parce qu'il s'agit de recréer une solution existante, mais avec volontairement moins de fonctionnalités.

Entity Framework et Dapper sont très différents. EF a toujours été conçu pour être un ORM complet, et les deux sont venus des années après l'original Linq-To-SQL en 2007 .

Cependant, je ne pense pas que vous ayez tort non plus et il semble que nous nous parlions tous les uns des autres. Le fil est principalement des commentaires sur le produit du serveur d'authentification alors que vous parlez des bibliothèques liées à REST, qui semblent suffisamment petites et ciblées pour être incluses dans un cadre Web. Je suis d'accord qu'il serait utile d'avoir des paramètres standardisés search/paging/filter pour le code de l'API Web.

Cette discussion ne reconnaît pas la vérité embarrassante selon laquelle dans certaines organisations, les développeurs doivent tenir compte de chaque package open source introduit dans leur solution. Dans certains cas, il s'agit d'une analyse automatique qui produira des rapports de « Risques » que fréquemment un gestionnaire de risques non technique devra examiner. Ces outils signaleront tout ce qui n'est pas activement maintenu et tout ce qui ressemble à une licence copyleft.

Vous pouvez également imaginer que dans ces organisations, contribuer à l'open source est considéré comme un discours fou.

Oui, Identity Server 4 est incroyable. Mais pour un gestionnaire de risques non technique, c'est quelque chose pour lequel nous n'avons pas de garantie, quelque chose pris en charge par une poignée de personnes et pire encore - quelque chose avec le code source disponible pour tout le monde. Cette personne est malavisée mais le développeur moyen sur le terrain ne va pas gagner ce combat.

Un « Identity Server Lite », comme le dit si bien

@edandersen

Mais pour un gestionnaire de risques non technique, c'est quelque chose pour lequel nous n'avons pas de garantie, quelque chose pris en charge par une poignée de personnes et pire encore - quelque chose avec le code source disponible pour tout le monde.

Je suis presque sûr que les gens d'IdentityServer fourniraient une assistance si vous les payiez pour cela - tout comme vous paieriez Microsoft. OSS n'est pas synonyme de gratuité.

Qu'est-ce qui vous fait penser que l'équipe ASP.NET Core de Microsoft n'est pas « une poignée de personnes » ? Spoiler... ils sont comme 20-30 personnes au total. Seul un couple travaillerait sur un produit comme celui-là.

Je suis vraiment curieux de savoir pourquoi "le code source accessible à tous" est une mauvaise chose ? Et qu'est-ce qui vous fait penser que ce produit chez Microsoft ne sera pas open source ? C'est la nouvelle valeur par défaut.

@khellang "le code source accessible à tous" pour être clair, c'est une bonne chose ! Mais vous seriez surpris des arguments que certains développeurs doivent avoir au travail. Le point "Microsoft l'a écrit" est malheureusement le seul argument acceptable parfois. Notez que je joue l'avocat du diable pour une entreprise dysfonctionnelle hypothétique mais typique.

Et bien sûr, les mêmes développeurs pourraient préconiser que leur employeur paie pour le support d'Identity Server, mais le processus d'approvisionnement les privera probablement de la volonté de vivre.

Eh bien, si nous commençons à utiliser ces arguments de managers non technologiques, les choses vont commencer à devenir folles. À mon humble avis, les personnes qui ne sont pas techniques, ne devraient pas dicter ce qui doit être utilisé ou non. S'ils veulent avoir un dicton, ils devraient au moins savoir de quoi ils parlent, et dire qu'un package bien connu comme IdentityServer est de moins bonne qualité qu'un package MS, pour moi, c'est tout à fait faux. Je fuirais une entreprise comme ça !

Mais le fait est que pratiquement tout le monde s'accorde à dire que passer du temps sur quelque chose qui existe déjà, c'est solide et BEAUCOUP de gens l'utilisent, c'est un peu étrange. Je me demande quelle est la vraie raison derrière cela. Je ne pense pas que c'était comme : Oh, construisons notre propre truc, juste parce que nous le pouvons. Les clients demandent-ils réellement cela dont nous ne sommes peut-être pas au courant ?

Personnellement, je ne vois pas un autre concurrent dans l'espace OAuth-Server comme un problème, mais une bonne chose.

Cela peut aider à stimuler le développement dans ce domaine, ou simplement servir de solution rapide et sale pour les personnes qui n'ont besoin de rien de plus - une solution rapide et sale.

Si vous voulez ou avez besoin de plus d'un serveur OAuth, rien n'empêche aucun d'entre nous d'utiliser les solutions existantes. Ou, si vous voulez un modèle en un clic pour faire OAuth de base _et rien de plus_, alors cela semble être un objectif louable, du moins pour moi.

Je pense que ce fil s'est transformé en un tit-for-tat sur ce qu'est l'OSS, ce que MS est bon à faire et ce à quoi MS n'est pas bon, plutôt que de se concentrer sur ce qui est sur la feuille de route pour .NET Core 2.2, ce qui est vraiment importe ici.

@khellang
"NHibernate est mort", a dit qui ? Je vois que le projet est toujours vivant, et a même une meilleure dynamique que Dapper
https://github.com/nhibernate/nhibernate-core/graphs/contributors
https://github.com/StackExchange/Dapper/graphs/contributors

Ah, je n'ai pas mentionné IdentityServer jusqu'à présent pour rester sur mon point d'avoir un cadre RESTful dans les packages aspcore officiels ... voici mes réflexions sur IdentityServer, c'est vraiment solide et génial, MAIS c'est un projet à 2 personnes, regarde les métriques :
https://github.com/IdentityServer/IdentityServer4/graphs/contributors

Environ 85% du travail est effectué par 2 personnes et c'est bien pour un projet lié à la sécurité, mais dans l'entreprise, de nombreuses entreprises réfléchissent à la maintenabilité de tels projets à l'avenir. Récemment, une entreprise m'a dit qu'elle voulait que j'utilise React au lieu de Vus.Js dans son projet simplement parce qu'elle a dit "vue.js est à peu près Evan You"... et je pense qu'elle a raison. Et c'est ce que j'essaie de dire depuis le début de la discussion sur le fait d'avoir un package RESTful dans les packages officiels, aucune grande entreprise n'acceptera que vous utilisiez un package "potentiel" non maintenu sur leurs projets.

Il en va de même pour la manipulation / tamisage des données (pagination, mise en forme, tri, etc.) car presque tous les projets contiennent ces exigences, et oui, comme l' a dit

@manigandham
C'est exactement ce que je pense être juste... adapter et soutenir officiellement les solutions, que ce soit financièrement ou en contribuant via github ou au moins en les mentionnant dans leurs docs ou leurs cours (j'ai déjà vu Hanselman mentionner SwashBuckle dans l'un de ses cours chez Microsoft Virtual Academy qui est vraiment géniale, et ce serait mieux de voir plus d'adaptation à de tels projets !).

@kieronlanning
Vous avez raison, nous sommes allés trop loin du sujet principal ... mais comme je l' ai mentionné, le noyau de asp juste obtenu très mature (et fiable performant), et je pense qu'il est temps de commencer par le hors-la solutions de boîte .

Je pense qu'ignorer un projet parce qu'il a deux contributeurs principaux est sacrément idiot. IS4 est très bien entretenu et ces deux gars passent beaucoup de temps à répondre aux questions et à aider les gens. Il est également largement considéré comme l'une des meilleures solutions FOSS pour un serveur OAuth2 sur le marché.

"NHibernate est mort", a dit qui ? Je vois que le projet est toujours vivant, et a même une meilleure dynamique que Dapper

@0xRumple J'ai dit "comme mort" 😉 Vous semblez avoir des mesures très étranges sur la santé et l'utilisation des projets OSS. Est-il juste de comparer le nombre de commits sur un projet de 2003 à celui qui est en cours depuis 2011 ? Ce sont aussi des bêtes _très_ différentes (comme indiqué plus haut dans le fil); Dapper est "complet" (cela ne veut pas dire non entretenu, abandonné, etc.) depuis un certain temps, tandis que NHibernate (et son ensemble de fonctionnalités) est à la traîne.
Je sais que le projet avance toujours, mais je ne me souviens pas de la dernière fois, au cours de mes 7 dernières années de consultation dans l'espace .NET, où j'ai rencontré NHibernate dans la nature (où il n'était pas en train de en cours de migration vers Entity Framework). Tous ceux qui ont suivi cet espace au cours des deux dernières années savent très bien que NHibernate est à la traîne et perd des parts de marché au profit d'Entity Framework. Il suffit de regarder les numéros de téléchargement de NuGet : Entity Framework a 45,8 millions contre NHibernate avec 3,4 millions.

Quoi qu'il en soit, le point n'est pas Entity Framework vs NHibernate. C'était juste un exemple. Nous avons eu cette discussion maintes et maintes fois; plus récemment, lorsque Microsoft a déployé sa propre implémentation de conteneur IoC léger dans ASP.NET Core ou lorsque Microsoft envisageait de déployer son propre mappeur d'objets. Chaque fois que Microsoft entre dans un espace de la communauté OSS, il aspire une grande partie (la plupart ?) de l'air hors de la pièce. Assez souvent pour que les petits projets communautaires s'étouffent avec le temps. Moi, et la plupart de la communauté, le savons trop bien ; il est impossible de rivaliser avec Microsoft dans le monde de Microsoft (.NET). Je comprends parfaitement qu'ils ont des clients payants qu'ils doivent satisfaire, donc je ne m'attends pas à ce que ces commentaires les fassent changer d'avis :sourire:

Fonctionnalités géniales :)

Où puis-je obtenir plus d'informations sur la fonction Bilan de santé ?

Améliorer la gestion des certificats auto-signés

Lors du développement d'applications Web qui appellent des API Web associées, il arrive un moment où il est utile de les tester avec des utilisateurs internes sur le réseau local. Vous avez peut-être réussi tous les tests unitaires, fonctionnels et d'intégration, mais il n'y a rien de tel qu'un humain pour vraiment casser des choses.

Dans l'esprit des préoccupations de découplage, mes applications Web appellent plusieurs API Web. Dans un premier temps, je développe ces API Web en utilisant https://localhost :. Une fois qu'une API Web est prête (assez), je la publie ensuite sur IIS sur ma machine locale. Chaque site a un nom d'hôte approprié que j'ai configuré sur mon serveur DNS interne. À ce stade, j'utilise Barry Dorrans - @blowdart - gist https://gist.github.com/blowdart/1cb907b68ed56bcf8498c16faff4221c pour créer un certificat de serveur. Pourvu que j'importe les certificats dans tous les bons magasins, tout fonctionne sur ma machine sans alarme.

Cela change lorsque d'autres personnes sur le réseau accèdent aux applications Web (les appels d'API se trouvent tous dans ma boîte de développement). Des avertissements graves sont reçus par l'utilisateur. Je leur dis d'ignorer ces avertissements et, si possible et suffisamment simple, d'importer les certificats. Étant donné que ces certificats auto-signés ont le même nom d'émetteur et le même nom commun, chaque nouvelle application Web déclenche une page d'avertissement

Je ne peux m'empêcher de penser que demander aux utilisateurs de son organisation de consulter des pages d'avertissement est une mauvaise idée.

En tant que non-spécialiste de la sécurité, il y a deux ou trois choses que j'aimerais voir :

• la possibilité d'avoir un certificat racine local pour tous les certificats de développement que je crée, puis d'être informé d'un moyen autorisé de l'importer dans des PC, des Mac, des appareils Android, iPad et iPhone, afin que ces pages alarmantes ne se produisent plus

• une méthode plus simple de génération de certificats pour les API pouvant être utilisées avec IIS et Kestrel qui remplit correctement tous les magasins de certificats appropriés

@CrispinH Pour être honnête, soutenir une autorité de certification racine serait, eh bien, une préoccupation de faire tourner une autorité de certification racine. Si vous en êtes à ce stade, il est temps d'envisager de créer vous-même une autorité de certification racine et de la gérer. Le support auto-signé, que ce soit l'outil global ou mon script est juste pour ça, le développement. Une fois que vous commencez à laisser les gens s'y attacher, vous êtes hors de portée de cette fonctionnalité. Si vous êtes dans une organisation et que vous souhaitez que les gens accèdent aux services, l'organisation doit déterminer sa stratégie de certificat, exécuter une autorité de certification interne via Windows ou OpenSSL et pousser la racine via la stratégie AD ou d'autres moyens.

@blowdart L'une des raisons de mon ennui était que j'avais passé quelques jours à essayer de créer une autorité de certification racine et que je n'avais pas réussi à bien faire les choses malgré mon manque de compétence dans ce domaine. J'ai même essayé de trouver comment modifier votre essence pour accepter une autorité de certification racine locale.
Toute la documentation que j'ai trouvée était beaucoup trop générale - tout ce que je voulais, c'était un processus de création de certificats (idéalement basé sur une autorité de certification racine) uniquement pour protéger les API et les applications Web avec un certificat de serveur. Peut-être qu'une documentation sur des cas spécifiques est tout ce dont vous avez besoin.

@CrispinH Window Server est livré avec une autorité de certification que vous pouvez configurer, si vous voulez aller jusqu'au bout.

Les certificats en général ne sont pas un sujet facile et vous devrez apprendre un peu pour le faire correctement.

À des fins de développement, les certificats auto-signés sont parfaitement adaptés et faciles à utiliser. Tout au-delà de cela, y compris la configuration et la gestion d'une autorité de certification, n'est plus à des fins de développement et est définitivement hors de portée et beaucoup trop complexe pour un cadre d'application Web.

@CrispinH Comme @poke l'a dit, il est difficile de bien faire les choses. Une fois que vous avez des machines faisant confiance à une autorité de certification racine, tous les certificats émis seront approuvés, et les développeurs exécutent du code non fiable sur leurs boîtes de développement, c'est ce que sont les packages nuget après tout. Considérez donc quelque chose qui vole votre autorité de certification racine. Dans la vraie vie, les autorités de certification racine ont tendance à être maintenues hors ligne, elles signent un deuxième certificat, qui est limité dans ce qu'il peut faire, les certificats serveur et client généralement, puis les certificats sont émis par cela, par confiance, de nombreuses autorités de développement sont limitées, donc compromis signifierait la capacité d'émettre des certificats de signature de code de confiance. Sans vouloir être horriblement insultant un CA, ce n'est pas quelque chose qu'un développeur devrait diriger, il vaut mieux le laisser à ceux qui comprennent les conséquences, et les conséquences peuvent être désastreuses. Ensuite, il y a la rotation des certificats, la révocation, OCSP et plus encore à prendre en compte. Je dois avoir une autorité de certification de test pour mon middleware d'authentification de certificat, et elle se trouve dans une machine virtuelle qui est désactivée. Je deviens très nerveux quand je l'allume pour obtenir plus de certificats de test.

Si vous voulez vraiment, vraiment, descendre cette racine (jeu de mots) alors https://infiniteloop.io/powershell-self-signed-certificate-via-self-signed-root-ca/ pourrait vous aider à démarrer dans powershell, mais cela ne vous donne aucune prise en charge de CRL ou OCSP ou de révocation. https://gist.github.com/Soarez/9688998 semble couvrir OpenSSL. Et si vous avez besoin de CRL, il y a le CA intégré à Windows, la configuration est documentée ici https://leastprivilege.com/2008/08/14/how-to-build-a-developmenttestdemo-ca/

_Notez que je n'ai utilisé aucun des liens ci-dessus (bien que je fasse confiance à l'auteur du dernier), et il ne s'agit en aucun cas d'une recommandation officielle de MSFT. La recommandation officielle de l'équipe de sécurité ASP.NET est de laisser quelqu'un qui comprend l'infrastructure et les risques mettre en place une autorité de certification d'entreprise pour vous. Parlez à votre service informatique_

@blowdart Non, je _ne_ veux vraiment pas_ descendre cette 'racine'. C'est bien de savoir pourquoi maintenant.

Il semble que mes tests humanoïdes devront être effectués sur l'Internet public sur un hôte de test à l'aide de certificats Let's Encrypt, mais avec un mur d'authentification en place pour éviter les regards indiscrets.

En fonction de vos besoins et de votre budget, certaines entreprises comme DigiCert proposent des services PKI managés. Cela peut utiliser une racine privée ou publique. Je ne connais pas les coûts.

Et s'il ne s'agit que de HTTPS, souvenez-vous que vous obtenez un certificat pour chaque sous-domaine azurewebsites.net.

Pesant sur la nouvelle implémentation OpenID, au lieu d'une autre implémentation pour apprendre, embrasser et s'engager avec les efforts de la communauté d'IdentityServer4 et contribuer à créer une version "Lite" d'IdentityServer qui pourrait être incluse à partir de nuget et configurée avec un minimum d'efforts.

Vous réagissez tous de manière excessive.
L'équipe ASP.NET pense déjà comme vous tous. @DamianEdwards en a parlé dans le dernier Community Standup.

Voici la partie la plus pertinente (mais je vous encourage à l'écouter en entier) :

"Nous en parlons actuellement avec les gens d'IdentityServer."
https://youtu.be/Tzh2EXwgEk8?t=25m15s

Vraiment intéressant de voir à quel point la discussion autour du projet "serveur d'autorisation MSFT" est passionnée :sourire:

Soit dit en passant, Vittorio Bertocci m'a contacté il y a exactement 2 ans pour discuter de ce projet car ils envisageaient d'utiliser OpenIddict (le serveur OIDC que je développe et entretiens) comme base pour ce projet.
L'année dernière, on m'a dit qu'ils préféraient utiliser leur propre implémentation plutôt que de tirer parti d'OSS tiers, car cela était considéré comme "trop ​​stratégique" d'un point de vue commercial (ce que je pouvais comprendre).

Je suis content de voir qu'ils ont changé d'avis et envisagent enfin d'utiliser une solution OSS existante comme IdentityServer4 au lieu de créer une autre chose à partir de zéro : c'est un très bon signal envoyé à la communauté .NET :clap:

Cela sort un peu du fil, mais @CrispinH , il semble que vous cherchiez un peu 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 inclut également d'autres fonctionnalités pour créer et utiliser des certificats. Consultez également les commentaires sur l'exécution d'une autorité de certification. L'outillage de la bibliothèque est presque là et en fonction de votre organisation, vous pourrez peut-être utiliser des certificats de manière contrôlée sur certains serveurs sans définir beaucoup d'intrastructure. Sur ce jeton, la lecture des demandes de signature de certificat (CSR) prêtes à l'emploi (encodées DER) serait un ajout intéressant, ainsi qu'une bibliothèque JSON-LD. Et plus de crypto en général. :)

J'aimerais voir un middleware comme la prise en charge de LetsEncrypt - fonctionnant avec App Services sous Windows, Linux et Docker dans Azure.

@kieronlanning Je suis d'accord, en plus de l'encodage DER en ce qui concerne la signature CSR mentionné précédemment (bien que l'ajout de la prise en charge sans cas extrêmes ne semble pas si difficile). Il existe quelques bibliothèques pour .NET (également répertoriées sur les pages Let's Encrypt), mais aussi quelques problèmes. Par exemple, le .NET le plus activement maintenu en ce qui concerne Let's Encryptc ressemble à Certes , mais il nécessite une dépendance de BouncyCastle . Ce serait bien si quelqu'un l'aidait à être .NET Standard 2.0 uniquement. Une des raisons pour moi est que BouncyCastle ne fonctionne pas bien avec Orleans TaskScheduler . :)

À propos de la mention crypto, bien qu'il ne s'agisse pas strictement d'un problème ASP.NET Core, MS semble pousser fortement sur les blockchains, mais .NET manque de capacité crypto. _À première vue_ cela a aussi beaucoup à voir avec le noyau ASP.NET (comme, par exemple, les différentes implémentations de l'explorateur de blockchain, telles que https://etherscan.io/) et ce serait bien d'avoir plus de support pour des bibliothèques comme Inferno et juste plus de capacités intégrées à la plate-forme. Un problème en suspens se trouve sur https://github.com/sdrapkin/SecurityDriven.Inferno/issues/10#issuecomment -395778931 (en prêtant quelques yeux ici si quelqu'un a les moyens d'aider).

Ceci de @kieronlanning serait ma demande de fonctionnalité numéro un :

"J'aimerais voir un middleware comme la prise en charge de LetsEncrypt."

Voici le problème ouvert : https://github.com/aspnet/Home/issues/1190. S'il vous plaît, allez-y et votez.

Est-il considéré que le messagepack est disponible sur le noyau asp.net pour tous les frameworks et pas seulement sur SignalR ? Étant donné que le cadrage Http2 est binaire, envisagez-vous un pack de messages pour cela?

serveur d'autorisation publié sur preview3?

Il existe déjà. Https://IdentityServer.io

@leastprivilege
J'aime et j'utilise IdentityServer
Mais je suis très curieux de voir l'implémentation de Microsoft et de comprendre pourquoi (microsoft) n'a pas intégré le serveur d'identité dans votre cœur

@danroth27 - pouvez-vous partager les dernières nouvelles ?

Microsoft utilise IdentityServer.

Alors comment ça marche ? Microsoft utilise directement le code IDS4 ? Microsoft réduit les fonctionnalités IDS4 ? C'est quoi le modèle ici ? Quelles devraient être nos attentes? Y a-t-il un chemin de migration possible entre eux ?

Microsoft utilisera notre package nuget standard et utilisera notre API de configuration pour vous donner des paramètres par défaut pour bien jouer avec le modèle et l'identité ASP.NET. C'est tout.

Vous pouvez déjà réaliser exactement la même chose aujourd'hui.

C'est probablement moi, mais je suis surpris de lire que la lacune du serveur d'autorisation Microsoft est comblée par IdentityServer4. Selon ma compréhension, la principale préoccupation d'IdentityServer est l'authentification, pas l'autorisation.

Pour moi, IdentityServer est bien comme serveur d'authentification, mais ne fonctionne pas comme serveur d'autorisation. J'ai supposé que c'était la raison pour laquelle PolicyServer avait été créé.

@leastprivilege IdentityServer sera-t-il étendu avec quelque chose comme PolicyServer ?

@Ruard Donc c'est déroutant (et Dominick va probablement grincer des dents ou choisir mon explication).

OAuth est une authentification, mais il a une autorisation comme première étape, puis délivre une autorisation basée sur des étendues, etc. Ainsi, dans notre encapsulation, Identity Server effectuera la connexion, la validera, validera les étendues requises (ce qui, dans le cas initial, toujours réussir car nous utilisons la portée par défaut), puis retransmettez un jeton à l'appelant, qui est ensuite envoyé à l'API qui le validera, puis, éventuellement, vous pouvez aller plus loin avec les règles d'autorisation au sein de l'API. OIDC fournit à OIDC la confusion supplémentaire en étant un moyen d'acquérir les informations d'identité d'un utilisateur, y compris l'autorisation que l'application est autorisée à les avoir ...

Donc, fondamentalement, Identity Server nous donnera une identité, autorisant que l'application est autorisée à l'avoir, puis vous pouvez utiliser les éléments d'autorisation d'ASP.NET pour contrôler davantage l'accès.

@MichelZ il y aura une histoire de grandir. Nous allons configurer pour des scénarios simples, et une fois que vous sortez de ceux-ci, vous pouvez explorer toute la puissance du modèle de configuration IdentityServer.

@blowdart Nous utilisons déjà IdentityServer (et sommes impressionnés par les capacités !), mais bénéficier des politiques de "support à long terme" de Microsoft est également un gros plus pour nous. Ainsi, quelles que soient les synergies que vous pouvez fournir ici, elles sont les bienvenues.
Nous aimons les deux produits, ASP.NET Core et IdentityServer (4) de la même manière. C'est définitivement un pas dans la bonne direction à mon humble avis.
Cependant, nous reconnaissons également que tous ces protocoles ne sont pas exactement "simples". Ils ne sont pas sorciers si vous les comprenez, mais ils ne sont quand même pas simples non plus.

J'aimerais que quelqu'un invente un protocole VRAIMENT simple, laissant derrière lui TOUTES les implémentations héritées et se concentrant sur l'avenir.

Si vous l'utilisez déjà, alors votre utilisation ne changera pas vraiment, vous l'avez fait fonctionner :)

Nous visons Fichier Nouveau > API Web avec authentification individuelle, puis nous ajoutons d'autres API, et tout est basé sur les conventions. Cela ne fonctionnera pas pour les applications existantes, car les conventions seront nouvelles. Je ne prévois pas de remplacer ta config par la nôtre :)

J'aimerais que quelqu'un invente un protocole VRAIMENT simple, laissant derrière lui TOUTES les implémentations héritées et se concentrant sur l'avenir.

C'est le problème - les applications deviennent plus compliquées pas moins. Pour les sécuriser, la sécurité est également compliquée. J'ai toujours reculé quand j'entends des gens dire qu'IdentityServer est compliqué -- ce n'est pas le cas. Ce sont les exigences de sécurité de votre application qui sont compliquées. Souvent, les gens n'ont pas la perspective de le reconnaître.

Oui, cela fonctionne - et cela fonctionne bien - mais quand même, cette assurance supplémentaire qu'elle (peut) vous donner, lorsque Microsoft "approuve" officiellement et finalement "supporte" une technologie est de l'or pur.... !
Vous avez été élevé à un tout autre niveau !

@brockallen Oui, les applications compliquent probablement BEAUCOUP les choses. Cependant, le protocole OIDC a indéniablement hérité de certaines choses d'OAuth 2.0 qu'il aurait mieux fait de secouer. Certains des membres de votre équipe (je pense que c'était @leastprivilege) ont dit que si OIDC était développé à partir de zéro, il serait probablement assez différent de ce que nous avons maintenant.

Je ne dis pas que ce que nous avons maintenant est "mauvais", j'apprécie vraiment ce que nous avons, et c'est vraiment fonctionnel pour nos besoins, et j'espère que tous ceux qui ont participé à sa création sont fiers du travail qu'ils ont fait !

@Équipe;
Pour l'aperçu 3, pourriez-vous s'il vous plaît fournir des documents détaillés sur le "Serveur d'autorisation" et comment il fonctionnera avec l'API Web et le JS côté client, comme Vue ?
Nous devons prendre une décision et cet aperçu sur le serveur d'autorisation est un aperçu critique et tout document détaillé nous donnera des informations sur notre décision.

Merci!

Comme discuté avant

https://identityserver.io

Je viens de remarquer que les API de données ouvertes américaines sont également en JSON-LD : https://project-open-data.cio.gov/v1.1/schema/ . Cela semble être une tendance à la croissance rapide, donc une bibliothèque JSON-LD .NET bien fournie utilisée avec ASP.NET serait bien. :)

@veikkoeeva Il en json-ld.net , pas besoin d'une autre bibliothèque.

@khellang Et il existe également d'autres bibliothèques, cette bibliothèque particulière pourrait utiliser des mainteneurs (https://github.com/linked-data-dotnet/json-ld.net/issues/26). Je me rends compte que c'est open source et en théorie, je pourrais intervenir pour contribuer, mais pour le moment au moins, je suis trop dispersé pour aider avec cela. Autrement dit, j'aimerais peut-être attirer l'attention sur le fait que de nombreux ensembles de données semblent évoluer vers des formats sémantiques et qu'il n'est pas clair comment travailler efficacement avec cela en utilisant .NET.

À mon humble avis, ajouter IdentityServer4 au cœur d'ASP.Net Core est une mauvaise idée.
S'il vous plaît, ne faites pas du .NetCore un framework monolithique.
.NetCore est là et IdentityServer4 est là, les gens fondent l'architecture sur leurs propres besoins d'authentification et d'autorisation.

@mikeandersun Le plan est uniquement d'avoir une configuration par défaut simple que vous pouvez ajouter à votre projet pour le faire fonctionner

Vous ne pouvez toujours pas l'utiliser et cela ne vous affectera pas. Vous pouvez toujours utiliser IdSrv et le configurer entièrement vous-même. Vous pouvez toujours choisir les composants à inclure dans votre projet. Rien de tout cela ne rend ASP.NET Core monolithique.

ASP.NET Core != .NET Core d'ailleurs.

La 2.2 sera-t-elle une version LTS ? (Demander si cela a déjà été annoncé, ne pas vous demander de faire une nouvelle annonce.)

@yzorg non qui n'a pas été annoncé. Cette détermination est souvent prise après la libération sur la base de la qualité/stabilité.

@blowdart , ce modèle fournirait-il au serveur d'identité un client MVC d'application Web au lieu d'une API ?

@Ponant Non. Il s'adresse uniquement aux API. Nous réévaluerons cela dans la chronologie 3.x.

Intéressant... Cette question a été soulevée lors d'une réunion hier. Si nous construisons un projet "MVC" complet sans utiliser l'API Web, pouvons-nous utiliser le nouveau modèle ASP.Net 2.2 IS4 intégré dans 2.2 ?
On dirait que le grand patron (Barry) vient de répondre à la question.

@blowdart allias big boss : pourquoi ça ne se fait pas d'un seul coup ? Il semble trivial à première vue d'utiliser un client mvc ou une API Web pour parler à un serveur IS4 d'identité principale asp.net.

@Ponant Parce que nous n'avons pas des ressources infinies. Quelles fonctionnalités auriez-vous aimé que nous abandonnions afin d'amener tout le monde à modifier une grande partie du flux MVC qui ne donnerait aucune nouvelle fonctionnalité, changerait simplement le fonctionnement d'une fonctionnalité existante ? Une API authentifiée individuelle a été un écart entre le framework complet et ASP.NET Core. L'accent était mis sur le comblement de cette lacune. Identity Server a déjà des modèles de travail pour MVC avec Identity Server comme "noyau".

@CrispinH @blowdart Je suis tout à fait d'accord avec vous, l'administration des utilisateurs, les rôles, la location et les groupes d'utilisateurs sont désespérément nécessaires. Regardez ceci - il y a 7 tickets Uservoice qui se plaignent tous de ces centaines de développeurs et d'entreprises. Malheureusement, de nombreuses autres technologies comme le portail Java blueRay JSR 182 ou 173 font un si beau travail ici!

--> Autant de demandes de gestion des utilisateurs/groupes/locataires

--> ENCORE ici les gens se plaignent... ça continue, même sur twitter et facebook... c'est la raison - pourquoi d'autres plateformes comme WP et PHP sont plus faciles !

Bien que @manigandham pense que le serveur d'identité convient parfaitement, ils facturent BEAUCOUP pour l'outil d'administration de l'interface graphique et ce n'est pas bon marché pour de nombreux pays et développeurs, cela va également à l'encontre du développeur à faible coût total de possession. Combien de personnes peuvent vraiment se le permettre. Cela a été un ÉNORME obstacle et un recul, une fonctionnalité de base et une interface graphique pour gérer les utilisateurs/rôles/rôles-groupes d'utilisateurs/locataires sont nécessaires , qui peuvent ensuite être améliorées par le développeur

@papyr Pourquoi ne

@papyr @poke pas besoin d'un nouveau projet open source, il existe d'excellents projets existants.

Si vous voulez quelque chose d'open source de MS conçu pour rivaliser avec WordPress, regardez Orchard :
https://github.com/OrchardCMS/OrchardCore

Si vous voulez plus d'une approche de bibliothèque au lieu d'un framework, consultez cloudscribe, qui a des nugets pour la multi-location et l'interface utilisateur de gestion des utilisateurs et des rôles et des revendications pré-construite avec une intégration facultative Identityserver4 et un cms facultatif (cloudscribe.Simple/content) comme pépites supplémentaires.
https://www.cloudscribe.com/docs/introduction
https://github.com/cloudscribe/cloudscribe
https://github.com/cloudscribe/cloudscribe.SimpleContent

Si vous voulez quelque chose d'open source de MS conçu pour rivaliser avec WordPress, regardez Orchard :
https://github.com/OrchardCMS/OrchardCore

J'appuie cette recommandation.

Et Orchard Core est conçu pour être extrêmement modulaire. Par exemple, il est possible d' extraire uniquement son module multi-locataire et de l'utiliser dans vos propres projets . Il possède également déjà des modules pour gérer les utilisateurs et les rôles, et je suis sûr qu'ils apprécieraient votre contribution pour le rendre encore meilleur.

Vous pouvez regarder de nombreuses démos de ses différentes fonctionnalités sur leur chaîne .

@papyr Pourquoi ne

https://github.com/IdentityManager/IdentityManager2

Cette chose de l'interface utilisateur peut être délicate, bien qu'utile pour obtenir rapidement les éléments de base. Il semble que j'ai récemment rencontré des cas où la création de l'interface utilisateur n'est pas la tâche la plus importante, mais déterminer comment répondre aux "besoins du processus", tels que la pré-approbation de certains e-mails (qui font quelque chose de spécifique à l'application), l'appel d'API qui appellent des API , dont certains peuvent signifier des jointures dans la base de données ou des appels vers un autre endroit, etc., puis les ajouter aux jetons et à la logique de l'interface utilisateur.

Donc, avoir de bons tutoriels tels que https://mcguirev10.com/2018/01/28/login-identity-management-best-practices.html ou ceux de https://mcguirev10.com/page2/ semble plus important que l'interface utilisateur ( surtout si on ne peut ou ne veut pas utiliser EF). Ensuite, recherchez peut-être l'interface utilisateur pour la technologie choisie (Aurelia/Angular/Razor/React/Vue, etc.) et comment elle implémente la gestion des données.

Pour nommer les projets et les noms, outre @scottbrady91 , j'ai trouvé très instructif de vérifier https://github.com/abergs/fido2-net-lib ( @abergs , @aseigler), @TomCJones , @mackie1001 (Gitter) etc. pour fournir des explications supplémentaires et un code à consulter lorsque vous sortez un peu du besoin de base. J'ai oublié d'ajouter quelques noms et projets. :)

Pourquoi le noyau .net n'a-t-il pas de pages Web de rasoir normales ? Quand je fais des rapports complexes, j'aime tout faire à partir d'une seule page de rasoir (c#). Ou du moins la possibilité d'utiliser simplement une vue parfois uniquement sans modèle ni contrôleur.

En d'autres termes, la capacité de base à se connecter à sql dans la vue et à recevoir les requêtes GET et POST, aseptisée bien sûr, j'utilise actuellement une classe appelée Striptag.cs.

Pourquoi le noyau .net n'a-t-il pas de pages Web de rasoir normales ?

Vous pouvez utiliser les pages Razor pour cela https://docs.microsoft.com/en-us/aspnet/core/razor-pages/?view=aspnetcore-2.1&tabs=visual-studio

Avoir une classe de modèle de page d'accueil est facultatif ; vous ne pouvez avoir qu'une seule page

benaadams merci pour la réponse, comment utiliser les requêtes GET et POST directement dans une page de rasoir et établir une connexion de base au serveur SQL. La connexion pour les requêtes régulières, pas les entités ado, ni linq, ni ORM. Je préfère toujours les requêtes normales.

Comme:

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

Je sais que la chaîne de connexion se trouve maintenant dans un fichier json, mais je ne sais pas comment l'utiliser en vue. Certaines choses ne sont pas profondément documentées.

Eh bien, il a une courbe d'apprentissage. Si vous souhaitez récupérer des données _avant_ de charger la vue, vous le faites dans l'action correspondante. Donc, pour l'action HomeController.ViewReports et la page Views/Home/ViewReports.cshtml vous écrivez :

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

Si vous souhaitez récupérer les données _après_ le chargement de la page, vous utilisez généralement des requêtes AJAX vers un point de terminaison GET/POST pur qui renvoie des données au format JSON.

Peut toujours le faire sur une page sans aucun contrôleur ni action ; quelque chose comme

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

J'ai utilisé mvc asp.net et des formulaires Web et d'anciennes pages de rasoir, donc je ne suis pas nouveau dans ce domaine. J'ai passé 3 heures et je n'arrive toujours pas à faire fonctionner une simple page de rasoir de test, j'ai :

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

Juste une page html et se charge.

Modèle

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

Vue:

<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 heures et tout ce que j'obtiens est une page blanche. J'ai essayé une instruction return, etc.

Si je tape simplement http://localhost :51307/pets/razdb3 j'obtiens les deuxièmes divisions "bonjour", mais
le @Model.myvar je ne reçois rien.

Je suis nouveau sur .net core, et je n'aurais jamais imaginé qu'il serait ou pourrait être si difficile d'afficher simplement une page de rasoir.

Dans la communauté VS 2017

le @Model.myvar je ne reçois rien.

Vous définissez la myvar sur une demande de publication ( OnPost ) avec la valeur du formulaire psearch ; donc vous auriez besoin de faire une requête POST avec cette valeur pour la définir ?

Dans la requête GET ( OnGet ) que vous obtenez simplement en naviguant vers l'url depuis le navigateur ; plutôt qu'une publication de formulaire n'est définie sur rien.

Essayez de le définir sur une valeur par défaut afin qu'il apparaisse lorsque vous ne le définissez pas pour confirmer que le modèle circule :

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

Changé en

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

Et encore une page blanche. @Model.myvar est-il correct ?

même changé en

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>

Il construit bien sans erreur, mais une page blanche, peu importe ce que j'essaie.

Commentaire/réflexions polis : j'ai l'impression que cette discussion sur les "pages de rasoir normales" commence à être un peu hors sujet par rapport au sujet de ce fil.

😊

Désolé, je me rends compte que j'aurais dû utiliser le forum. Merci @benaadams votre code m'a mis sur la bonne voie et j'ai trouvé ceci :

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

C'est comme ça que je faisais normalement les choses de toute façon, en utilisant le mot clé "nouveau", comme

EmployeeDataAccessLayer objemployee = new EmployeeDataAccessLayer();

C'était rassurant de voir que vous pouviez toujours utiliser des classes personnalisées dans le noyau .net.

Vous devez admettre que .net core a une courbe d'apprentissage plus raide que certains frameworks asp.net antérieurs. Merci beaucoup.

Les notes de version parlent d'une fonctionnalité "Authorization Server" à prévoir en tant que module complémentaire dans les mois à venir. Y a-t-il plus d'informations disponibles sur cette fonctionnalité ? J'essaie de décider si nous devons l'attendre. Ou créez votre propre solution.

Les notes de version parlent d'une fonctionnalité "Authorization Server" à prévoir en tant que module complémentaire dans les mois à venir. Y a-t-il plus d'informations disponibles sur cette fonctionnalité ? J'essaie de décider si nous devons l'attendre. Ou créez votre propre solution.

Je pense que le plan actuel consiste à utiliser https://github.com/IdentityServer/IdentityServer4 de manière "pré-emballée".

Suite aux notes de l'équipe IS4 et de l'équipe de sécurité de MS, il semblait que MS essayait simplement de faire un emballage rapide et sale d'IS4 et de l'appeler le jour. Mais ressemble à quelqu'un avec plus de sagesse, a décidé de se retenir et de le faire de la bonne manière, car la sécurité peut créer des effets d'entraînement lorsqu'elle n'est pas bien faite.

J'espère qu'une intégration complète entre IS4 et ASP est faite pour prendre en charge à la fois l'API Web et MVC.

De nos jours, une authentification/autorisation de niveau industriel est requise au strict minimum. L'Open Source (OSS) convient pour la plupart des choses, mais il y a eu de sérieux doutes concernant certains produits de sécurité OSS qui ne sont acceptables sur aucun site Web d'entreprise. 85 % des projets utilisent des bibliothèques obsolètes qui présentent un risque de sécurité inacceptable. Par exemple, 45 % des serveurs Web utilisent Apache (https://www.cvedetails.com/vendor/45/Apache.html) qui présente bien plus de vulnérabilités que IIS (https://www.cvedetails.com/product/3436/ Microsoft-IIS.html?vendor_id=26). Des produits tels que Identity Server peuvent convenir, mais les modifications apportées par les développeurs peuvent les rendre complètement non sécurisés. Nous avons besoin d'une solution intégrée à Net Core qui soit toujours sûre...

De nos jours, une authentification/autorisation de niveau industriel est requise au strict minimum. L'Open Source (OSS) convient pour la plupart des choses, mais il y a eu de sérieux doutes concernant certains produits de sécurité OSS qui ne sont acceptables sur aucun site Web d'entreprise. 85 % des projets utilisent des bibliothèques obsolètes qui présentent un risque de sécurité inacceptable. Par exemple, 45 % des serveurs Web utilisent Apache (https://www.cvedetails.com/vendor/45/Apache.html) qui présente bien plus de vulnérabilités que IIS (https://www.cvedetails.com/product/3436/ Microsoft-IIS.html?vendor_id=26). Des produits tels que Identity Server peuvent convenir, mais les modifications apportées par les développeurs peuvent les rendre complètement non sécurisés. Nous avons besoin d'une solution intégrée à Net Core qui soit toujours sûre...

Votre remarque est tout à fait correcte. Mais dans certaines vidéos, le personnel de MS avait dit qu'ils n'allaient pas réinventer les roues [de sécurité] et utiliser un système tiers [IS4]. J'espère donc que ce sera une situation gagnant/gagnant pour nous tous.

De nos jours, une authentification/autorisation de niveau industriel est requise au strict minimum. L'Open Source (OSS) convient pour la plupart des choses, mais il y a eu de sérieux doutes concernant certains produits de sécurité OSS qui ne sont acceptables sur aucun site Web d'entreprise. 85 % des projets utilisent des bibliothèques obsolètes qui présentent un risque de sécurité inacceptable. Par exemple, 45 % des serveurs Web utilisent Apache (https://www.cvedetails.com/vendor/45/Apache.html) qui présente bien plus de vulnérabilités que IIS (https://www.cvedetails.com/product/3436/ Microsoft-IIS.html?vendor_id=26). Des produits tels que Identity Server peuvent convenir, mais les modifications apportées par les développeurs peuvent les rendre complètement non sécurisés. Nous avons besoin d'une solution intégrée à Net Core qui soit toujours sûre...

Rien n'est "toujours sûr", surtout pas quelque chose de Microsoft ;)
C'est toujours entre les mains de l'utilisateur de ces choses de les fabriquer et de les garder en sécurité.

IdentityServer sera inclus dans les nouveaux modèles d'expédition post 2.2. L'objectif initial sera le contrôle d'accès aux API - mais il est prévu de l'étendre à l'avenir.

ASP.NET Core sera livré avec une API de configuration simplifiée qui couvre uniquement les scénarios de modèle, mais sera très facile à démarrer. Vous pouvez à tout moment passer au système de configuration natif IS qui vous offre des scénarios avancés.

IdentityServer sera inclus dans les nouveaux modèles d'expédition post 2.2. L'objectif initial sera le contrôle d'accès aux API - mais il est prévu de l'étendre à l'avenir.

ASP.NET Core sera livré avec une API de configuration simplifiée qui couvre uniquement les scénarios de modèle, mais sera très facile à démarrer. Vous pouvez à tout moment passer au système de configuration natif IS qui vous offre des scénarios avancés.

Merci pour l'information Dominick;
Je pense que ce « tremplin » en aidera beaucoup à démarrer puis à passer à un SI complet. Bon mouvement.

IdentityServer sera inclus dans les nouveaux modèles d'expédition post 2.2. L'objectif initial sera le contrôle d'accès aux API - mais il est prévu de l'étendre à l'avenir.

ASP.NET Core sera livré avec une API de configuration simplifiée qui couvre uniquement les scénarios de modèle, mais sera très facile à démarrer. Vous pouvez à tout moment passer au système de configuration natif IS qui vous offre des scénarios avancés.

Bon à savoir! Merci.

Je suppose que ce contrôle d'accès à l'API sera basé sur des étendues OAuth ?
Pas de prise en charge directe des autorisations utilisateur plus volatiles comme décrit sur policyserver.io ?

IdentityServer sera inclus dans les nouveaux modèles d'expédition post 2.2. L'objectif initial sera le contrôle d'accès aux API - mais il est prévu de l'étendre à l'avenir.
ASP.NET Core sera livré avec une API de configuration simplifiée qui couvre uniquement les scénarios de modèle, mais sera très facile à démarrer. Vous pouvez à tout moment passer au système de configuration natif IS qui vous offre des scénarios avancés.

Bon à savoir! Merci.

Je suppose que ce contrôle d'accès à l'API sera basé sur des étendues OAuth ?
Pas de prise en charge directe des autorisations utilisateur plus volatiles comme décrit sur policyserver.io ?

PolicyServer est une solution commerciale

Je suppose que ce contrôle d'accès à l'API sera basé sur des étendues OAuth ?
Pas de prise en charge directe des autorisations utilisateur plus volatiles comme décrit sur policyserver.io ?

"Uniquement" IdentityServer. ASP.NET Core a une API intégrée pour l'autorisation des utilisateurs - et si PolicyServer (le produit) vous semble intéressant, faites-le moi savoir.

Fermeture de ce problème car ASP.NET Core 2.2 a été expédié.

ne devrait-il pas être mis à jour vers ASP 3.0

Une mise à jour sur la date de livraison des améliorations du serveur d'autorisation ?