E quanto ao EF Core 2.2 Roadmap?

E quanto ao EF Core 2.2 Roadmap?

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

O roadmap parece bom, principalmente verificações de integridade e HTTP 2.0. No entanto, da maneira mais gentil possível , discordo da necessidade de construir um servidor de autorização Microsoft primário simples. IdentityServer4 preenche bem essa lacuna e o tempo gasto na reimplementação de uma versão mais simples dele poderia ser melhor gasto em outro lugar. Eu entendo que o objetivo é fornecer uma solução simples, mas o auth é difícil e o IdentityServer fornece uma API tão simples quanto parece. Se houver ideias para uma abstração mais simples, ela pode ser construída sobre o IdentityServer para que as pessoas possam usar a abstração simples, mas tenham o poder, se necessário.

Atualizar

No standup da Comunidade ASP.NET, foi mencionado que a equipe ASP.NET Core está conversando com a equipe do Identity Server sobre as opções, incluindo a construção de algo sobre o Identity Server. Acho que é isso que todos nós queremos, muito bem!

Quais são os planos atuais em relação aos WebHooks ASP.NET Core ?

Em relação ao despachante, isso será possível no middleware então? 😱
C# public async Task Invoke(HttpContext context, [FromRoute] SomeModel someModel)
^[FromQuery]?

Simple Auth Server, mas lembre-se também do que aconteceu com Katana Simple Auth Server

Desejo ecoar as preocupações de @RehanSaeed e gostaria de pedir alguns esclarecimentos sobre quais casos de uso exatos esse novo servidor deve preencher. Se isso for principalmente para que as APIs da web tenham uma maneira de obter seu token de portador que seja válido na autenticação existente do aplicativo, tudo bem. Mas tudo em cima disso provavelmente é melhor deixar para as soluções existentes, que já oferecem muitas opções de complexidade e flexibilidade diferentes com produtos como IdentityServer, OpenIddict e AspNet.Security.OpenIdConnect.Server.

E quanto à hospedagem em processo do IIS ?

Você poderia elaborar mais sobre a parte do TypeScript de "geração do cliente API (C # e TypeScript)"?

Isso seria realmente algo que eu estaria ansioso. Atualmente estou usando o NSwag para gerar automaticamente meus serviços de API do Angular Client. Mas existem tantas combinações diferentes possíveis para configurações de cliente que acho que isso pode ser problemático para agradar a todos.

No topo da minha cabeça, algo que deve ser considerado (e se possível deve ser configurável):

• Apenas um cliente TypeScript com busca ou um serviço Angular com HttpClient?
• Se for Angular, quais versões você oferece suporte (também importante para RxJS)?
• tratamento nulo / indefinido
• manipulação de enum
• Data JS ou momentjs para tipos de data?
• Tratamento de exceções, tratamento de erros de validação
• Como estender o código gerado no cliente?
• Possibilidade de influenciar a geração de nome (por exemplo, descartar a parte DTO de xxxDTO para as classes de cliente geradas ou já na definição OpenAPI)

Se fosse possível votar em recursos, essas melhorias / correções no middlware existente estariam na minha lista de desejos:

• Permite criptografar suporte https://github.com/aspnet/Home/issues/1190.
• O middleware do Cache de Resposta basicamente não pode ser usado como é hoje. Adicionar um armazenamento de cache de resposta Redis e extensibilidade para operações do usuário de respostas em cache deve resolver https://github.com/aspnet/Home/issues/2606.
• Suporte para veiculação de arquivos pré-codificados com GZIP e pré-BR .
• Adicione um provedor de compactação Brotli e também vários problemas com o middleware de compactação de resposta.

Eu também voto para ignorar o produto Authorization Server. A segurança é complicada e houve um grande esforço para mudar para os serviços em nuvem para remover a manutenção, e qualquer pessoa que quiser mais controle já pode usar o IdentityServer4, que é bem construído, testado, documentado e com suporte. Uma configuração simples leva 5 minutos e eles têm muitos exemplos iniciais, vídeos e tutoriais.

Não consigo ver como você pode fazer a segurança funcionar como "configuração zero" mais do que eles. Parece que isso apenas adicionará mais confusão (na nomenclatura e no uso), enquanto se torna mais uma coisa para apoiar e manter por anos, tirando o esforço de outros recursos continuamente. Por favor, repense isso.

Também estou curioso para saber por que a hospedagem em processo do IIS não está neste roadmap 2.2. Esta é uma característica importante e é um fator importante em nossa estratégia de lançamento e horários aqui no estouro de pilha e já foi removido último minuto antes do lançamento 2.1, prometendo um prazo de 2,2 vez . Diga-me que isso é apenas um descuido e não outra mudança de plano.

Edit: @DamianEdwards respondeu no Twitter que isso foi realmente um descuido (o que significa que está planejado para 2.2). Ufa!

Vou repetir outros comentários. Se você vai investir em Autorização / Política, especificamente tornando-o mais simples, pessoalmente prefiro muito mais ver uma parceria com empresas como OpenIddict e IdentityServer em documentos e investimentos em andaimes. Não posso deixar de sentir que qualquer trabalho, não importa o quão simples seja, acabará duplicando esforços fantásticos de terceiros e incorrendo em custos de manutenção desnecessários para a equipe aspnet.

Pode ser uma visão impopular, mas eu gostaria de ver um Microsoft Auth Server, construído aos olhos do público, com nossa contribuição e suporte.

Os atuais - Id4, OpenIddict - são obviamente excelentes projetos OSS, e não posso deixar de sentir que um com o apoio da MS por trás dele poderia ser uma coisa ruim ...?

Há um limite para a quantidade de suporte disponível de um pequeno grupo de pessoas, e esses são produtos de missão crítica, afinal.

Acho uma pena que o Código de Conduta do MS OSS não inclua uma linha que diga "Não promova recursos que duplicam algo que pode ser trazido com uma solicitação da Nuget e que casualmente esmagará uma empresa de dois homens que contribui para o nosso ecossistema ".

O cínico em mim não pode deixar de se perguntar se, para alguns insiders, dar a Brock e Dominick um nariz sangrando foi uma característica dessa sugestão, em vez de um bug. É isso que acontece com as pequenas empresas que sempre tiveram a ousadia de criticar qualquer coisa que a equipe ASP faça?

Eu também me pergunto sobre a duplicação da funcionalidade de autenticação em vez de construir algo na parte superior, como interfaces de usuário e documentação.

Além disso, uma biblioteca JSON-LD 1.1 bem testada seria uma boa adição específica ao roteiro. :)

Repetindo o que outros disseram - eu prefiro muito mais ver o trabalho de autorização sendo trazido de algo como IdentityServer4 do que implementado novamente por vocês mesmos. Se houver lacunas, certamente superá-las por meio de contribuições, amostras e pontos de integração de refinamento seria o melhor caminho a seguir. Talvez também preste atenção à sua oferta de nuvem neste espaço (B2C), que está em um estado terrível.

Além disso, embora você afirme que o objetivo não é replicar a funcionalidade em ofertas de código aberto existentes e manter as coisas simples, isso é um pouco equivalente à armadilha de reescrita clássica: "esta solução é excessivamente complexa e um pouco confusa, vamos reescrevê-la! " É ingênuo e na hora de n versões eu apostaria em você ter lidado com os muitos casos extremos que as soluções do mundo real exigem e que algo como IdentityServer já está lidando.

De forma mais ampla, com a aquisição do GitHub, tem havido muita discussão recentemente sobre a atitude da Microsoft em relação ao código aberto. É ótimo que a Microsoft esteja fazendo tanto trabalho aberto, mas parte de ser um bom cidadão do código aberto é aproveitar o código aberto existente quando ele existe.

Isso é particularmente importante para proprietários de plataforma como você - um proprietário de plataforma que duplica a funcionalidade em ofertas de código aberto existentes _descoraja_ contribuições enquanto se envolve com essas ofertas _encoraja_ contribuições.

Eu também não consigo ver a razão do esforço despendido na autorização, mas gostaria de ver o _gerenciamento_ da identidade do ASP.NET Core aprimorado. Damian Edwards foi bastante claro em live.asp.net que não devemos implementar nossa própria segurança, mas - a menos que eu não tenha percebido - ASP.NET Core Identity não contém nenhuma ferramenta de gerenciamento de usuário e, portanto, temos que implementar nosso próprio. Acho isso um pouco assustador, pois não sou um especialista em segurança e estou mortalmente com medo de deixar um buraco de segurança que eu mesmo criei.

Que tal mover formatadores de conteúdo do nível MVC para abstrações AspNetCore.Http em 2.2?

Talvez o PM responsável pudesse escrever uma descrição mais detalhada deste Identity Server Lite para deixar claro exatamente quais deficiências nas soluções de código aberto de terceiros existentes que a equipe ASP.NET está procurando resolver. Porque do jeito que está, você está falando sobre reinventar uma roda, mas talvez remover alguns raios, e isso não faz muito sentido. Como outra pessoa disse, consertar o AAD B2C e fornecer integração de primeira classe com isso seria ótimo e faria sentido para os negócios da MS.

Além disso, você já considerou como será difícil obter um produto de servidor Auth, totalmente novo, após o @blowdart?

Algum plano de ter um suporte de API RESTful integrado como o que django tem?
Porque é algo que todos os desenvolvedores tendem a escrever sempre!

Construí recentemente algo que poderia ser escrito como um controlador de API RESTful genérico:

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

Também concordo com "Não consigo ver como você pode fazer a segurança funcionar como" configuração zero "mais do que eles podem" e "você está falando sobre reinventar uma roda, mas talvez remover alguns raios", o servidor de identidade é um produto incrível, muito simples para começar e fornece extensibilidade para cenários mais complicados, não sei por que exigimos uma versão "simplificada".

Em uma escala muito menor, por que precisamos de outra implementação de verificação de integridade. Já existem várias soluções de código aberto, por exemplo

• https://github.com/Xabaril/BeatPulse , inclui um monte de cheques pré-escritos e ainda vem com uma IU
• https://www.app-metrics.io/web-monitoring/aspnet-core/health/

Qual será a diferença de recursos com eles e o que é fornecido em 2.2?

@ 0xRumple As melhorias no ApiController devem ajudar a tornar isso menos prolixo em geral. Mas não, você provavelmente não verá algo que apenas fornece uma API CRUD para suas entidades por padrão. Isso teria que fazer muitas suposições sobre seu DAL e autorização.

Se você seguir certos padrões em seu aplicativo, não há nada de errado em criar seus próprios tipos de base ou convenções no 2.2 que generalizarão o trabalho para você.

@kieronlanning

Os atuais - Id4, OpenIddict - são obviamente excelentes projetos OSS, e não posso deixar de sentir que um com o apoio da MS por trás dele poderia ser uma coisa ruim ...? Há um limite para a quantidade de suporte disponível de um pequeno grupo de pessoas, e esses são produtos de missão crítica, afinal.

Já que você perguntou se isso poderia ser uma coisa ruim:

A equipe ASP.NET também é relativamente pequena, atendendo a milhões de desenvolvedores com capacidade limitada, portanto, qualquer novo projeto consumirá tempo e esforço de outras coisas. Isso significa que todos nós temos que esperar mais para obter quaisquer recursos totalmente novos que provavelmente agreguem mais valor.

Muito pior é que isso prejudica o ecossistema de terceiros e desencoraja novos produtos porque a Microsoft lançou um pacote "oficial", que muitas empresas não conseguem escolher apenas porque é da Microsoft, mesmo que seja tecnicamente (e, neste caso, supostamente) menos capaz. ASP.NET já integra Json.NET, Polly, AutoMapper e muitas outras bibliotecas, então parece um erro reconstruir um produto de segurança tão complexo (que precisará de 80% do mesmo código base) quando já existem ótimas opções, e com muito mais coisas interessantes no roteiro para trabalhar.

@cutucar
Você está certo, escrever classes básicas de meus aplicativos é uma boa ideia.

Na verdade, acredito que essas não estão dentro das responsabilidades do framework:

CRUD resources (repository responsibility)

Manipulating data (sieve responsibility)
    Paging
    Filtering
    Searching
    Sorting
    Shaping

Mas há muitas coisas que eu pensei que o AspNetCore poderia ter feito melhor (por ter um pacote AspNetCore.RestFramework):

1. HATEOAS (API autodetectável)
2. Tipos de mídia (configuração de tipos de mídia personalizados)
3. Controle de versão (atualizar a versão do tipo de mídia)
4. Metadados de dados Mainpulated (paginação no cabeçalho X-Pagination, metadados do filtro ... etc).
5. Limitação de taxa e estrangulamento.

Eu sei que existem toneladas de bibliotecas por aí, encontrei algumas aqui: https: //github.com/thangchung/awesome-dotnet-core ... Mas, bibliotecas de terceiros não são realmente uma boa opção para os aplicativos corporativos!

O mesmo vale para a peneira, se houver um pacote OFICIAL para paginação, filtragem ... etc, os desenvolvedores não tenderão a escrever bibliotecas com bugs ou não mantidas, usei esta peneira no meu aplicativo que mencionei acima: https: // github.com/Biarity/Sieve , mas esta biblioteca pode ficar sem manutenção a qualquer segundo que o autor esteja ocupado.

Acho que o AspNetCore está maduro o suficiente para começar a pensar em soluções out-of-the-box como no django, desta forma podemos ter o luxo da performance do agilidade do django .

Mas, as bibliotecas de terceiros não são realmente uma boa opção para os aplicativos corporativos!

^ É por isso que não podemos ter coisas boas 😞

Mas, as bibliotecas de terceiros não são realmente uma boa opção para os aplicativos corporativos!

Sim, é exatamente essa a mentalidade que precisa mudar aqui. ASP.NET Core e .NET Core são de código aberto e seu ecossistema _está_ abraçando a comunidade de código aberto e deve continuar a fazê-lo. Não apenas com soluções de código aberto que fazem parte da .NET Foundation, mas qualquer solução realmente.

mas esta biblioteca pode ficar sem manutenção a qualquer segundo que o autor esteja ocupado

E, da mesma forma, um pacote “oficial” pode deixar de ser mantido a qualquer momento em que a empresa mude de interesse. Isso já aconteceu com coisas específicas da Microsoft antes, incluindo vários pacotes de código aberto que publicaram, mas é realmente natural para qualquer empresa.

Se você decidir ficar dependente da biblioteca de outra, é sua responsabilidade viver com isso. Independentemente de quem seja o autor disso. O bom do código aberto é que, mesmo que o autor acabe não respondendo, você tem todo o direito de alterá-lo.

Sou totalmente contra esperar soluções oficiais da Microsoft para tudo o que você possa apresentar. Não apenas porque nunca existe uma solução única para todos, tornando isso muito difícil e ao mesmo tempo provável de sair do controle, mas especialmente porque isso tira recursos de partes da estrutura que realmente precisam de atenção. E, ao mesmo tempo que dói a idéia de código aberto realmente muito ruim.

Se você está criando aplicativos corporativos e ainda luta com essa síndrome NIH (ou “não foi inventado em <large-company>”), deveria realmente acordar porque estamos em 2018 e provavelmente deveria adotar o código aberto agora.

Você está certo, a Microsoft pode parar de manter qualquer pacote, mas pelo menos eles têm um LTS específico: https://www.microsoft.com/net/support/policy

Por exemplo, o suporte do .NET Core 1.1 termina em 27 de junho de 2019 ... assim, posso ter certeza de que, se usar esta versão, não ficarei aleijado no meio.

Certa vez, usei um auxiliar de tag de paginação de terceiros e não foi agradável, o autor basicamente me disse que não iria consertá-lo para o .NET Core 1.1 e que eu deveria atualizar o projeto, era um sistema universitário, para 2.0 (e ele tem todo o direito de fazê-lo porque escreveu esse pacote GRATUITAMENTE).

Aqui está o problema, na empresa, isso não funciona ... você não pode convencer toda a equipe de que você deve mudar para 2.0 enquanto o aplicativo está instalado e funcionando só porque o auxiliar de tag de paginação não t trabalho!
Então você apenas começa a hackear a fonte como eu fiz usando um decorador: https://github.com/cloudscribe/cloudscribe.Web.Pagination/issues/37

E sim, quem disse que não sou um grande fã do código aberto: confused :?

@ 0xRumple não é a ideia do código aberto para contribuir e colaborar?

Se esse auxiliar de tag de paginação de terceiros não existisse, você teria que escrevê-lo e mantê-lo de qualquer maneira, "na empresa".

Aqui está o problema, na empresa, isso não funciona ... você não pode convencer toda a equipe de que você deve mudar para 2.0 enquanto o aplicativo está instalado e funcionando só porque o auxiliar de tag de paginação não t trabalho!

Em vez de tentar "convencer toda a equipe de que você deve mudar para o 2.0", contribua com uma atualização e ajude, em vez de depender de outra pessoa para fazer o trabalho ou esperar que a Microsoft forneça um equivalente. Se o proprietário não quiser aceitar sua contribuição, vá em frente com um fork para suas necessidades.

Suponho que seu tipo de pensamento (sem intenção de ofender) é uma grande parte do motivo de haver uma discussão em torno de "servidor de autorização da Microsoft" versus servidor de identidade. Como o código aberto funcionará se os desenvolvedores não quiserem participar. Devemos esperar que a Microsoft forneça todo o código de que precisamos?

Eu concordo com muitos aqui que a Microsoft deve ter cuidado para não matar bons projetos de código aberto no ecossistema fazendo suas próprias substituições para tudo.

Na verdade, sou o autor da biblioteca taghelper de paginação mencionada por @ 0xRumple , o problema dele era realmente com um componente pagedlist e não com o taghelper que, na verdade, tem um nuget mais antigo que suporta o núcleo aspnet 1.x. A lista paginada era realmente algo que fazia parte de uma biblioteca de pagers de código aberto anterior que informou o design da minha biblioteca e foi usada nas páginas de demonstração uma vez, mas o taghelper do pager não dependia da implementação da lista de pagers e existem outros pagers listar implementações que ele poderia ter usado enquanto ainda usava o pager taghelper. Na verdade, desde então removi a lista paginada inteiramente daquela biblioteca, pois ela nem mesmo faz parte do taghelper e nunca foi.

Realmente não é diferente usar pacotes nuget de desenvolvedores de software de fonte aberta da Microsoft, pois se você ficar preso no aspnet core 1.1, não poderá obter correções e melhorias do aspnet core 2.x a menos que atualize para a nova estrutura.

@joeaudette
Acabei de mencionar esse exemplo para ilustrar meu ponto de vista sobre soluções integradas em comparação com soluções de terceiros, ainda sou grato por seu trabalho nesse taghelper de paginação ... a universidade usa seu pacote de paginação e eles estão felizes: coração:

@alhardy

Devemos esperar que a Microsoft forneça todo o código de que precisamos?

Este é o principal problema, pensamos que quando a Microsoft traz uma solução oficial, eles vão lutar contra qualquer outra solução de código aberto ou eles vão escrever cada linha de código por si próprios: sorriso:

Claro que não, podemos oferecer o melhor dos dois mundos, uma solução oficial e uma baseada na comunidade se a Microsoft adotar as soluções certas e criar as soluções que faltam, para que os desenvolvedores possam se concentrar em contribuir com elas.

A comunidade django acertou, eles fornecem / adotam oficialmente a solução simples inicial para um problema específico, por exemplo, estrutura RESTful, e a comunidade construída em cima disso ... dê uma olhada aqui em seu estágio inicial de construção de django-rest- estrutura: https://www.djangoproject.com/weblog/2016/jun/22/django-rest-framework-funding/

Eles começaram o projeto inicial, e a comunidade está melhorando / construindo em cima disso, este é o repositório deles: https: //github.com/encode/django-rest-framework ... cerca de 800 contribuidores!
E a comunidade é motivada a construir pacotes que resolvam problemas em cima desse pacote, como django-rest-auth ou django-rest-framework-jwt .

Pelo menos eles fornecem as "soluções oficiais" que a maioria dos desenvolvedores precisa, como django-admin-site ou django-debug-toolbar . Isso também vem da filosofia Python de "baterias incluídas", no início, achei ruim, pois se esforça para soluções de mínimo denominador comum, e percebi mais tarde a brisa que isso traz.

* PS: Dapper (da StackExchange) e EFCore (da Microsoft) são ORMs, mas visam resolver o mesmo problema em abordagens diferentes. O Dapper foi criado inicialmente em 2011, enquanto o EFCore 2014 ... o EFCore afetou mal os projetos de código aberto? claro que não, e é uma solução oficial!
Pessoas que já estão construindo sobre essas coisas incríveis, como este: https://github.com/crhairr/EntityFrameworkCore.MongoDb/

o EFCore afetou mal os projetos de código aberto?

Uuuh, alguém se lembra do NHibernate (que é o mais próximo do EF em funcionalidade)? Não, provavelmente não, porque está praticamente morto depois que EF foi lançado 😕

@ 0xRumple

Claro que não, podemos ter o melhor dos dois mundos, uma solução oficial e uma solução baseada na comunidade se a Microsoft adotar as soluções certas e criar as soluções que faltam,

Neste caso, não é porque está recriando uma solução existente, mas com menos funcionalidade propositalmente.

Entity Framework e Dapper são muito diferentes. EF sempre foi projetado para ser um ORM completo, e ambos surgiram anos depois do Linq-To-SQL original em 2007 .

No entanto, também não acho que você esteja errado e parece que todos nós estamos conversando. O tópico consiste principalmente em comentários sobre o produto do servidor de autenticação enquanto você está falando sobre bibliotecas relacionadas a REST, que parecem pequenas e focadas o suficiente para serem incluídas em uma estrutura da web. Eu concordo que os parâmetros search/paging/filter padronizados seriam úteis para ter código de API da Web integrado.

Esta discussão não está reconhecendo a estranha verdade de que, em algumas organizações, os desenvolvedores precisam levar em conta cada pacote de código aberto introduzido em sua solução. Em alguns casos, esta é uma verificação automática que produzirá relatórios de "Risco" que freqüentemente um gerente de risco não técnico precisará revisar. Essas ferramentas sinalizarão qualquer coisa que não seja mantida ativamente e qualquer coisa que se pareça com uma licença copyleft.

Você também pode imaginar que, nessas organizações, contribuir para o código aberto é visto como uma conversa maluca.

Sim, o Identity Server 4 é incrível. Mas para um gerente de risco não técnico é algo para o qual não temos garantia, algo suportado por um punhado de pessoas e ainda pior - algo com o código-fonte disponível para todos verem. Esta pessoa está equivocada, mas o desenvolvedor médio em campo não vai ganhar esta luta.

Um "Identity Server Lite", como @markrendle coloca apropriadamente, escrito principalmente por funcionários da Microsoft pode ser a diferença em poder usar o .NET Core ou não, especialmente se houver um arquiteto corporativo na organização insistindo que alguns $$ $$$ O lixo corporativo da HP ou IBM é usado para autenticação.

@edandersen

Mas para um gerente de risco não técnico é algo para o qual não temos garantia, algo suportado por um punhado de pessoas e ainda pior - algo com o código-fonte disponível para todos verem.

Tenho certeza de que o pessoal do IdentityServer forneceria algum suporte se você pagasse por isso - assim como você pagaria à Microsoft. OSS não é igual a grátis.

O que o faz pensar que a equipe ASP.NET Core da Microsoft não é "um punhado de pessoas"? Spoiler ... são cerca de 20-30 pessoas no total. Apenas um casal trabalharia em um produto assim.

Estou realmente curioso para saber por que "o código-fonte disponível para todos verem" é uma coisa ruim? E o que o faz pensar que este produto da Microsoft não será open source? É o novo padrão.

@khellang "o código-fonte disponível para todos verem" para deixar claro que isso é uma coisa boa! Mas você ficaria surpreso com os argumentos que alguns desenvolvedores precisam ter no trabalho. O ponto "A Microsoft escreveu" infelizmente é o único argumento aceitável às vezes. Note que estou bancando o advogado do diabo para uma hipotética, mas típica empresa disfuncional.

E, claro, os mesmos desenvolvedores podem defender que seu empregador pague pelo suporte para o Identity Server, mas o processo de aquisição provavelmente irá privá-los da vontade de viver.

Bem, se começarmos a usar esses argumentos de gerentes não técnicos, as coisas vão começar a ficar malucas. IMHO, pessoas que não são técnicas, não devem ditar o que deve ser usado ou não. Se eles querem ter um ditado, pelo menos eles deveriam saber do que estão falando, e dizer que um pacote bem conhecido como IdentityServer tem menos qualidade do que um MS, para mim, é completamente errado. Eu fugiria de uma empresa assim!

Mas o ponto aqui é que quase todo mundo concorda que gastar tempo em algo que já está lá, é sólido e MUITAS pessoas estão usando isso é um pouco estranho. Eu me pergunto qual é a verdadeira razão por trás disso .. Eu não acho que foi assim: Oh, vamos construir nossas próprias coisas, só porque podemos. Os clientes realmente pedem isso que talvez não tenhamos conhecimento?

Pessoalmente, não vejo outro competidor no espaço do servidor OAuth como um problema, mas é uma coisa boa.

Pode ajudar a impulsionar o desenvolvimento nesta área ou apenas servir como uma solução rápida e suja para pessoas que não precisam de nada mais do que isso - uma solução rápida e suja.

Se você deseja ou precisa de mais de um servidor OAuth, então não há nada que impeça qualquer um de nós de usar as soluções existentes. Ou, se você quiser um modelo de um clique para fazer OAuth básico _e nada mais_, então essa parece uma meta válida, pelo menos para mim.

Eu acho que este tópico se transformou em um olho por olho sobre o que é OSS, o que o MS é bom em fazer e o que o MS não é bom, ao invés de focar no que está no roteiro para .NET Core 2.2, que é o que realmente importa aqui.

@khellang
"O NHibernate está morto", disse quem? Vejo que o projeto ainda está vivo e ainda tem um ímpeto melhor do que Dapper
https://github.com/nhibernate/nhibernate-core/graphs/contributors
https://github.com/StackExchange/Dapper/graphs/contributors

Ah, eu não mencionei o IdentityServer até agora para insistir em ter o framework RESTful dentro dos pacotes aspcore oficiais ... aqui estão meus pensamentos sobre o IdentityServer, é realmente sólido e ótimo, MAS é um projeto de 2 pessoas, dê uma olhada nas métricas:
https://github.com/IdentityServer/IdentityServer4/graphs/contributors

Cerca de 85% do trabalho é feito por 2 pessoas e não há problema em um projeto relacionado à segurança, mas na empresa muitas empresas pensam na capacidade de manutenção de tais projetos no futuro. Recentemente, uma empresa me disse que queria que eu usasse React em vez de Vus.Js em seu projeto só porque disseram "vue.js é basicamente Evan You" ... e acho que eles estão certos. E é isso que estou tentando dizer, desde o início da discussão sobre ter o pacote RESTful dentro dos pacotes oficiais, nenhuma grande empresa aceitará você usar em um pacote "potencial" não mantido em seus projetos.

O mesmo vale para manipulação / peneiramento de dados (paginação, modelagem, classificação ... etc) porque quase todo projeto contém esses requisitos e, sim, como @manigandham disse, eles são padronizados e diretos.

@manigandham
Exatamente isso que eu acho certo ... adaptar e apoiar as soluções oficialmente , seja financeiramente ou contribuindo via github ou pelo menos mencionando-as em seus documentos ou cursos (eu já vi Hanselman mencionando SwashBuckle em um de seus cursos no Microsoft Virtual Academia que é realmente ótima, e seria melhor ver mais adaptação a esses projetos!).

@kieronlanning
Você está certo, nós fomos muito longe do tópico principal ... mas como mencionei antes, asp core ficou muito maduro (desempenho e confiável), e eu acho que é hora de começar com o fora do soluções em caixa .

Acho que descontar um projeto porque ele tem dois contribuidores principais é muito bobo. O IS4 é muito bem conservado e aqueles dois caras passam muito tempo respondendo perguntas e ajudando as pessoas. Ele também é amplamente considerado como uma das melhores soluções FOSS para um servidor OAuth2 no mercado.

"O NHibernate está morto", disse quem? Vejo que o projeto ainda está vivo e ainda tem um ímpeto melhor do que Dapper

@ 0xRumple Eu disse "praticamente morto" 😉 Você parece ter algumas métricas muito estranhas sobre a saúde e o uso de projetos de software de fonte aberta. É justo comparar o número de compromissos em um projeto de 2003 com aquele que vem acontecendo desde 2011? Eles também são _muito_ diferentes animais (conforme observado anteriormente no tópico); O Dapper está "completo" (isso não significa sem manutenção, abandonado, etc.) há algum tempo, enquanto o NHibernate (e seu conjunto de recursos) está ficando para trás.
Eu sei que o projeto ainda está avançando, mas não me lembro da última vez, nos meus últimos 7 anos de consultoria no espaço .NET, onde encontrei o NHibernate em estado selvagem (onde não estava no processo de sendo migrado para o Entity Framework). Todo mundo que está seguindo este espaço nos últimos dois anos sabe muito bem que o NHibernate está ficando para trás e perdendo participação de mercado para o Entity Framework. Basta olhar apenas para os números de download do NuGet: o Entity Framework tem 45,8 milhões contra o NHibernate com 3,4 milhões.

De qualquer forma, o ponto não é Entity Framework vs NHibernate. Foi apenas _um_ exemplo. Tivemos essa discussão inúmeras vezes; mais recentemente, quando a Microsoft lançou sua própria implementação leve de contêiner IoC no ASP.NET Core ou quando a Microsoft estava pensando em lançar seu próprio mapeador de objetos. Sempre que a Microsoft entra em um espaço na comunidade OSS, ela suga muito (a maior parte?) Do ar da sala. Freqüentemente, o suficiente para que os projetos menores voltados para a comunidade sufoquem com o tempo. Eu, e a maior parte da comunidade, sabemos muito bem; é impossível competir com a Microsoft no próprio mundo (.NET) da Microsoft. Eu entendo perfeitamente que eles têm clientes pagantes que precisam satisfazer, então não espero que este feedback mude de ideia: sorria:

Recursos incríveis :)

Onde posso obter mais informações sobre o recurso de verificação de integridade?

Melhorar o gerenciamento de certificados autoassinados

Ao desenvolver aplicativos da web que chamam APIs da web associadas, chega um ponto em que é útil testá-los com usuários internos na rede local. Você pode ter passado em todos os testes de unidade, funcional e de integração, mas não há nada como um ser humano para realmente quebrar as coisas.

No espírito de desacoplamento, meus aplicativos da web chamam várias APIs da web. Na primeira instância, eu desenvolvo essas APIs da web usando https: // localhost :. Assim que uma API da web estiver pronta (o suficiente), eu a publico no IIS em minha máquina local. Cada site tem um nome de host apropriado que configurei em meu servidor DNS interno. Neste ponto, eu uso Barry Dorrans '- @blowdart - gist https://gist.github.com/blowdart/1cb907b68ed56bcf8498c16faff4221c para criar um certificado de servidor. Desde que eu importe os certificados para todas as lojas certas, tudo funciona na minha máquina sem alarmes.

Isso muda quando outras pessoas na rede acessam os aplicativos da web (as chamadas de API estão todas dentro da minha caixa de desenvolvimento). Avisos terríveis são recebidos pelo usuário. Eu digo a eles para ignorar esses avisos e, quando possível e suficientemente direto, importar os certificados. Como esses certificados autoassinados têm o mesmo nome de emissor e nome comum, cada novo aplicativo da web aciona uma página de aviso

Não consigo deixar de pensar que pedir aos usuários de uma organização que percorram as páginas de aviso é uma má ideia.

Como não especialista em segurança, há algumas coisas que gostaria de ver:

• a capacidade de ter um certificado raiz local para todos os certificados de desenvolvimento que eu crio e, em seguida, ser informado de uma forma autorizada de importá-lo para PCs, Macs, dispositivos Android, iPad e iPhone, de modo que essas páginas alarmantes não ocorram mais

• um método mais fácil de gerar certificados para APIs que podem ser usados ​​com IIS e Kestrel que preenche todos os armazenamentos de certificados corretos corretamente

@CrispinH Para ser honesto, dar suporte a uma CA raiz seria, bem, uma preocupação em criar uma CA raiz. Se você está nesse ponto, é hora de considerar criar você mesmo uma CA raiz e gerenciá-la. O suporte autoassinado, seja através da ferramenta global ou meu script é apenas para isso, desenvolvimento. Uma vez que você começa a permitir que as pessoas se conectem a ele, você está fora do escopo desse recurso. Se você está em uma organização e deseja que as pessoas acessem os serviços, a organização precisa descobrir sua estratégia de certificado, executando uma CA interna via Windows ou OpenSSL e removendo a raiz via política AD ou outros meios.

@blowdart Um dos motivos do meu resmungo foi que passei alguns dias tentando criar um CA raiz e não consegui acertar, por falta de competência nessa área. Até tentei descobrir como modificar sua essência para aceitar uma CA raiz local.
Toda a documentação que encontrei era muito geral - tudo que eu queria era um processo para criar certificados (de preferência com base em uma CA raiz) apenas para proteger APIs e aplicativos da web com um certificado de servidor. Talvez a documentação de um caso específico seja tudo o que for necessário.

O @CrispinH Window Server vem com uma Autoridade de Certificação que você pode configurar, se quiser ir até o fim.

Certificados em geral não são um tópico fácil e você terá que aprender um pouco para fazer isso direito.

Para fins de desenvolvimento, certificados autoassinados são totalmente adequados e fáceis de usar. Tudo além disso, incluindo a configuração e o gerenciamento de um CA, não é mais para fins de desenvolvimento e definitivamente está fora do escopo e muito complexo para uma estrutura de aplicativo da web.

@CrispinH Como @poke disse que é difícil acertar. Assim que você tiver máquinas que confiam em uma CA raiz, todos os certificados emitidos serão confiáveis. E os desenvolvedores executam códigos não confiáveis ​​em suas caixas de desenvolvimento. Afinal, é isso que os pacotes nuget são. Portanto, considere algo que rouba sua CA raiz. Na vida real, as CAs raiz tendem a ser mantidas off-line, eles assinam um segundo certificado, que é restrito no que pode fazer, certificados de servidor e cliente geralmente, e então os certificados são emitidos por eles, por contraste, muitas CAs de desenvolvimento são restritas, então compromisso significaria a capacidade de emitir certificados de assinatura de código confiáveis. Sem a intenção de insultar terrivelmente um CA não é algo que um desenvolvedor deveria estar executando, é melhor deixar para aqueles que entendem as consequências, e as consequências podem ser terríveis. Depois, há rotação de certificados, revogação, OCSP e muito mais a considerar. Preciso ter uma CA de teste para meu middleware de autenticação de certificado e está em uma VM que está desligada. Fico muito nervoso quando o ligo para obter mais certificados de teste.

Se você realmente quer descer essa raiz (trocadilho intencional), https://infiniteloop.io/powershell-self-signed-certificate-via-self-signed-root-ca/ pode ajudá-lo a começar no PowerShell, mas isso não dá suporte a CRL, OCSP ou revogação. https://gist.github.com/Soarez/9688998 parece cobrir o OpenSSL. E se você precisar de CRLs, há o CA integrado ao Windows. A configuração está documentada aqui https://leastprivilege.com/2008/08/14/how-to-build-a-developmenttestdemo-ca/

_Observe que não usei nenhum dos links acima (embora confie no autor do último) e de forma alguma este é um tipo de recomendação oficial da MSFT. A recomendação oficial da equipe de segurança ASP.NET é permitir que alguém que entende de infraestrutura e riscos configure uma CA corporativa para você. Fale com o seu departamento de TI_

@blowdart Não, eu realmente _não_ quero ir para a 'raiz'. É bom saber por quê agora.

Parece que meu teste humanóide terá que ser feito na Internet pública em um host de teste usando certificados Let's Encrypt, mas com uma parede de autenticação para evitar olhares curiosos.

Dependendo do que você precisa e do seu orçamento, algumas empresas como a DigiCert oferecem serviços de PKI gerenciada. Isso pode usar uma raiz privada ou pública. Não sei os custos.

E se for apenas HTTPS, lembre-se de obter um certificado para cada subdomínio do azurewebsites.net.

Pesando sobre a nova implementação de OpenID, em vez de outra implementação para aprender, abraçar e se envolver com os esforços da comunidade de IdentityServer4 e contribuir para criar uma versão "Lite" de IdentityServer opinativa que poderia ser incluída a partir do nuget e configurada com o mínimo de esforço.

Você está exagerando.
A equipe ASP.NET já está pensando como todos vocês. @DamianEdwards falou sobre isso no mais recente Community Standup.

Aqui está a parte mais relevante (mas eu encorajo você a ouvir tudo isso):

"Na verdade, estamos conversando com o pessoal do IdentityServer sobre isso agora."
https://youtu.be/Tzh2EXwgEk8?t=25m15s

Realmente interessante ver o quão acalorada é a discussão em torno do projeto "servidor de autorização MSFT": sorria:

A propósito, Vittorio Bertocci me contatou há exatamente 2 anos para conversar sobre este projeto, pois eles estavam considerando usar o OpenIddict (o servidor OIDC que eu desenvolvo e mantenho) como base para este projeto.
No ano passado, disseram-me que eles preferiam fazer sua própria implementação em vez de aproveitar o OSS de terceiros, pois era considerado "muito estratégico" de uma perspectiva de negócios (algo que eu poderia entender).

Fico feliz em ver que eles mudaram de ideia e estão finalmente considerando usar uma solução OSS existente como IdentityServer4 em vez de criar outra coisa do zero: é um sinal muito bom enviado para a comunidade .NET: clap:

Isso vai um pouco fora do tópico, mas @CrispinH , parece que você está parecendo um pouco https://stackoverflow.com/questions/51123289/how-to-generate-a-response-to-a-csr- in-net-core-ie-to-write-a-csr-logging-se. O .NET Core 2.0 inclui outros recursos para criar e trabalhar com certificados também. Veja os comentários sobre como executar um CA também. O conjunto de ferramentas da biblioteca está quase lá e, dependendo da sua organização, você pode usar certificados de alguma forma controlada em algum servidor sem configurar muita infraestrutura. Nesse token, ler (codificados por DER) solicitações de assinatura de certificado (CSRs) prontas para usar seria uma boa adição - junto com uma biblioteca JSON-LD. E mais criptografia em geral. :)

Eu adoraria ver algum middleware como suporte para LetsEncrypt - trabalhando com serviços de aplicativos no Windows, Linux e Docker no Azure.

@kieronlanning Eu concordo, além da codificação DER com relação à assinatura CSR mencionada anteriormente (embora adicionar suporte sem casos extremos não parece tão difícil). Existem algumas bibliotecas para .NET (também listadas nas páginas Let's Encrypt), mas também alguns problemas. Por exemplo, o .NET mais ativamente mantido em relação ao Let's Encryptc parece ser um certificado , mas requer uma dependência de BouncyCastle . Seria bom se alguém o ajudasse a ser apenas .NET Standard 2.0. Uma razão para mim é que BouncyCastle não funciona bem com Orleans TaskScheduler . :)

Sobre a menção à criptografia, embora não seja estritamente um problema do ASP.NET Core, a MS aparentemente está empurrando fortemente as cadeias de blocos, mas o .NET carece da capacidade de criptografia. _Na superfície_ muito disso tem a ver com o núcleo do ASP.NET também (como, por exemplo, as várias implementações do explorador de blockchain, como https://etherscan.io/) e seria bom ter mais suporte para bibliotecas como o Inferno e apenas mais habilidades incorporadas à plataforma. Um problema pendente está em https://github.com/sdrapkin/SecurityDriven.Inferno/issues/10#issuecomment -395778931 (emprestando alguns olhos aqui se alguém tiver coragem para ajudar).

Este de @kieronlanning seria meu pedido de recurso número um:

"Eu adoraria ver algum middleware como suporte para LetsEncrypt."

Aqui está o problema em aberto: https://github.com/aspnet/Home/issues/1190. Por favor, vá e vote positivamente.

Ele está sendo considerado um pacote de mensagens disponível no núcleo do asp.net para todos os frameworks e não apenas no SignalR? Uma vez que o enquadramento do Http2 é binário, você está considerando o pacote de mensagens para isso?

servidor de autorização lançado em preview3?

Já existe. Https://IdentityServer.io

@Ultimo privilégio
Eu gosto e uso IdentityServer
Mas estou muito curioso para ver a implementação da Microsoft e entender por que (microsoft) não incorporou o servidor de identidade em seu núcleo

@ danroth27 - você pode compartilhar as últimas?

A Microsoft está usando IdentityServer.

Então, como isso está funcionando? A Microsoft usa o código IDS4 diretamente? A Microsoft reduz recursos do IDS4? Qual é o modelo aqui? Quais devem ser nossas expectativas? Existe um caminho de migração possível entre eles?

A Microsoft usará nosso pacote nuget padrão e usará nossa API de configuração para fornecer algumas configurações padrão para jogar bem com o modelo e a identidade ASP.NET. Isso é tudo.

Você pode conseguir exatamente a mesma coisa hoje.

Provavelmente sou eu, mas estou surpreso ao ler que a lacuna do servidor de autorização da Microsoft é preenchida pelo IdentityServer4. Pelo que entendi, a principal preocupação do IdentityServer é a autenticação, não a autorização.

Para mim, IdentityServer é bom como servidor de autenticação, mas não funciona como servidor de autorização. Presumi que essa era a razão pela qual o PolicyServer foi criado.

@leastprivilege O IdentityServer será estendido com algo como PolicyServer?

@Ruard Então é confuso (e Dominick provavelmente vai se encolher ou pegar na minha explicação).

OAuth é autenticação, mas tem autorização como primeira etapa e, em seguida, emite uma concessão com base em escopos etc. Portanto, em nosso empacotamento, o Identity Server realizará o login, validará, validará os escopos necessários (o que no caso inicial irá sempre bem-sucedido porque estamos usando o escopo padrão), em seguida, passe um token de volta para o chamador, que é enviado para a API que irá validá-lo e, em seguida, opcionalmente, você pode ir mais longe com as regras de autorização dentro da API. O OIDC fornece OIDC confundiu ainda mais por ser uma maneira de adquirir informações de identidade de um usuário, incluindo a autorização de que o aplicativo tem permissão para tê-las ...

Então, basicamente, o Identity Server nos dará uma identidade, autorizando que o aplicativo tenha permissão para tê-la, e então você pode usar as peças de autorização do ASP.NET para controlar ainda mais o acesso.

@MichelZ haverá uma história de crescimento. Faremos a configuração para cenários simples e, assim que você sair deles, poderá explorar todo o poder do modelo de configuração IdentityServer.

@blowdart Já usamos IdentityServer (e estamos impressionados com os recursos!), no entanto, obter o benefício das políticas de "suporte de longo prazo" da Microsoft também é uma grande vantagem para nós. Portanto, quaisquer sinergias que você possa fornecer aqui são muito bem-vindas.
Amamos os dois produtos, ASP.NET Core e IdentityServer (4) da mesma maneira. É definitivamente um passo na direção certa IMHO.
No entanto, também reconhecemos que todos esses protocolos não são exatamente "diretos". Eles não são ciência de foguetes, você os entende, mas ainda assim, eles não são diretos também.

Eu gostaria que alguém inventasse um protocolo REALMENTE simples, deixando para trás TODAS as implementações legadas e se concentrando no futuro.

Se você já estiver usando, então seu uso não mudará, você o fez funcionar :)

Nosso objetivo é Arquivo Novo> API da Web com autenticação individual e, em seguida, adicionar outras APIs, e tudo é baseado em convenção. Isso não vai funcionar para os aplicativos existentes, porque as convenções serão novas. Eu não planejaria substituir sua configuração pela nossa :)

Gostaria que alguém inventasse um protocolo REALMENTE simples, deixando para trás TODAS as implementações legadas e se concentrando no futuro.

Este é o problema - os aplicativos estão ficando mais complicados e não menos. Para protegê-los, a segurança também é complicada. Sempre recuei quando ouço as pessoas dizerem que IdentityServer é complicado - não é. São os requisitos de segurança do seu aplicativo que são complicados. Freqüentemente, as pessoas não têm perspectiva para reconhecer isso.

Sim, está funcionando - e está funcionando bem - mas ainda assim, aquela garantia adicional que (pode) dar a você, quando a Microsoft oficialmente "endossa" e finalmente "suporta" uma tecnologia é ouro puro ...!
Você foi elevado a um nível totalmente novo!

@brockallen Sim, os aplicativos provavelmente complicam MUITO as coisas. No entanto, o protocolo OIDC inegavelmente herdou algumas coisas do OAuth 2.0 que seria melhor ter descartado. Alguns membros de sua equipe (acho que foi @leastprivilege) disseram que se o OIDC fosse desenvolvido do zero, provavelmente seria bem diferente do que temos agora.

Não estou dizendo que o que temos agora é "ruim", eu realmente aprecio o que temos, e é realmente funcional para nossos propósitos, e espero que todos os envolvidos na criação dele estejam orgulhosos do trabalho que fizeram!

@Equipe;
Para a visualização 3, você poderia fornecer alguns documentos detalhados sobre o "Servidor de autorização" e como ele funcionará usando a API Web e JS do lado do cliente, como o Vue?
Precisamos tomar uma decisão e esta visualização no servidor de autorização é uma visualização crítica e quaisquer documentos detalhados nos darão informações sobre nossa decisão.

Obrigado!

Como discutido antes

https://identityserver.io

Notei que também as APIs de dados abertos dos EUA estão em JSON-LD: https://project-open-data.cio.gov/v1.1/schema/. Esta parece ser uma tendência de crescimento rápido, então uma biblioteca JSON-LD .NET com bons recursos usada com ASP.NET seria bom. :)

@veikkoeeva Assim como (pelo menos parte) das APIs NuGet. Eles estão usando json-ld.net , não há necessidade de outra biblioteca.

@khellang E há outras bibliotecas também, esta biblioteca em particular pode usar mantenedores (https://github.com/linked-data-dotnet/json-ld.net/issues/26). Sei que é um código aberto e, em teoria, poderia intervir para contribuir, mas, pelo menos por enquanto, estou muito limitado para ajudar nisso. Colocando de outra forma, talvez eu gostaria de chamar a atenção para o fato de que muitos conjuntos de dados parecem estar se movendo em direção a formatos semânticos e não está claro como trabalhar de forma eficiente com isso usando .NET.

IMHO, adicionar IdentityServer4 ao núcleo do ASP.Net Core é uma má ideia.
Por favor, não faça o .NetCore como uma estrutura monolítica.
.NetCore está lá e IdentityServer4 está lá, as pessoas fazem a arquitetura com base nas próprias necessidades de autenticação e autorização.

@mikeandersun O plano é apenas ter uma configuração padrão fácil que você pode adicionar ao seu projeto para fazê-lo funcionar

Você ainda não pode usá-lo e isso não afetará você. Você ainda pode usar o IdSrv e configurá-lo totalmente sozinho. Você ainda pode escolher quais componentes incluir em seu projeto. Nada disso está tornando o ASP.NET Core monolítico.

ASP.NET Core! = .NET Core btw.

2.2 será uma versão LTS? (Perguntar se já foi anunciado, não pedindo para você fazer um novo anúncio.)

@yzorg não, isso não foi anunciado. Essa determinação geralmente é feita após o lançamento com base na qualidade / estabilidade.

@blowdart , este modelo forneceria ao servidor de identidade um cliente MVC de aplicativo da Web em vez de uma API?

@Ponant Não. Destina-se apenas a APIs. Vamos reavaliar isso na linha do tempo 3.x.

Interessante ... Esta questão surgiu em uma reunião ontem. Se construirmos um projeto "MVC" completo sem o uso da API Web, podemos usar o novo modelo ASP.Net 2.2 IS4 que está integrado no 2.2?
Parece que o chefão (Barry) acabou de responder à pergunta.

@blowdart allias chefão: por que isso não é feito de uma só vez? Parece trivial à primeira vista usar um cliente mvc ou uma API da web conversando com um servidor IS4 de identidade de núcleo asp.net.

@Ponant Porque não temos recursos infinitos. Quais recursos você gostaria que deixássemos para colocar todos na mudança de uma parte importante do fluxo MVC que não forneceria quaisquer novos recursos, apenas mudaria o funcionamento de um existente? Uma API autenticada individual tem sido uma lacuna entre a estrutura completa e o ASP.NET Core. O foco do trabalho era preencher essa lacuna. O Identity Server já tem modelos de trabalho para MVC com o Identity Server como o "núcleo".

@CrispinH @blowdart Eu concordo totalmente com você, Administração de usuários, funções, locação e grupos de usuários são necessários desesperadamente. Olhe só - há 7 ingressos da Uservoice, todos reclamando de centenas de desenvolvedores e empresas. Infelizmente, muitas outras tecnologias como o portal Java blueRay JSR 182 ou 173 um trabalho tão bonito aqui!

-> Tantas solicitações de gerenciamento de usuários / grupos / inquilinos

-> DE NOVO aqui gente reclamando ... continua, até no twitter e no facebook .. esse é o motivo - porque outras plataformas como WP e PHP são mais fáceis!

Enquanto @manigandham acredita que o servidor de identidade é uma ótima opção, eles cobram MUITO pela ferramenta de administração da GUI e não é barata para muitos países e desenvolvedores, mas também vai contra o desenvolvedor de baixo TCO. Quantas pessoas realmente podem pagar por isso. Tem sido um obstáculo ENORME e um retrocesso, uma funcionalidade básica vanilla e GUI para gerenciar os usuários / funções / funções-grupos de usuários / inquilinos é necessária , que pode então ser aprimorada pelo desenvolvedor

@papyr Por que você simplesmente não inicia um projeto de código aberto para isso? Uma GUI completa para tudo não precisa ser construída na estrutura (modelos). E vendo como já é difícil para a equipe manter as atualizações dos modelos, por exemplo, com alterações no Bootstrap, eu realmente não quero que eles desperdicem mais esforços com isso. Mas por outro lado, entendo totalmente que seria uma coisa útil existir, então por que você simplesmente não faz isso um esforço da comunidade?

@papyr @poke não há necessidade de um novo projeto de código aberto, existem excelentes projetos existentes.

Se você quiser algo de código aberto da MS projetado para competir com o WordPress, olhe para Orchard:
https://github.com/OrchardCMS/OrchardCore

Se você quiser mais de uma abordagem de biblioteca em vez de uma estrutura, confira o cloudscribe, que tem nugets para multilocação e usuário, função e gerenciamento de reivindicações pré-construídas com uma integração opcional de servidor de identidade4 e cms opcional (cloudscribe.Simple / content) como pepitas adicionais.
https://www.cloudscribe.com/docs/introduction
https://github.com/cloudscribe/cloudscribe
https://github.com/cloudscribe/cloudscribe.SimpleContent

Se você quiser algo de código aberto da MS projetado para competir com o WordPress, olhe para Orchard:
https://github.com/OrchardCMS/OrchardCore

Apoio esta recomendação.

E o Orchard Core foi projetado para ser extremamente modular. Por exemplo, é possível extrair apenas seu módulo de multilocação e usá-lo em seus próprios projetos . Ele também já tem módulos para gerenciar usuários e funções, e tenho certeza de que eles apreciariam sua contribuição para torná-lo ainda melhor.

Você pode assistir a muitas demos de seus vários recursos em seu canal .

@papyr Por que você simplesmente não inicia um projeto de código aberto para isso?

https://github.com/IdentityManager/IdentityManager2

Essa coisa da interface do usuário pode ser complicada, embora útil para obter coisas básicas rapidamente. Parece que recentemente encontrei casos que construir a IU não é a maior tarefa, mas descobrir como preencher as "necessidades do processo", como pré-aprovar alguns e-mails (que fazem algo específico do aplicativo), chamar APIs que chamam APIs , alguns dos quais podem significar junções no banco de dados ou chamadas para outro lugar, etc. e, em seguida, adicioná-los aos tokens e à lógica da IU.

Portanto, ter bons tutoriais como https://mcguirev10.com/2018/01/28/login-identity-management-best-practices.html ou aqueles em https://mcguirev10.com/page2/ parece mais importante do que a IU ( especialmente se não se pode ou não quer usar EF). Então, talvez pesquise a interface do usuário para a tecnologia escolhida (Aurelia / Angular / Razor / React / Vue etc.) e como eles implementam algum tratamento de dados.

Sobre nomear projetos e nomes, além de @ scottbrady91 , achei muito educativo verificar @LindaLawton , https://github.com/abergs/fido2-net-lib ( @abergs , @aseigler), @TomCJones , @ mackie1001 (Gitter) etc. para fornecer explicações adicionais e código para dar uma olhada ao pisar um pouco fora da necessidade básica. Esqueci de adicionar alguns nomes e projetos. :)

Por que o .net core não pode ter páginas da web normais do razor? Quando faço relatórios complexos, gosto de fazer tudo a partir de uma única página de navalha (c #). Ou pelo menos a capacidade de usar apenas uma visualização, às vezes, sem modelo ou controlador.

Em outras palavras, a capacidade básica de se conectar ao sql na visualização e receber solicitações GET e POST, higienizada é claro, atualmente uso uma classe chamada Striptag.cs.

Por que o .net core não pode ter páginas da web normais do razor?

Você pode usar as páginas do Razor para este https://docs.microsoft.com/en-us/aspnet/core/razor-pages/?view=aspnetcore-2.1&tabs=visual-studio

Ter uma classe de modelo de página posterior é opcional; você pode ter apenas uma única página

benaadams obrigado pela resposta, como eu usaria a solicitação GET e POST diretamente em uma página do razor e faria uma conexão básica com o sql server. A conexão para consultas regulares, não entidades ado, ou linq, ou ORM. Sempre prefiro consultas normais.

Gostar:

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

Sei que a string de conexão está em um arquivo json agora, mas não sei como usá-la no modo de exibição. Algumas coisas não estão profundamente documentadas.

Bem, tem uma curva de aprendizado. Se você deseja obter dados _antes_ de carregar a visualização, faça isso na ação correspondente. Portanto, para HomeController.ViewReports action e Views/Home/ViewReports.cshtml page você escreve:

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

Se você deseja buscar dados _após_ carregamento da página, normalmente usa solicitações AJAX para algum ponto de extremidade GET / POST puro que retorna dados formatados em JSON.

Ainda pode fazer isso em uma página sem nenhum controlador ou ação; 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>
    }
}

Eu usei mvc asp.net e webforms e páginas antigas do Razor, então não sou novo nisso. Passei 3 horas e ainda não consigo fazer uma página simples de teste de navalha funcionar, eu:

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

Apenas uma página html e carrega.

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

Visualizar:

<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 e tudo o que recebo é uma página em branco. Tentei uma declaração de retorno, etc.

Se eu apenas digitar http: // localhost : 51307 / pets / razdb3, recebo a segunda divisão "olá", mas
o @ Model.myvar não recebo nada.

Sou novo no núcleo .net e nunca teria imaginado que seria ou poderia ser tão difícil exibir uma página de barbear.

Na comunidade VS 2017

o @ Model.myvar não recebo nada.

Você define o myvar em uma solicitação de postagem ( OnPost ) com o valor do formulário psearch ; então você precisaria fazer uma solicitação POST com esse valor para defini-lo?

Na solicitação GET ( OnGet ) que você obtém apenas navegando para a url no navegador; em vez de um postback de formulário, não está definido para nada.

Tente defini-lo com um valor padrão para que apareça quando você não o definir para confirmar que o modelo está fluindo:

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

Mudou para

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

E ainda uma página em branco. @ Model.myvar está correto?

até mudou para

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>

Ele cria bem sem erro, mas uma página em branco, não importa o que eu tente.

Comentários / pensamentos educados: parece que esta discussão sobre "páginas normais de barbear" está começando a sair um pouco do tópico em relação ao assunto deste tópico.

😊 😊

Desculpe, eu percebi que deveria ter usado o fórum. Obrigado @benaadams seu código me colocou no caminho certo e eu encontrei este:

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

É assim que eu normalmente fazia as coisas de qualquer maneira, usando a palavra-chave "nova", como

EmployeeDataAccessLayer objemployee = new EmployeeDataAccessLayer();

Foi reconfortante ver que você ainda pode usar classes personalizadas no núcleo .net.

Você tem que admitir, .net core tem uma curva de aprendizado mais íngreme do que alguns frameworks asp.net anteriores. Muito obrigado.

As notas de lançamento falam sobre um recurso de "Servidor de Autorização" esperado como complemento nos próximos meses. Há mais informações disponíveis sobre este recurso? Estou tentando decidir se devemos esperar por isso. Ou construir nossa própria solução.

As notas de lançamento falam sobre um recurso de "Servidor de Autorização" esperado como complemento nos próximos meses. Há mais informações disponíveis sobre este recurso? Estou tentando decidir se devemos esperar por isso. Ou construir nossa própria solução.

Acho que o plano atual é usar https://github.com/IdentityServer/IdentityServer4 de uma forma "pré-embalada".

Seguindo as observações da equipe do IS4 e da equipe de segurança da MS, parecia que a MS estava simplesmente tentando fazer um empacotamento rápido e sujo do IS4 e encerrar o dia. Mas parece que alguém com mais sabedoria decidiu se conter e fazer da maneira certa, pois a segurança pode criar efeito cascata quando não é feita da maneira certa.

Espero que uma integração completa entre IS4 e ASP seja feita para suportar AMBOS a API Web e MVC.

Hoje em dia, a autenticação / autorização de força industrial é exigida no mínimo. Código aberto (OSS) é bom para a maioria das coisas, mas tem havido sérias dúvidas em alguns produtos de segurança de software livre que não são aceitáveis ​​em qualquer site corporativo. 85% dos projetos usam bibliotecas desatualizadas que são um risco de segurança inaceitável. Por exemplo, 45% dos servidores da web usam Apache (https://www.cvedetails.com/vendor/45/Apache.html), que tem muito mais vulnerabilidades do que o IIS (https://www.cvedetails.com/product/3436/ Microsoft-IIS.html? Vendor_id = 26). Produtos como o Identity Server podem ser bons, mas os ajustes do desenvolvedor podem torná-los completamente inseguros. Precisamos de uma solução integrada no Net Core que seja sempre segura ...

Hoje em dia, a autenticação / autorização de força industrial é exigida no mínimo. Código aberto (OSS) é bom para a maioria das coisas, mas tem havido sérias dúvidas em alguns produtos de segurança de software livre que não são aceitáveis ​​em qualquer site corporativo. 85% dos projetos usam bibliotecas desatualizadas que são um risco de segurança inaceitável. Por exemplo, 45% dos servidores da web usam Apache (https://www.cvedetails.com/vendor/45/Apache.html), que tem muito mais vulnerabilidades do que o IIS (https://www.cvedetails.com/product/3436/ Microsoft-IIS.html? Vendor_id = 26). Produtos como o Identity Server podem ser bons, mas os ajustes do desenvolvedor podem torná-los completamente inseguros. Precisamos de uma solução integrada no Net Core que seja sempre segura ...

Seu ponto está absolutamente correto. Mas em alguns vídeos, a equipe da MS disse, que eles não vão reinventar as rodas [de segurança] e usar um sistema de terceiros [IS4]. Portanto, espero que seja uma situação ganha / ganha para todos nós.

Hoje em dia, a autenticação / autorização de força industrial é exigida no mínimo. Código aberto (OSS) é bom para a maioria das coisas, mas tem havido sérias dúvidas em alguns produtos de segurança de software livre que não são aceitáveis ​​em qualquer site corporativo. 85% dos projetos usam bibliotecas desatualizadas que são um risco de segurança inaceitável. Por exemplo, 45% dos servidores da web usam Apache (https://www.cvedetails.com/vendor/45/Apache.html), que tem muito mais vulnerabilidades do que o IIS (https://www.cvedetails.com/product/3436/ Microsoft-IIS.html? Vendor_id = 26). Produtos como o Identity Server podem ser bons, mas os ajustes do desenvolvedor podem torná-los completamente inseguros. Precisamos de uma solução integrada no Net Core que seja sempre segura ...

Nada é "sempre seguro", especialmente algo da Microsoft;)
Está sempre nas mãos do usuário essas coisas para torná-las e mantê-las seguras.

IdentityServer será incluído em novos modelos de envio de postagem 2.2. O foco inicial será o controle de acesso à API - mas há planos para expandir isso no futuro.

O ASP.NET Core será fornecido com uma API de configuração simplificada que cobre apenas os cenários de modelo - mas será muito fácil de começar. Você pode, a qualquer momento, fazer a transição para o sistema de configuração nativo IS, que oferece cenários avançados.

IdentityServer será incluído em novos modelos de envio de postagem 2.2. O foco inicial será o controle de acesso à API - mas há planos para expandir isso no futuro.

O ASP.NET Core será fornecido com uma API de configuração simplificada que cobre apenas os cenários de modelo - mas será muito fácil de começar. Você pode, a qualquer momento, fazer a transição para o sistema de configuração nativo IS, que oferece cenários avançados.

Obrigado pela informação Dominick;
Acho que esse "trampolim" ajudará muitos a começar e depois fazer a transição para o SI total. Boa jogada.

IdentityServer será incluído em novos modelos de envio de postagem 2.2. O foco inicial será o controle de acesso à API - mas há planos para expandir isso no futuro.

O ASP.NET Core será fornecido com uma API de configuração simplificada que cobre apenas os cenários de modelo - mas será muito fácil de começar. Você pode, a qualquer momento, fazer a transição para o sistema de configuração nativo IS, que oferece cenários avançados.

Bom saber! Obrigada.

Eu acho que esse controle de acesso da API será baseado em escopos OAuth?
Não há suporte direto para permissões de usuário mais voláteis, como descrito em policyserver.io?

IdentityServer será incluído em novos modelos de envio de postagem 2.2. O foco inicial será o controle de acesso à API - mas há planos para expandir isso no futuro.
O ASP.NET Core será fornecido com uma API de configuração simplificada que cobre apenas os cenários de modelo - mas será muito fácil de começar. Você pode, a qualquer momento, fazer a transição para o sistema de configuração nativo IS, que oferece cenários avançados.

Bom saber! Obrigada.

Eu acho que esse controle de acesso da API será baseado em escopos OAuth?
Não há suporte direto para permissões de usuário mais voláteis, como descrito em policyserver.io?

PolicyServer é uma solução comercial

Eu acho que esse controle de acesso da API será baseado em escopos OAuth?
Não há suporte direto para permissões de usuário mais voláteis, como descrito em policyserver.io?

"Apenas" IdentityServer. ASP.NET Core tem uma API interna para autorização do usuário - e se PolicyServer (o produto) parecer interessante para você, me avise.

Encerrando este problema porque o ASP.NET Core 2.2 foi enviado.

não deve ser atualizado para ASP 3.0

Alguma atualização sobre quando os aprimoramentos do Authorization Server serão enviados?