EF Core 2.2 로드맵은 어떻습니까?

EF Core 2.2 로드맵은 어떻습니까?

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

로드맵, 특히 상태 확인 및 HTTP 2.0이 좋아 보입니다. 그러나 가장 친절한 방법 으로 간단한 자사 Microsoft 인증 서버를 구축해야 하는 필요성에 동의하지 않습니다. IdentityServer4는 이 격차를 잘 메우며 더 간단한 버전을 다시 구현하는 데 소요되는 시간을 다른 곳에서 더 잘 보낼 수 있습니다. 목표는 간단한 솔루션을 제공하는 것이지만 인증은 어렵고 IdentityServer는 가능한 한 간단한 API를 제공합니다. 더 간단한 추상화에 대한 아이디어가 있는 경우 IdentityServer 위에 구축할 수 있으므로 사람들이 간단한 추상화를 사용할 수 있지만 필요한 경우 권한을 가질 수 있습니다.

업데이트

ASP.NET 커뮤니티 스탠드업에서 ASP.NET Core 팀이 Identity Server 위에 무언가를 구축하는 것을 포함하여 옵션에 대해 Identity Server 팀과 이야기하고 있다고 언급했습니다. 그것이 우리 모두가 원하는 것이라고 생각합니다. 잘했습니다!

ASP.NET Core WebHooks에 대한 현재 계획은 무엇입니까?

Dispatcher와 관련하여 미들웨어에서 이것이 가능합니까? 😱
C# public async Task Invoke(HttpContext context, [FromRoute] SomeModel someModel)
^{[프롬쿼리]?}

단순 인증 서버이지만 Katana 단순 인증 서버에서 발생한 일을 기억하십시오.

@RehanSaeed의 우려를 반영하고 이 새 서버가 채워야 하는 정확한 사용 사례에 대한 설명을 요청하고 싶습니다. 이것이 기본적으로 웹 API가 앱의 기존 인증 내에서 유효한 전달자 토큰을 얻을 수 있는 방법이라면 괜찮을 것입니다. 그러나 그 위에 있는 모든 것은 이미 IdentityServer, OpenIddict 및 AspNet.Security.OpenIdConnect.Server와 같은 제품으로 다양한 복잡성과 유연성의 많은 옵션을 제공하는 기존 솔루션에 맡기는 것이 더 나을 것입니다.

IIS 인프로세스 호스팅은 어떻습니까?

"API 클라이언트 생성(C# & TypeScript)"의 TypeScript 부분에 대해 더 자세히 설명해 주시겠습니까?

이것은 내가 정말 기대하는 것입니다. 현재 저는 Angular 클라이언트 API 서비스를 자동 생성하기 위해 NSwag를 사용하고 있습니다. 그러나 클라이언트 구성에 대해 가능한 다양한 조합이 있으므로 이것이 모든 사람을 기쁘게 하는 데 문제가 될 수 있다고 생각합니다.

내 머리 꼭대기에서 고려해야 할 몇 가지 사항(가능하면 구성 가능해야 함):

• 가져오기가 있는 TypeScript 클라이언트 또는 HttpClient가 있는 Angular 서비스입니까?
• Angular라면 어떤 버전을 지원합니까(RxJS에서도 중요)?
• null/정의되지 않은 처리
• 열거형 처리
• 날짜 유형에 대한 JS 날짜 또는 momentjs?
• 예외 처리, 유효성 검사 오류 처리
• 클라이언트에서 생성된 코드를 확장하는 방법은 무엇입니까?
• 이름 생성에 영향을 줄 수 있는 가능성(예: 생성된 클라이언트 클래스에 대해 xxxDTO에서 DTO 부분 삭제 또는 이미 OpenAPI 정의에 있음)

기능에 투표할 수 있다면 기존 미들웨어에 대한 이러한 개선 사항/수정 사항이 내 위시리스트에 포함될 것입니다.

• Let Encrypt는 https://github.com/aspnet/Home/issues/1190을 지원
• Response Cache 미들웨어는 기본적으로 오늘날처럼 사용할 수 없습니다. Redis 응답 캐시 저장소 및 캐시된 응답의 사용자 작업에 대한 확장성을 추가하면 https://github.com/aspnet/Home/issues/2606 이 해결
• GZIP 이전 및 BR 인코딩된 파일 제공 지원 .
• Brotli 압축 공급자 를 여러 문제 를 수정합니다.

또한 Authorization Server 제품을 건너뛰는 데 투표합니다. 보안은 복잡하고 유지 관리를 제거하기 위해 클라우드 서비스로 이동하려는 큰 움직임이 있었습니다. 더 많은 제어를 원하는 사람은 이미 잘 구축되고 테스트되고 문서화되고 지원되는 IdentityServer4 를 사용할 수 있습니다. 간단한 설정에는 5분이 소요되며 많은 시작 샘플, 비디오 및 자습서가 있습니다.

나는 당신이 할 수 있는 것보다 더 이상 "제로 구성"으로 보안을 작동시킬 수 있는 방법을 알지 못합니다. 이것은 (이름 지정 및 사용에서) 혼란을 더 가중시키는 반면, 다른 기능에 대한 노력을 지속적으로 빼면서 수년간 지원하고 유지 관리해야 하는 또 다른 항목이 될 것 같습니다. 다시 생각해 보십시오.

또한 IIS 인프로세스 호스팅이 이 2.2 로드맵에 없는 이유도 궁금합니다. 이 주요 기능이며 스택 오버플로에서 여기에 우리의 출시 전략 및 일정의 주요 요인이며, 이미 대신 2.2 기간을 약속, 2.1 릴리스 전에 매우 마지막 순간을 제거했다 . 이것은 단지 실수일 뿐이며 또 다른 계획 변경이 아님을 알려주세요.

편집: @DamianEdwards 는 Twitter 에서 이것이 실제로 실수 라고 답했습니다(2.2로 계획됨을 의미함). 휴!

다른 의견을 반영하겠습니다. Authorization/Policy, 특히 더 단순하게 만드는 데 투자하려는 경우 문서 및 스캐폴딩에 대한 투자에 대해 OpenIddict 및 IdentityServer와 같은 파트너와 개인적으로 훨씬 더 많은 협력을 원합니다. 아무리 단순해도 모든 작업은 결국 엄청난 타사 작업을 복제하고 aspnet 팀에 불필요한 유지 관리 비용을 초래하게 될 것이라는 느낌을 지울 수 없습니다.

인기가 없을 수도 있지만 우리의 의견과 지원을 받아 대중의 눈에 띄는 Microsoft Auth Server를 보고 싶습니다.

현재의 Id4, OpenIddict는 분명히 우수한 OSS 프로젝트이고, 그 뒤에 MS의 지원을 받는 프로젝트가 나쁜 일이 될 수 있다는 느낌을 지울 수 없습니다...?

소수의 사람들이 제공할 수 있는 지원의 양에는 한계가 있으며 이는 결국 미션 크리티컬한 제품입니다.

MS OSS 행동 강령에 "Nuget 요청으로 가져올 수 있는 기능을 복제하는 기능을 홍보하지 마십시오. 우리 생태계에 기여합니다."

내 안의 냉소주의자들은 일부 내부자들에게 Brock과 Dominick에게 피 묻은 코를 주는 것이 버그가 아니라 이 제안의 특징인지 궁금해하지 않을 수 없습니다. ASP 팀이 하는 모든 일을 냉정하게 비판하는 소기업에게 이런 일이 발생합니까?

또한 UI 및 문서와 같이 맨 위에 무언가를 구축하는 것 외에 인증 기능을 복제하는 것에 대해 궁금합니다.

또한, 잘 테스트된 JSON-LD 1.1 라이브러리는 로드맵에 훌륭하고 구체적인 추가 사항이 될 것입니다. :)

다른 사람들이 말한 것을 반복하십시오 - 나는 스스로 새로 구현하는 것보다 IdentityServer4와 같은 것으로부터 승인 작업을 가져오는 것을 훨씬 더 보고 싶습니다. 격차가 있는 경우 기여, 샘플 및 개선된 통합 지점을 통해 격차를 확실히 연결하는 것이 더 나은 방법이 될 것입니다. 끔찍한 상태에 있는 이 공간(B2C)에서 제공하는 클라우드에도 주의를 기울이십시오.

그 외에도 목표는 기존 오픈 소스 제품의 기능을 복제하지 않고 일을 단순하게 유지하는 것이지만 이는 고전적인 재작성 함정과 다소 동일합니다. "이 솔루션은 지나치게 복잡하고 약간 지저분합니다. 다시 작성하겠습니다! ". 순진하고 n 버전에서는 실제 솔루션이 필요로 하고 IdentityServer와 같은 것이 이미 처리하고 있는 많은 엣지 케이스를 처리한 데 돈을 투자할 것입니다.

보다 광범위하게는 GitHub 인수와 함께 최근 오픈 소스에 대한 Microsoft의 태도에 대해 많은 논의가 있었습니다. Microsoft가 오픈 소스에서 많은 일을 하고 있지만 훌륭한 오픈 소스 시민이 되는 것의 일부는 기존 오픈 소스가 존재할 때 이를 활용하는 것입니다.

이는 기존 오픈 소스 제품의 기능을 복제하는 플랫폼 소유자인 귀하와 같은 플랫폼 보유자에게 특히 중요합니다. 기고를 _권장하는 동시에 해당 제품에 참여 _권장_합니다.

나도 권한 부여에 노력의 요점을 볼 수 없지만 ASP.NET Core ID의 _management_가 개선되기를 바랍니다. Damian Edwards는 live.asp.net에서 우리가 자체 보안을 롤백해서는 안 된다고 분명히 밝혔지만 - 제가 그것을 놓친 경우가 아니라면 - ASP.NET Core Identity에는 사용자 관리 도구가 포함되어 있지 않으므로 롤링해야 합니다. 우리 자신의. 나는 보안 전문가가 아니며 내가 만든 보안 허점을 남기는 것을 매우 두려워하기 때문에 약간 무섭습니다.

MVC 수준에서 2.2의 AspNetCore.Http 추상화로 콘텐츠 포맷터를 이동하는 것은 어떻습니까?

담당 PM이 이 Identity Server Lite에 대한 보다 자세한 설명을 작성하여 ASP.NET 팀이 해결하고자 하는 기존 타사 오픈 소스 솔루션의 단점을 정확히 명확히 할 수 있습니다. 있는 그대로, 당신은 바퀴를 재발명하지만 일부 스포크를 제거하는 것에 대해 이야기하고 있고 그것은 별로 의미가 없기 때문입니다. 다른 누군가가 말했듯이 AAD B2C를 수정하고 이에 대한 최고 수준의 통합을 제공하는 것은 훌륭하고 MS에 비즈니스 의미가 있습니다.

또한 @blowdart를 지나서 완전히 새로운 Auth 서버 제품을 얻는 것이 얼마나 어려운지 생각해 본 적이 있습니까?

django와 같은 내장형 RESTful API 지원을 가질 계획이 있습니까?
모든 개발자가 매번 작성하는 경향이 있기 때문입니다!

최근에 Generic RESTful API 컨트롤러로 작성할 수 있는 것을 만들었습니다.

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

또한 "나는 당신이 할 수 있는 것보다 더 이상 "제로 구성"으로 보안을 작동시킬 수 있는 방법을 알지 못합니다." 및 "당신은 바퀴를 재발명하지만 아마도 일부 스포크를 제거하는 것에 대해 이야기하고 있습니다"에 동의합니다. ID 서버는 정말 멋진 제품입니다. 시작하기 쉽고 더 복잡한 시나리오에 대한 확장성을 제공하지만 왜 "단순화" 버전이 필요한지 잘 모르겠습니다.

훨씬 더 작은 규모에서 왜 다른 상태 확인 구현이 필요한가요? 이미 여러 오픈 소스 솔루션이 있습니다.

• https://github.com/Xabaril/BeatPulse , 미리 작성된 수표가 포함되어 있으며 UI도 함께 제공됩니다.
• https://www.app-metrics.io/web-monitoring/aspnet-core/health/

이들과 2.2에서 제공되는 기능의 차이점은 무엇입니까?

@0xRumple ApiController에 대한 개선 사항은 일반적으로 이것을 덜 장황하게 만드는 데 도움이 될 것입니다. 그러나 아니요, 기본적으로 엔터티에 대한 CRUD API를 제공하는 것을 볼 수 없을 것입니다. 그러한 일은 DAL 및 권한 부여에 대해 너무 많은 가정을 해야 합니다.

애플리케이션에서 특정 패턴을 따른다면 2.2에서 작업을 일반화하는 고유한 기본 유형이나 규칙을 만드는 데 아무런 문제가 없습니다.

@kieronlanning

현재의 Id4, OpenIddict는 분명히 우수한 OSS 프로젝트이고, 그 뒤에 MS의 지원을 받는 프로젝트가 나쁜 일이 될 수 있다는 느낌을 지울 수 없습니다...? 소수의 사람들이 제공할 수 있는 지원의 양에는 한계가 있으며 이는 결국 미션 크리티컬한 제품입니다.

당신이 그것이 나쁜 일이 될 수 있는지에 대해 물었기 때문에:

ASP.NET 팀도 상대적으로 작기 때문에 제한된 용량으로 수백만 명의 개발자에게 서비스를 제공하므로 새 프로젝트는 다른 일에서 시간과 노력을 들이게 됩니다. 이는 우리 모두가 더 많은 가치를 제공할 수 있는 새로운 기능을 얻기 위해 더 오래 기다려야 함을 의미합니다.

훨씬 더 나쁜 것은 Microsoft가 "공식" 패키지를 출시하기 때문에 제3자 생태계에 피해를 입히고 신제품을 낙담시킨다는 것입니다. 많은 회사는 기술적으로(이 경우에는 더 낮아야 함) Microsoft에서 제공한다는 이유로 선택에 어려움을 겪습니다. 유능한. ASP.NET은 이미 Json.NET, Polly, AutoMapper 및 기타 많은 라이브러리를 통합하고 있으므로 훌륭한 옵션이 이미 존재하는 경우 이러한 복잡한 보안 제품(동일한 기본 코드의 80%가 필요함)을 다시 빌드하는 것은 실수처럼 보입니다. 로드맵에 더 많은 흥미로운 것들이 있습니다.

@찌름
내 앱의 기본 클래스를 작성하는 것은 좋은 생각입니다.

사실 나는 그것들이 프레임워크 책임 내에 있지 않다고 생각합니다.

CRUD resources (repository responsibility)

Manipulating data (sieve responsibility)
    Paging
    Filtering
    Searching
    Sorting
    Shaping

그러나 AspNetCore가 AspNetCore.RestFramework 패키지를 사용하여

1. HATEOAS(자체 검색 가능한 API)
2. 미디어 유형(사용자 정의 미디어 유형 설정)
3. 버전 관리(미디어 유형 버전 업데이트)
4. 조작된 데이터 메타데이터(X-Pagination 헤더로의 페이지 매김, 필터 메타데이터 등).
5. 속도 제한 및 조절.

거기에 수많은 라이브러리가 있다는 것을 알고 있습니다. 여기에서 일부를 찾았습니다. https://github.com/thangchung/awesome-dotnet-core... 하지만 타사 라이브러리는 엔터프라이즈 앱에 실제로 좋은 옵션이 아닙니다!

체도 마찬가지입니다. 페이지 매김, 필터링 등을 위한 공식 패키지가 있는 경우 개발자는 버그가 있거나 유지 관리되지 않는 라이브러리를 작성하는 경향이 없습니다. 위에서 언급한 내 앱에서 이 체를 사용했습니다: https:// github.com/Biarity/Sieve 하지만 이 라이브러리는 작성자가 바 유지 관리되지 않을 수 있습니다.

AspNetCore는 django에서처럼 즉시 사용 가능한 솔루션에 대해 생각할 만큼 충분히 성숙했다고 생각합니다. 이렇게 하면 asp 성능 의 고급스러움과 django 의

그러나 타사 라이브러리는 실제로 엔터프라이즈 앱에 좋은 옵션이 아닙니다!

^^ 이래서 우리가 좋은 걸 가질 수 없어요 😞

그러나 타사 라이브러리는 실제로 엔터프라이즈 앱에 좋은 옵션이 아닙니다!

네, 바로 여기에서 바뀌어야 하는 마음가짐입니다. ASP.NET Core 및 .NET Core는 오픈 소스이며 해당 에코시스템은 오픈 소스 커뮤니티를 _포용하고 있으며 계속 그렇게 해야 합니다. .NET Foundation의 일부인 오픈 소스 솔루션뿐만 아니라 실제로 모든 솔루션을 사용할 수 있습니다.

하지만 이 라이브러리는 작성자가 바빠서 유지 관리되지 않을 수 있습니다.

그리고 같은 방식으로 "공식적인" 패키지는 회사가 관심을 옮기는 즉시 유지 관리되지 않게 될 수 있습니다. 이것은 게시한 여러 오픈 소스 패키지를 포함하여 이전에 Microsoft 특정 일에서 발생했지만 모든 회사에서 정말 자연스러운 일입니다.

다른 사람의 라이브러리에 대한 종속성을하기로 결정하면, 당신이 그와 함께 살 수 있다는 것은 귀하의 책임입니다. 그 작가가 누구이든 상관없이 말이다. 오픈 소스의 좋은 점은 작성자가 응답하지 않더라도 사용자 가 직접 변경할 수 있다는 것입니다.

나는 당신이 제시할 수 있는 모든 것에 대한 공식 Microsoft 솔루션을 기대 하는 것에 대해 강력히 반대 합니다. 만능 솔루션이 없기 때문에 매우 어렵고 동시에 손에서 벗어날 가능성이 높기 때문일 뿐만 아니라 특히 주의가 필요한 프레임워크 부분에서 리소스를 빼앗아 가기 때문입니다. 그리고 동시에 그것은 오픈 소스 아이디어에 정말 나쁜 영향을 미칩니다 .

엔터프라이즈 애플리케이션을 구축하고 있지만 여전히 이 NIH 증후군(또는 "<대형 회사>에서 발명되지 않음")으로 어려움을 겪고 있다면 2018년이므로 이제 깨어나야 하며 지금 오픈 소스를 수용해야 할 것입니다.

Microsoft는 패키지 유지 관리를 중단할 수 있지만 최소한 특정 LTS가 있습니다. https://www.microsoft.com/net/support/policy

예를 들어 .NET Core 1.1 지원은 2019년 6월 27일에 종료됩니다... 이렇게 하면 이 버전을 사용하면 중간에 장애가 발생하지 않을 것이라고 확신할 수 있습니다.

한 번 타사 페이지 매김 태그 도우미를 사용했는데 기분이 좋지 않았습니다. 작성자는 기본적으로 .NET Core 1.1용으로 수정하지 않을 것이며 프로젝트를 업데이트해야 한다고 말했습니다. 이 프로젝트는 대학 시스템이었습니다. 2.0( 그는 그 패키지를 무료로 작성했기 때문에

여기 문제가 있습니다. 기업에서는 이것이 작동하지 않습니다... 앱이 실행되는 동안 2.0으로 전환해야 한다고 전체 팀을 설득할 수 없습니다. 일!
따라서 내가 데코레이터를 사용하여 했던 것처럼 소스 해킹을 시작하면 됩니다. https://github.com/cloudscribe/cloudscribe.Web.Pagination/issues/37

그리고 네, 누가 제가 오픈 소스의 열렬한 팬이 아니라고 말했습니까? :confused: ?

@0xRumple 은 기여하고 협업하는 오픈 소스의 아이디어가 아닌가요?

타사 페이지 매김 태그 도우미가 존재하지 않는 경우 "기업에서" 직접 작성하고 유지 관리해야 합니다.

여기 문제가 있습니다. 기업에서는 이것이 작동하지 않습니다... 앱이 실행되는 동안 2.0으로 전환해야 한다고 전체 팀을 설득할 수 없습니다. 일!

"전체 팀을 설득하여 2.0으로 옮겨야 한다고 설득"하는 대신, 다른 사람이 작업을 수행하거나 Microsoft가 동등물을 제공하기를 기다리기보다 업데이트를 다시 제공하고 도움을 제공하십시오. 소유자가 귀하의 기여를 수락하기를 원하지 않으면 귀하의 필요에 따라 포크를 진행하십시오.

귀하의 사고 유형(전혀 불쾌감을 주지 않음)이 "Microsoft 인증 서버"와 identityserver에 대한 논의가 있는 이유의 큰 부분을 차지한다고 생각합니다. 개발자가 참여하지 않으려면 오픈 소스가 어떻게 작동합니까? Microsoft가 필요한 모든 코드를 제공할 때까지 기다려야 합니까?

Microsoft가 모든 것을 자체적으로 대체하여 생태계에서 좋은 오픈 소스 프로젝트를 죽이지 않도록 주의해야 한다는 많은 의견에 동의합니다.

저는 실제로 @0xRumple이 언급한 페이지 매김 taghelper 라이브러리의 작성자입니다. 그의 문제는 실제로 1.x aspnet 코어를 지원하는 이전 너겟이 있는 taghelper가 아닌 pagedlist 구성 요소와 관련이 있습니다. 페이징된 목록은 실제로 내 라이브러리의 디자인을 알려주고 한 번에 데모 페이지에서 사용된 이전 오픈 소스 호출기 라이브러리의 일부였지만 호출기 taghelper는 페이징된 목록 구현에 의존하지 않고 다른 페이징된 호출기 taghelper를 사용하는 동안 사용할 수 있었던 구현을 나열합니다. 사실 나는 taghelper의 일부도 아니었고 결코 없었기 때문에 그 라이브러리에서 페이지 목록을 완전히 제거했습니다.

aspnet core 1.1에 갇힌 경우 새 프레임워크로 업데이트하지 않는 한 aspnet core 2.x에서 수정 및 개선 사항을 얻을 수 없다는 점에서 Microsoft와 OSS 개발자의 nuget 패키지를 사용하는 것과 실제로 다르지 않습니다.

@joeaudette
내장 솔루션과 타사 솔루션에 대한 제 요점을 설명하기 위해 방금 그 예를 언급했습니다. 여전히 페이지 매김 태그 도우미에 대한 귀하의 작업에 감사드립니다... 대학은 페이지 매김 패키지를 사용하며 만족합니다 :heart:

@알하디

Microsoft가 필요한 모든 코드를 제공할 때까지 기다려야 합니까?

이것이 주요 문제입니다. 우리는 Microsoft가 공식 솔루션을 제공할 때 다른 오픈 소스 솔루션과 싸우거나 스스로 모든 단일 코드 라인을 작성할 것이라고 생각합니다.스마일:

물론 아닙니다. Microsoft가 올바른 솔루션을 채택하고 누락된 솔루션을 만들어 개발자가 해당 솔루션에 기여하는 데 집중할 수 있다면 공식 솔루션 과 커뮤니티 기반 솔루션 이라는 두 가지 장점을 모두 누릴 수 있습니다.

django 커뮤니티가 올바르게 이해했습니다. RESTful 프레임워크와 같은 특정 문제에 대한 초기 간단한 솔루션을 공식적으로 제공/채택하고 그 위에 커뮤니티를 구축합니다. django-rest를 구축하는 초기 단계를 여기에서 살펴보세요. 프레임워크: https://www.djangoproject.com/weblog/2016/jun/22/django-rest-framework-funding/

그들은 초기 프로젝트를 시작했고 커뮤니티는 그 위에 개선/구축 중입니다. https://github.com/encode/django-rest-framework... 약 800명의 기여자가 있는 저장소입니다!
그리고 커뮤니티는 django-rest-auth 또는 django-rest-framework-jwt 와 같은 패키지 위에 문제를 해결하는 패키지를 빌드하도록 주도됩니다.

최소한 django-admin-site 또는 django-debug-toolbar 와 같이 대부분의 개발자에게 필요한 "공식 솔루션"을 제공합니다. 이것은 "배터리 포함"이라는 Python 철학에서 비롯된 것입니다. 처음에는 최소 공통 분모 솔루션을 위해 노력하는 것이 나쁘다고 생각했지만 나중에 그것이 가져오는 바람을 깨달았습니다.

*PS: Dapper(StackExchange)와 EFCore(Microsoft)는 둘 다 ORM이지만 동일한 문제를 다른 접근 방식으로 해결하는 것을 목표로 합니다. Dapper는 2011년에 처음 만들어졌지만 EFCore 2014는... EFCore가 오픈 소스 프로젝트에 나쁜 영향을 미쳤습니까? 물론 그렇지 않으며 공식 솔루션입니다!
https://github.com/crhairr/EntityFrameworkCore.MongoDb/ 와 같이 사람들은 이미 그 놀라운 것들을 기반으로 구축하고

EFCore가 오픈 소스 프로젝트에 나쁜 영향을 미쳤습니까?

Uuuh, 누구든지 NHibernate(기능면에서 EF에 가장 가깝다)를 기억합니까? 아니, 아마 아닐거야, 왜냐면 EF가 출시된 후 죽은 거나 마찬가지니까 😕

@0x럼플

물론 그렇지 않습니다. Microsoft가 올바른 솔루션을 채택하고 누락된 솔루션을 만들면 공식 솔루션과 커뮤니티 기반 솔루션의 두 가지 장점을 모두 누릴 수 있습니다.

이 경우 기존 솔루션을 다시 만들기 때문이 아니라 의도적으로 더 적은 기능을 사용하기 때문입니다.

Entity Framework와 Dapper는 매우 다릅니다. EF는 항상 모든 기능을 갖춘 ORM이 되도록 설계되었으며 둘 다 2007년 원래

그러나 나는 당신이 틀렸다고 생각하지 않으며 우리 모두가 서로 과거에 대해 이야기하는 것 같습니다. 스레드는 웹 프레임워크에 포함하기에 충분히 작고 집중된 것처럼 보이는 REST 관련 라이브러리에 대해 이야기하는 동안 대부분 인증 서버 제품에 대한 설명입니다. 표준화된 search/paging/filter 매개변수가 Web API 코드에 내장되어 있으면 도움이 될 것이라는 데 동의합니다.

이 논의는 일부 조직에서 개발자가 솔루션에 도입된 모든 단일 오픈 소스 패키지를 설명해야 한다는 불편한 진실을 인정하는 것이 아닙니다. 어떤 경우에는 비기술적 위험 관리자가 검토해야 하는 "위험" 보고서를 생성하는 자동 스캔입니다. 이러한 도구는 적극적으로 유지 관리되지 않는 모든 항목과 카피레프트 라이선스처럼 보이는 항목에 플래그를 지정합니다.

또한 이러한 조직에서 오픈 소스에 다시 기여하는 것이 미친 이야기로 간주된다는 것을 상상할 수도 있습니다.

예, Identity Server 4는 훌륭합니다. 그러나 비기술적 위험 관리자에게는 우리가 보증하지 않는 것, 소수의 사람들이 지원하는 것, 더 나쁜 것은 모든 사람이 볼 수 있는 소스 코드가 있는 것입니다. 이 사람은 잘못 인도되었지만 지상의 평범한 개발자는 이 싸움에서 이기지 못할 것입니다.

@markrendle이 적절하게

@edandersen

그러나 비기술적 위험 관리자에게는 우리가 보증하지 않는 것, 소수의 사람들이 지원하는 것, 더 나쁜 것은 모든 사람이 볼 수 있는 소스 코드가 있는 것입니다.

Microsoft에 비용을 지불하는 것처럼 IdentityServer 사람들이 비용을 지불하면 지원을 제공할 것이라고 확신합니다. OSS는 무료와 동일하지 않습니다.

Microsoft의 ASP.NET Core 팀이 "소수의 사람들"이 아니라고 생각하는 이유는 무엇입니까? 스포일러... 다 합치면 20~30명 정도 됩니다. 그런 제품을 만드는 작업을 하는 사람은 몇 명뿐입니다.

"모든 사람이 볼 수 있는 소스 코드"가 왜 나쁜지 정말 궁금합니다. 그리고 Microsoft의 이 제품이 오픈 소스가 아닐 것이라고 생각하는 이유는 무엇입니까? 새로운 기본값입니다.

@khellang "모든 사람이 볼 수 있는 소스 코드"를 분명히 하는 것은 좋은 일입니다! 그러나 일부 개발자가 직장에서 주장해야 하는 주장에 놀랄 것입니다. 불행히도 "Microsoft가 작성했습니다"라는 점은 때때로 받아들일 수 있는 유일한 주장입니다. 참고 저는 가상이지만 일반적으로 기능하지 않는 회사에 대한 악마의 옹호자 역할을 하고 있습니다.

물론 동일한 개발자가 고용주가 Identity Server에 대한 지원 비용을 지불해야 한다고 주장할 수 있지만 조달 프로세스는 아마도 생존 의지를 앗아갈 것입니다.

글쎄, 우리가 이러한 비기술적 관리자 주장을 사용하기 시작하면 상황이 미쳐지기 시작할 것입니다. 기술이 아닌 IMHO는 무엇을 사용해야 하는지 여부를 지시해서는 안 됩니다. 그들이 말을 하고 싶다면 최소한 무슨 말을 하는지는 알아야 하고 IdentityServer와 같은 잘 알려진 패키지가 MS보다 품질이 낮다고 말하는 것은 저에게 명백한 잘못입니다. 그런 회사에서 뛰겠습니다!

그러나 여기에서 요점은 거의 모든 사람들이 이미 존재하는 무언가에 시간을 보내는 데 동의한다는 것입니다. 그것은 견고하고 많은 사람들이 그것을 사용하는 것이 약간 이상하다는 것입니다. 이 이면의 진짜 이유가 무엇인지 궁금합니다. 나는 그것이 단지 다음과 같은 것이라고 생각하지 않습니다. 오, 우리가 할 수 있기 때문에 우리 자신의 것을 만들자. 고객이 실제로 우리가 인식하지 못하는 것을 요구합니까?

개인적으로 OAuth-Server 공간의 다른 경쟁자를 문제로 보지는 않지만 좋은 점입니다.

이 영역의 개발을 촉진하는 데 도움이 되거나 그 이상, 즉 빠르고 더러운 솔루션이 필요한 사람들을 위한 빠르고 더러운 솔루션 역할을 할 수 있습니다.

OAuth 서버에서 더 많은 것을 원하거나 필요한 경우 우리 중 누구도 기존 솔루션을 사용하는 것을 막을 수 없습니다. 또는 기본 OAuth _그 이상은 하지 않는 원 클릭 템플릿을 원하면 적어도 나에게는 이것이 가치 있는 목표처럼 보입니다.

제 생각에는 이 스레드가 .NET Core 2.2의 로드맵에 있는 내용에 초점을 맞추는 것보다 OSS가 무엇인지, MS가 잘하는 것과 잘하지 못하는 것에 대한 맞대결로 바뀌었다고 생각합니다. 여기서 중요합니다.

@kellang
"NHibernate는 죽었다"고 누가 말했는가? 나는 프로젝트가 아직 살아 있고 심지어 Dapper보다 더 나은 추진력을 가지고 있음을 봅니다.
https://github.com/nhibernate/nhibernate-core/graphs/contributors
https://github.com/StackExchange/Dapper/graphs/contributors

아, 공식 aspcore 패키지 내에서 RESTful 프레임워크를 갖는 것에 대한 제 요점을 고수하기 위해 지금까지 IdentityServer에 대해 언급하지 않았습니다... 여기에 IdentityServer에 대한 제 생각이 있습니다. 정말 견고하고 훌륭하지만 2인 프로젝트입니다. 측정항목을 살펴보세요.
https://github.com/IdentityServer/IdentityServer4/graphs/contributors

작업의 약 85%는 2명이서 하고 보안 관련 프로젝트는 괜찮지만 기업에서는 많은 기업들이 미래에 이러한 프로젝트의 유지 관리 가능성에 대해 생각합니다. 최근 한 회사에서 "vue.js는 거의 Evan You"라고 말했기 때문에 프로젝트에서 Vus.J 대신 React를 사용하기를 원한다고 말했습니다... 그리고 저는 그들이 옳다고 생각합니다. 그리고 이것이 공식 패키지 내에서 RESTful 패키지를 갖는 것에 대한 입니다. 어떤 대기업도 프로젝트에서 "잠재적인" 유지 관리되지 않는 패키지를 사용하는 것을 허용하지 않을 것입니다.

거의 모든 프로젝트에 이러한 요구 사항이 포함되어 있고 @manigandham이 말했듯이 표준화되고 간단하기 때문에 데이터 조작 / 체질(페이징, 셰이핑, 정렬 등)도

@manigandham
바로 그것이 내가 옳다고 생각하는 것입니다... 재정적으로든 github을 통해 기여하든 최소한 문서나 과정에서 언급하든 공식적으로 솔루션을 조정하고 지원 합니다. 아카데미는 정말 훌륭하고 그러한 프로젝트에 더 많이 적응하는 것을 보는 것이 더 좋을 것입니다!).

@kieronlanning
당신 말이 맞아, 우리는 주요 주제에서 너무 멀리 갔다 ... 그러나 내가 전에 언급했듯이 asp 코어는 이제 막 매우 성숙해졌고 (성능 및 신뢰성), 이제 외부 에서 시작해야 할 때라고 생각합니다

두 명의 주요 기여자가 있기 때문에 프로젝트를 할인하는 것은 매우 어리석은 일이라고 생각합니다. IS4는 매우 잘 관리되어 있으며 그 두 사람은 질문에 답하고 사람들을 돕는 데 많은 시간을 할애합니다. 또한 시장에서 OAuth2 서버를 위한 최고의 FOSS 솔루션 중 하나로 널리 간주됩니다.

"NHibernate는 죽었다"고 누가 말했는가? 나는 프로젝트가 아직 살아 있고 심지어 Dapper보다 더 나은 추진력을 가지고 있음을 봅니다.

@0xRumple 나는 "죽은 것만큼 좋다"고 말했다 😉 당신은 OSS 프로젝트의 상태와 사용에 대해 매우 이상한 지표를 가지고 있는 것 같습니다. 2003년 프로젝트의 커밋 수와 2011년 이후 진행 중인 커밋 수를 비교하는 것이 공정합니까? 그들은 또한 _매우_ 다른 짐승입니다(앞서 스레드에서 언급했듯이). Dapper는 한동안 "완벽"(유지되지 않거나 버려진 등을 의미하지 않음)된 반면 NHibernate(및 해당 기능 세트)는 뒤쳐져 왔습니다.
나는 프로젝트가 여전히 진행되고 있다는 것을 알고 있지만 지난 7년 동안 .NET 분야에서 컨설팅을 하던 중 마지막으로 NHibernate를 야생에서 만났던 때가 언제였는지 기억이 나지 않습니다. Entity Framework로 마이그레이션됨). 지난 몇 년 동안 이 공간을 지켜본 모든 사람들은 NHibernate가 Entity Framework에 뒤쳐져 시장 점유율을 잃어가고 있다는 것을 아주 잘 알고 있습니다. NuGet 다운로드 수만 보세요. Entity Framework에는 45.8M이 있고 NHibernate에는 3.4M이 있습니다.

어쨌든 요점은 Entity Framework 대 NHibernate가 아닙니다. 그것은 단지 _하나의_ 예였습니다. 우리는 이 토론을 계속해서 했습니다. 가장 최근에 Microsoft가 ASP.NET Core에서 자체 경량 IoC 컨테이너 구현을 롤링하거나 Microsoft가 자체 개체 매퍼 롤링을 고려했을 때. 마이크로소프트가 OSS 커뮤니티의 한 공간에 들어올 때마다, 그것은 그 공간에서 많은(대부분?) 공기를 빨아들입니다. 종종 소규모 커뮤니티 주도 프로젝트가 시간이 지남에 따라 질식하기에 충분합니다. 나와 대부분의 커뮤니티는 이 사실을 너무 잘 알고 있습니다. Microsoft 자체(.NET) 세계에서 Microsoft와 경쟁하는 것은 불가능합니다. 나는 그들이 만족해야 하는 유료 고객이 있다는 것을 충분히 이해하므로 이 피드백이 그들의 마음을 바꿀 것이라고 기대하지 않습니다 :스마일:

멋진 기능 :)

상태 확인 기능에 대한 자세한 정보는 어디에서 얻을 수 있습니까?

자체 서명 인증서 관리 개선

연결된 웹 API를 호출하는 웹 앱을 개발할 때 로컬 네트워크를 통해 사내 사용자와 함께 테스트하는 것이 유용한 시점이 옵니다. 모든 단위, 기능 및 통합 테스트를 통과했을 수 있지만 실제로 문제를 해결하는 데 인간만큼 좋은 것은 없습니다.

문제를 분리한다는 정신으로 내 웹 앱은 여러 웹 API를 호출합니다. 첫 번째 인스턴스에서는 https://localhost 를 사용하여 이러한 웹 API를 개발합니다.. 웹 API가 준비되면(충분히) 로컬 컴퓨터의 IIS에 게시합니다. 각 사이트에는 내부 DNS 서버에 설정한 적절한 호스트 이름이 있습니다. 이 시점에서 Barry Dorrans' - @blowdart - gist https://gist.github.com/blowdart/1cb907b68ed56bcf8498c16faff4221c 를 사용하여 서버 인증서를 만듭니다. 인증서를 모든 올바른 저장소로 가져오면 모든 것이 알람 없이 내 컴퓨터에서 작동합니다.

이것은 네트워크의 다른 사람들이 웹 앱에 액세스할 때 변경됩니다(API 호출은 모두 내 개발 상자 내에 있음). 사용자가 심각한 경고를 받습니다. 나는 그들에게 이러한 경고를 무시하고 가능하고 충분히 간단한 경우 인증서를 가져오라고 말합니다. 이러한 자체 서명된 인증서에는 동일한 발급자 이름과 일반 이름이 있기 때문에 각각의 새 웹 앱은 경고 페이지를 트리거합니다.

나는 조직의 사용자에게 경고 페이지를 살펴보라고 요청하는 것이 나쁜 생각이라고 생각하지 않을 수 없습니다.

보안 전문가가 아닌 제가 보고 싶은 몇 가지 사항이 있습니다.

• 내가 생성한 모든 개발 인증서에 대한 로컬 루트 인증서를 보유하고 이를 PC, Mac, Android, iPad 및 iPhone 장치로 가져오는 승인된 방법을 알려 이러한 경고 페이지가 더 이상 발생하지 않도록 하는 기능

• 모든 올바른 인증서 저장소를 올바르게 채우는 Kestrel 및 IIS와 함께 사용할 수 있는 API용 인증서를 생성하는 더 쉬운 방법

@CrispinH 루트 CA를 지원하는 것은 루트 CA를 회전시키는 것과 관련이 있습니다. 그 시점에 있다면 루트 CA를 직접 가동하고 관리하는 것을 고려할 때입니다. 자체 서명된 지원은 글로벌 도구나 내 스크립트가 개발을 위한 것입니다. 사람들이 첨부하도록 허용하기 시작하면 해당 기능의 범위를 벗어납니다. 조직에 있고 사람들이 서비스에 액세스하기를 원한다면 조직은 Windows 또는 OpenSSL을 통해 내부 CA를 실행하고 AD 정책 또는 기타 수단을 통해 루트를 밀어내는 인증서 전략을 파악해야 합니다.

@blowdart 내가 불만을 품은 이유 중 하나는 루트 CA를 가동하는 데 며칠을 보냈고 이 영역에 대한 역량이 부족했지만 제대로 수행하지 못했기 때문입니다. 로컬 루트 CA를 수락하도록 요점을 수정하는 방법도 알아내려고 했습니다.
내가 찾은 모든 문서는 너무 일반적이었습니다. 내가 원하는 것은 오로지 서버 인증서로 API와 웹 앱을 보호하기 위한 인증서(이상적으로는 루트 CA 기반)를 만드는 프로세스였습니다. 아마도 특정한 경우의 문서가 필요한 전부일 것입니다.

@CrispinH Window Server는 인증 기관 과 함께 제공되며, 완전한 방법을 원할 경우 설정할 수 있습니다.

일반적으로 인증서는 쉬운 주제되지 않습니다 그리고 당신은 바로 그것을 할 꽤 배워야 할 것입니다.

개발 목적을 위해 자체 서명된 인증서는 완전히 훌륭하고 사용하기 쉽습니다. CA 설정 및 관리를 포함하여 그 밖의 모든 것은 더 이상 개발 목적이 아니며 확실히 범위를 벗어나고 웹 애플리케이션 프레임워크에 비해 너무 복잡합니다.

@CrispinH @poke가 말했듯이 제대로 하기가 어렵습니다. 루트 CA를 신뢰하는 시스템이 있으면 발급된 모든 인증서가 신뢰되고 개발자는 개발 상자에서 신뢰할 수 없는 코드를 실행합니다. 이것이 결국 nuget 패키지입니다. 따라서 루트 CA를 훔치는 것을 고려하십시오. 실생활에서 루트 CA는 오프라인 상태로 유지되는 경향이 있으며, 할 수 있는 일, 일반적으로 서버 및 클라이언트 인증서가 제한된 두 번째 인증서에 서명합니다. 타협은 신뢰할 수 있는 코드 서명 인증서를 발급하는 기능을 의미합니다. CA를 끔찍하게 모욕하는 의미가 없다면 개발자가 실행해야 할 일이 아니며 결과를 이해하는 사람들에게 맡기는 것이 가장 좋으며 그 결과는 끔찍할 수 있습니다. 그런 다음 고려해야 할 인증서 교체, 해지, OCSP 등이 있습니다. 내 인증서 인증 미들웨어에 대한 테스트 CA가 있어야 하며 꺼져 있는 VM에 있습니다. 나는 더 많은 시험 인증서를 얻을 때 그것을 켤 때 매우 긴장합니다.

진정으로 이 루트(말장난 의도)로 내려가고 싶다면 https://infiniteloop.io/powershell-self-signed-certificate-via-self-signed-root-ca/ 가 powershell을 시작할 수 있습니다. 그러나 CRL 또는 OCSP 또는 해지 지원을 제공하지 않습니다. https://gist.github.com/Soarez/9688998 은 OpenSSL을 다루는 것으로 보입니다. CRL이 필요한 경우 Windows에 CA가 내장되어 있습니다. 설정은 https://leastprivilege.com/2008/08/14/how-to-build-a-developmenttestdemo-ca/에 설명되어 있습니다.

_나는 위의 링크를 사용하지 않았으며(마지막 링크의 작성자를 신뢰하지만) 이것은 어떤 형식의 공식 MSFT 권장 사항도 아닙니다. ASP.NET 보안 팀의 공식 권장 사항은 인프라와 위험을 이해하는 사람이 회사 CA를 설정하도록 하는 것입니다. IT 부서에 문의하세요_

@blowdart 아니요, 저는 정말 _그 '루트'로 내려가고 싶지 않습니다. 그 이유를 이제 알 수 있어 좋습니다.

내 휴머노이드 테스트는 Let's Encrypt 인증서를 사용하는 테스트 호스트의 공용 인터넷에서 수행되어야 하지만, 엿보는 눈을 피하기 위해 인증 벽이 있어야 할 것 같습니다.

필요한 항목과 예산에 따라 DigiCert와 같은 일부 회사는 관리형 PKI 서비스를 제공합니다. 개인 루트 또는 공개 루트를 사용할 수 있습니다. 비용은 모르겠습니다.

HTTPS만 사용하는 경우 모든 azurewebsites.net 하위 도메인에 대한 인증서를 받습니다.

IdentityServer4의 커뮤니티 노력을 배우고 수용하고 참여하고 최소한의 노력으로 너겟 및 설정에서 포함할 수 있는 독창적인 IdentityServer "Lite" 버전을 만드는 데 기여하기 위한 또 다른 구현 대신 새로운 OpenID 구현에 무게를 둡니다.

당신은 모두 과민 반응하고 있습니다.
ASP.NET 팀은 이미 여러분과 같은 생각을 하고 있습니다. @DamianEdwards 는 가장 최근의 Community Standup에서

다음은 가장 관련성이 높은 부분입니다(하지만 모두 들어보기를 권장합니다).

"우리는 실제로 그것에 대해 지금 IdentityServer 사람들과 이야기하고 있습니다."
https://youtu.be/Tzh2EXwgEk8?t=25m15s

"MSFT 인증 서버" 프로젝트에 대한 토론이 얼마나 열정적인지 확인하는 것은 정말 흥미로운 일입니다.

덧붙여서, Vittorio Bertocci는 이 프로젝트의 기반으로 OpenIddict(내가 개발하고 유지 관리하는 OIDC 서버)를 사용하는 것을 고려하고 있었기 때문에 정확히 2년 전에 이 프로젝트에 대해 이야기하기 위해 저에게 연락했습니다.
작년에 나는 그들이 비즈니스 관점에서 (내가 이해할 수 있는) 때문에 타사 OSS를 활용하는 대신 자체 구현을 선호한다는 말을 들었습니다.

마음이 바뀌고 마침내 처음부터 다른 것을 만드는 대신 IdentityServer4와 같은 기존 OSS 솔루션을 사용하는 것을 고려하게 되어 기쁩니다. .NET 커뮤니티에 보낸 아주 좋은 신호입니다. 박수:

이것은 스레드에서 약간 벗어나지 만 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에는 인증서를 만들고 사용할 수 있는 다른 기능도 포함되어 있습니다. CA 실행에 대한 설명도 참조하십시오. 라이브러리 도구는 거의 존재하며 조직에 따라 많은 내부 구조를 설정하지 않고도 일부 서버에서 일부 제어된 방식으로 인증서를 사용할 수 있습니다. 해당 토큰에서 JSON-LD 라이브러리와 함께 즉시 사용 가능한(DER 인코딩된) 인증서 서명 요청(CSR)을 읽는 것이 좋습니다. 그리고 일반적으로 더 많은 암호화. :)

Windows의 App Services, Azure의 Linux 및 Docker와 함께 작동하는 LetsEncrypt 지원과 같은 일부 미들웨어를 보고 싶습니다.

@kieronlanning 앞서 언급한 CSR 서명과 관련된 DER 인코딩 외에 동의합니다(에지 케이스 없이 지원을 추가하는 것이 그렇게 어려워 보이지는 않지만). .NET용 라이브러리가 몇 개 있지만(Let's Encrypt 페이지에도 나와 있음) 약간의 문제도 있습니다. 예를 들어 Let's Encryptc와 관련하여 가장 적극적으로 유지 관리되는 .NET은 Certes 처럼 보이지만 BouncyCastle 에 종속 됩니다. 누군가가 .NET Standard 2.0 전용이 되도록 도와준다면 좋을 것입니다. 나에게 한 가지 이유는 BouncyCastle이 Orleans TaskScheduler 와 잘 작동하지 않기 때문입니다. :)

엄밀히 말하면 ASP.NET Core 문제는 아니지만 암호화 언급에 대해 MS는 블록체인을 많이 추진하고 있는 것 같지만 .NET은 암호화 기능이 부족합니다. _표면적으로_ 이 중 많은 부분이 ASP.NET 코어와도 관련이 있으며(예: https://etherscan.io/와 같은 다양한 블록체인 탐색기 구현) Inferno와 같은 라이브러리와 플랫폼에 구운 더 많은 기능. 한 가지 해결되지 않은 문제는 https://github.com/sdrapkin/SecurityDriven.Inferno/issues/10#issuecomment -395778931에 있습니다(누군가 도움이 필요한 경우 여기에 눈을 빌려주세요).

@kieronlanning의 이것이 저의 가장 큰 기능 요청이 될 것입니다.

"LetsEncrypt에 대한 지원과 같은 일부 미들웨어를 보고 싶습니다."

다음은 미해결 문제입니다: https://github.com/aspnet/Home/issues/1190. 가서 투표해 주세요.

SignalR뿐만 아니라 모든 프레임워크의 asp.net 코어에서 사용할 수 있는 messagepack으로 간주됩니까? Http2 프레이밍은 바이너리이므로 이에 대한 메시지 팩을 고려하고 있습니까?

미리보기3에서 인증 서버 출시?

이미 존재합니다. Https://IdentityServer.io

@최소 권한
IdentityServer를 좋아하고 사용합니다.
그러나 Microsoft 구현을 보고 왜 (microsoft)가 핵심에 identityserver를 통합하지 않았는지 이해하고 싶습니다.

@danroth27 - 최신 정보를 공유할 수 있습니까?

Microsoft는 IdentityServer를 사용하고 있습니다.

어떻게 작동합니까? Microsoft는 IDS4 코드를 직접 사용합니까? Microsoft는 IDS4 기능을 축소합니까? 여기 모델이 뭐에요? 우리는 무엇을 기대해야 합니까? 그들 사이에 가능한 마이그레이션 경로가 있습니까?

Microsoft는 표준 nuget 패키지를 사용하고 구성 API를 사용하여 템플릿 및 ASP.NET ID와 잘 어울리는 몇 가지 기본 설정을 제공합니다. 그게 다야.

오늘날 이미 똑같은 것을 성취할 수 있습니다.

아마 저일 것입니다만, 마이크로소프트 인증 서버의 공백이 IdentityServer4로 채워져 있다는 것을 읽고 깜짝 놀랐습니다. 내 이해에 따르면 IdentityServer의 주요 관심사는 인증이 아니라 인증입니다.

나에게 IdentityServer는 인증 서버로 괜찮지만 인증 서버로는 작동하지 않습니다. 그것이 PolicyServer를 만든 이유라고 생각했습니다.

@leastprivilege IdentityServer가 PolicyServer와 같은 것으로 확장됩니까?

@Ruard 그래서 혼란 스럽습니다 (Dominick은 아마도 설명을

OAuth는 인증이지만 첫 번째 단계로 권한 부여를 수행한 다음 범위 등에 따라 권한을 부여합니다. 따라서 랩핑에서 Identity Server는 로그인을 수행하고, 유효성을 검사하고, 필요한 범위를 확인합니다(초기의 경우 기본 범위를 사용하고 있기 때문에 항상 성공), 그런 다음 토큰을 호출자에게 다시 전달하고, 토큰은 유효성을 검사할 API로 전송되며, 선택적으로 API 내에서 권한 부여 규칙으로 더 나아갈 수 있습니다. OIDC는 앱이 가질 수 있도록 허용하는 권한을 포함하여 사용자의 신원 정보를 획득하는 방법으로 OIDC를 더욱 혼란스럽게 합니다...

따라서 기본적으로 Identity Server는 앱이 이를 가질 수 있도록 권한을 부여하는 ID를 제공하고 ASP.NET의 권한 부여 부분을 사용하여 액세스를 추가로 제어할 수 있습니다.

@MichelZ 성장 스토리가 있을 것입니다. 우리는 간단한 시나리오에 대해 구성할 것이며, 일단 이 시나리오를 벗어나면 IdentityServer 구성 모델의 모든 기능을 탐색할 수 있습니다.

@blowdart 우리는 이미 IdentityServer를 사용하고 있습니다(그리고 그 기능에 깊은 인상을 받았습니다!). 그러나 Microsoft의 "장기 지원" 정책의 이점을 얻는 것도 큰 장점입니다. 따라서 여기에서 제공할 수 있는 시너지 효과가 무엇이든 매우 환영합니다.
우리는 ASP.NET Core와 IdentityServer(4) 두 제품을 같은 방식으로 사랑합니다. 그것은 확실히 올바른 방향으로 나아가는 단계입니다. IMHO.
그러나 우리는 이러한 모든 프로토콜이 정확히 "직접적인" 것은 아니라는 것도 알고 있습니다. 그것들은 당신이 이해하는 로켓 과학이 아니지만 여전히 직선적이지 않습니다.

누군가가 정말 간단한 프로토콜을 발명하고 모든 레거시 구현을 뒤로하고 미래에 집중하기를 바랍니다.

이미 사용 중이라면 용도가 변경되지 않고 작동하는 것입니다. :)

File New > Web API with Individual Authentication을 목표로 하고 다른 API를 추가하는데 모든 것이 컨벤션 기반입니다. 규칙이 새롭기 때문에 기존 앱에서는 작동하지 않습니다. 귀하의 구성을 우리의 구성으로 교체할 계획은 없습니다. :)

누군가가 정말 간단한 프로토콜을 발명하고 모든 레거시 구현을 뒤로하고 미래에 집중하기를 바랍니다.

이것이 문제입니다. 앱이 점점 더 복잡해지고 있습니다. 그들을 보호하기 위해 보안도 복잡합니다. 저는 사람들이 IdentityServer가 복잡하다는 말을 들을 때마다 항상 뒤로 물러났습니다. 그렇지 않습니다. 복잡한 것은 애플리케이션의 보안 요구 사항입니다. 종종 사람들은 그것을 인식할 수 있는 관점을 가지고 있지 않습니다.

예, 작동하고 있으며 잘 작동하고 있습니다. 그러나 Microsoft가 공식적으로 기술을 "보증"하고 궁극적으로 "지원"할 때 (아마도) 추가 보증은 순금입니다.... !
당신은 완전히 새로운 차원으로 올라갔습니다!

@brockallen 예, 응용 프로그램은 아마도 많은 것을 복잡하게 만듭니다. 그러나 OIDC 프로토콜은 OAuth 2.0에서 일부 내용을 상속받았으며, 이 프로토콜이 더 좋았을 것입니다. 일부 팀원(@leastprivilege라고 생각합니다)은 OIDC가 처음부터 개발된다면 지금과 상당히 다르게 보일 것이라고 말했습니다.

나는 우리가 지금 가지고 있는 것이 "나쁘다"고 말하는 것이 아닙니다. 우리가 가진 것에 정말 감사하며 우리의 목적에 정말 적합합니다. 그리고 그것을 만드는 데 관련된 모든 사람들이 그들이 한 일을 자랑스러워하기를 바랍니다!

@팀;
미리보기 3의 경우 "인증 서버"에 대한 몇 가지 세부 문서와 Vue와 같은 웹 API 및 클라이언트 측 JS와 함께 사용하여 작동하는 방식을 제공해 주시겠습니까?
결정을 내려야 하며 Authorization Server의 이 미리 보기는 중요한 미리 보기이며 모든 세부 문서에서 결정에 대한 정보를 제공합니다.

감사 해요!

앞서 논의한 바와 같이

https://identityserver.io

방금 US 오픈 데이터 API가 JSON-LD에 있음을 알았습니다. https://project-open-data.cio.gov/v1.1/schema/ . 이것은 빠르게 성장하는 추세이므로 ASP.NET과 함께 사용되는 리소스가 풍부한 JSON-LD .NET 라이브러리가 좋을 것입니다. :)

@veikkoeeva NuGet API도 (적어도 일부) json-ld.net을 사용하고 있습니다.

@khellang 그리고 다른 라이브러리도 있습니다. 이 특정 라이브러리는 관리자를 사용할 수 있습니다(https://github.com/linked-data-dotnet/json-ld.net/issues/26). 나는 그것이 오픈 소스라는 것을 알고 있고 이론적으로 내가 기여할 수 있다는 것을 알고 있지만 적어도 당분간은 이것을 돕기에는 너무 얇아집니다. 달리 말하면, 많은 데이터 세트가 의미 체계 형식으로 이동하는 것처럼 보이고 .NET을 사용하여 효율적으로 작업하는 방법이 명확하지 않다는 점을 강조하고 싶습니다.

IMHO, ASP.Net Core의 코어에 IdentityServer4를 추가하는 것은 나쁜 생각입니다.
.NetCore를 모놀리식 프레임워크로 만들지 마십시오.
.NetCore가 있고 IdentityServer4가 있습니다. 사람들은 자신의 인증 및 권한 부여 요구 사항에 따라 아키텍처 기반을 만듭니다.

@mikeandersun 계획은 기본 구성을 쉽게 사용할 수 있도록 프로젝트에 추가할 수 있도록 하는 것입니다.

여전히 사용할 수 없으며 영향을 미치지 않습니다. 여전히 IdSrv를 사용하고 직접 구성할 수 있습니다. 여전히 프로젝트에 포함할 구성 요소를 선택할 수 있습니다. 이 중 어느 것도 ASP.NET Core를 모놀리식으로 만들지 않습니다.

ASP.NET Core != .NET Core btw.

2.2는 LTS 릴리스입니까? (이미 발표됐는지 묻는 것이지 새로 발표하라고 하는 것이 아니다.)

@yzorg 아니요 발표되지 않았습니다. 그 결정은 종종 품질/안정성을 기반으로 출시 후에 이루어집니다.

@blowdart , 이 템플릿은 API 대신 웹 앱 MVC 클라이언트가 있는 ID 서버를 제공합니까?

@Ponant 아니요. API 전용입니다. 3.x 타임라인에서 이를 재평가할 것입니다.

흥미롭습니다... 이 질문은 어제 회의에서 나왔습니다. Web API를 사용하지 않고 완전한 "MVC" 프로젝트를 빌드한다면 2.2에 통합된 새로운 ASP.Net 2.2 IS4 템플릿을 사용할 수 있습니까?
사장(배리)이 방금 질문에 답한 것 같습니다.

@blowdart allias 큰 보스: 한 번에 완료되지 않는 이유는 무엇입니까? asp.net 코어 ID IS4 서버와 통신하는 mvc 클라이언트 또는 웹 API를 사용하는 것은 언뜻 보기에 사소해 보입니다.

@Ponant 무한한 자원이 없기 때문입니다. 새로운 기능을 제공하지 않고 기존 기능이 작동하는 방식만 변경하는 MVC 흐름의 주요 부분을 모두 변경하기 위해 어떤 기능을 삭제하기를 원하십니까? 개별 인증 API는 전체 프레임워크와 ASP.NET Core 사이의 간격이었습니다. 그 간극을 채우는 데 초점이 맞춰져 있었다. Identity Server에는 이미 Identity Server를 "핵심"으로 사용하는 MVC용 작업 템플릿이 있습니다.

@CrispinH @blowdart 전적으로 동의합니다. 사용자 관리, 역할, 테넌시 및 사용자 그룹이 절실히 필요합니다. 이 수백 명의 개발자와 회사에 대해

--> 사용자/그룹/테넌트 관리에 대한 요청이 너무 많습니다.

--> 여기 사람들이 다시 불평합니다 ... 트위터와 페이스북에서도 계속됩니다. 이것이 바로 WP 및 PHP와 같은 다른 플랫폼이 더 쉬운 이유입니다!

@manigandham 은 ID 서버가 매우 적합하다고 생각하지만 GUI 관리 도구에 대해 많은 비용을 청구하고 많은 국가와 개발자에게 저렴하지 않으며 낮은 TCO 개발자에게도 불리합니다. 과연 이것을 감당할 수 있는 사람이 얼마나 될까요. 큰 장애물이었고 뒤로 물러서서 Users/roles/Roles-User_groups/Tenants를 관리하기 위한 기본 기본 기능과 GUI가 필요 하며 개발자가 이를 개선할 수 있습니다.

@papyr 이것을 위해 오픈 소스 프로젝트를 시작하지 않으시겠습니까? 모든 것을 위한 완전한 GUI는 프레임워크(템플릿)에 구축될 필요가 없습니다. 그리고 팀이 예를 들어 Bootstrap을 변경하여 템플릿 업데이트를 유지하는 것이 이미 얼마나 어려운지 알면, 나는 그들이 그것에 더 많은 노력을 낭비하는 것을 정말로 원하지 않습니다. 그러나 다른 한편으로, 나는 이것이 존재하는 데 유용한 것이 될 것이라는 것을 완전히 이해합니다. 그래서 이것을 커뮤니티에서 노력하지 않는 이유는 무엇입니까?

@papyr @poke 새로운 오픈 소스 프로젝트가 필요하지 않으며 우수한 기존 프로젝트가 있습니다.

WordPress와 경쟁하도록 설계된 MS의 오픈 소스를 원하면 Orchard를 살펴보십시오.
https://github.com/OrchardCMS/OrchardCore

프레임워크 대신 라이브러리 접근 방식을 더 원하면 다중 테넌시, 사용자 및 역할 및 클레임 관리 UI를 위한 nugets가 있는 cloudscribe를 확인하세요. 여기에는 선택적 identityserver4 통합과 선택적 cms(cloudscribe.Simple/content)가 미리 구축되어 있습니다. 추가 너겟.
https://www.cloudscribe.com/docs/introduction
https://github.com/cloudscribe/cloudscribe
https://github.com/cloudscribe/cloudscribe.SimpleContent

WordPress와 경쟁하도록 설계된 MS의 오픈 소스를 원하면 Orchard를 살펴보십시오.
https://github.com/OrchardCMS/OrchardCore

나는 이 추천을 두 번째로 한다.

그리고 Orchard Core는 극도로 모듈화되도록 설계되었습니다. 예를 들어 다중 테넌시 모듈만 추출하여 자신의 프로젝트에서 사용할 수 있습니다 . 또한 이미 사용자 및 역할을 관리하는 모듈이 있으며 더 나은 기능을 만들기 위한 귀하의 기여에 감사할 것이라고 확신합니다.

채널 에서 다양한 기능의 데모를 많이 볼 수 있습니다.

@papyr 이것을 위해 오픈 소스 프로젝트를 시작하지 않으시겠습니까?

https://github.com/IdentityManager/IdentityManager2

이 UI는 까다로울 수 있지만 기본 사항을 빠르게 얻는 데 도움이 됩니다. 최근에 UI를 구축하는 것이 가장 큰 작업은 아니지만 일부 이메일(애플리케이션 특정 작업을 수행하는)을 사전 승인하고 API를 호출하는 API를 호출하는 것과 같은 "프로세스 요구"를 충족하는 방법을 찾는 경우를 본 것 같습니다. , 그 중 일부는 데이터베이스의 조인 또는 다른 곳의 호출 등을 의미할 수 있으며 토큰 및 UI 로직에 추가합니다.

그래서 같은 좋은 자습서를 가지고 https://mcguirev10.com/2018/01/28/login-identity-management-best-practices.html 또는 그 https://mcguirev10.com/page2/이 (UI보다 더 중요한 느낌을 특히 EF를 사용할 수 없거나 사용하고 싶지 않은 경우). 그런 다음 선택한 기술(Aurelia/Angular/Razor/React/Vue 등)에 대한 UI와 일부 데이터 처리를 구현하는 방법을 검색할 수 있습니다.

@scottbrady91 외에도 프로젝트와 이름을 명명할 때 @LindaLawton , https://github.com/abergs/fido2-net-lib ( @abergs , @aseigler), @TomCJones , @mackie1001 을 확인하는 것이 매우 교육적이라는 것을

.net 코어에 정상적인 면도기 웹 페이지가 없는 이유는 무엇입니까? 복잡한 보고서를 작성할 때 단일 면도기(C#) 페이지에서 모든 작업을 수행하는 것을 좋아합니다. 또는 최소한 모델이나 컨트롤러 없이 때때로 보기만 사용할 수 있는 기능.

즉, 보기에서 sql에 연결하고 GET 및 POST 요청을 수신하는 기본 기능은 물론 삭제되며 현재 Striptag.cs라는 클래스를 사용합니다.

.net 코어에 정상적인 면도기 웹 페이지가 없는 이유는 무엇입니까?

이 https://docs.microsoft.com/en-us/aspnet/core/razor-pages/?view=aspnetcore-2.1&tabs=visual-studio에 Razor 페이지를 사용할 수 있습니다.

백킹 페이지 모델 클래스를 갖는 것은 선택 사항입니다. 당신은 단지 한 페이지를 가질 수 있습니다

benaadams 답변 주셔서 감사합니다. 면도기 페이지에서 직접 GET 및 POST 요청을 사용하고 SQL 서버에 기본 연결을 만드는 방법은 무엇입니까? ado 엔터티, linq 또는 ORM이 아닌 일반 쿼리에 대한 연결입니다. 나는 항상 일반 쿼리를 선호합니다.

좋다:

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

연결 문자열이 지금 json 파일에 있다는 것을 알고 있지만 보기에서 사용하는 방법을 모릅니다. 어떤 것들은 깊이 문서화되지 않았습니다.

글쎄, 그것은 학습 곡선이 있습니다. 뷰를 로드하기 _전에_ 데이터를 가져오려면 해당 작업에서 수행합니다. 따라서 HomeController.ViewReports 작업 및 Views/Home/ViewReports.cshtml 페이지에 대해 다음을 작성합니다.

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

페이지 로드 이후에 데이터를 가져오려면 일반적으로 JSON 형식 데이터를 반환하는 일부 순수 GET/POST 끝점에 대한 AJAX 요청을 사용합니다.

컨트롤러나 작업 없이 페이지에서 여전히 수행할 수 있습니다. 뭔가

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

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

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

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

나는 mvc asp.net과 webforms와 오래된 면도기 페이지를 사용해 왔기 때문에 이에 익숙하지 않습니다. 3시간을 보냈지만 여전히 간단한 테스트 면도기 페이지를 사용할 수 없습니다.

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

</body>
</html>

html 페이지만 로드하면 됩니다.

모델

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

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

        public void OnGet()
        {

        }

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

보다:

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

<!DOCTYPE html>

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

3시간이면 빈 페이지만 나옵니다. 나는 return 문 등을 시도했다.

http://localhost :51307/pets/razdb3만 입력하면 두 번째 부분인 "hello"가 표시되지만
@Model.myvar 나는 아무것도 얻지 못한다.

저는 .net 코어를 처음 접했고 면도기 페이지를 간단하게 표시하는 것이 그렇게 어려울 것이라고 상상하지 못했을 것입니다.

VS 커뮤니티 2017에서

@Model.myvar 나는 아무것도 얻지 못한다.

myvar 값을 psearch 양식에서 사용하여 게시물 요청( OnPost )에 설정합니다. 그래서 그것을 설정하려면 해당 값으로 POST 요청을 해야 합니까?

브라우저에서 URL로 이동하여 얻는 GET 요청( OnGet )에서; 대신 양식 포스트백이 설정되지 않습니다.

모델이 흐르는지 확인하기 위해 설정하지 않을 때 표시되도록 기본값으로 설정해 보십시오.

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

로 변경

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

그리고 여전히 빈 페이지. @Model.myvar가 맞습니까?

심지어 변경

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

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

        public void OnGet()
        {

        }

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

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

<!DOCTYPE html>

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

그것은 오류 없이 잘 빌드되지만 내가 무엇을 시도하든 빈 페이지를 만듭니다.

정중한 논평/생각: "일반 면도기 페이지"에 대한 이 토론이 이 스레드의 주제와 관련하여 주제에서 약간 벗어나기 시작한 것 같습니다.

😊 😊

죄송합니다. 포럼을 사용했어야 했습니다. @benaadams 에게 감사합니다

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

이것은 "새로운"키워드를 사용하여 어쨌든 일반적으로 작업을 수행하는 방법입니다.

EmployeeDataAccessLayer objemployee = new EmployeeDataAccessLayer();

.net 코어에서 사용자 정의 클래스를 계속 사용할 수 있다는 사실은 안심이 되었습니다.

.net 코어는 이전의 일부 asp.net 프레임워크보다 학습 곡선이 더 가파르다는 것을 인정해야 합니다. 정말 고마워.

릴리스 정보에서는 향후 몇 개월 동안 추가 기능으로 제공될 "인증 서버" 기능에 대해 설명합니다. 이 기능에 대한 추가 정보가 있습니까? 기다릴지 말지 결정하려고 합니다. 또는 자체 솔루션을 구축하십시오.

릴리스 정보에서는 향후 몇 개월 동안 추가 기능으로 제공될 "인증 서버" 기능에 대해 설명합니다. 이 기능에 대한 추가 정보가 있습니까? 기다릴지 말지 결정하려고 합니다. 또는 자체 솔루션을 구축하십시오.

현재 계획은 https://github.com/IdentityServer/IdentityServer4 를 "미리 패키징된" 방식으로 사용하는 것입니다.

IS4 팀과 MS 보안 팀의 메모에 따르면 MS는 단순히 IS4의 빠르고 더러운 패키징을 시도하고 있는 것처럼 보였습니다. 그러나 보안이 제대로 이루어지지 않을 때 파급 효과를 일으킬 수 있기 때문에 더 많은 지혜를 가진 사람처럼 보였지만 올바른 방법으로 행동하기로 결정했습니다.

IS4와 ASP가 완전히 통합되어 Web API와 MVC를 모두 지원하기를 바랍니다.

산업적으로 강력한 인증/인가가 최소한으로 요구되는 시대입니다. 오픈 소스(OSS)는 대부분의 경우 문제가 없지만 일부 OSS 보안 제품에는 기업 웹사이트에서 허용되지 않는 심각한 우려가 있었습니다. 프로젝트의 85%는 수용할 수 없는 보안 위험이 있는 오래된 라이브러리를 사용합니다. 예를 들어, 45%의 웹 서버는 IIS(https://www.cvedetails.com/product/3436/)보다 훨씬 더 많은 취약점이 있는 Apache(https://www.cvedetails.com/vendor/45/Apache.html)를 사용합니다. Microsoft-IIS.html?vendor_id=26). Identity Server와 같은 제품은 괜찮을 수 있지만 개발자가 조정하면 완전히 안전하지 않을 수 있습니다. 우리는 항상 안전한 Net Core에 내장된 솔루션이 필요합니다...

산업적으로 강력한 인증/인가가 최소한으로 요구되는 시대입니다. 오픈 소스(OSS)는 대부분의 경우 문제가 없지만 일부 OSS 보안 제품에는 기업 웹사이트에서 허용되지 않는 심각한 우려가 있었습니다. 프로젝트의 85%는 수용할 수 없는 보안 위험이 있는 오래된 라이브러리를 사용합니다. 예를 들어, 45%의 웹 서버는 IIS(https://www.cvedetails.com/product/3436/)보다 훨씬 더 많은 취약점이 있는 Apache(https://www.cvedetails.com/vendor/45/Apache.html)를 사용합니다. Microsoft-IIS.html?vendor_id=26). Identity Server와 같은 제품은 괜찮을 수 있지만 개발자가 조정하면 완전히 안전하지 않을 수 있습니다. 우리는 항상 안전한 Net Core에 내장된 솔루션이 필요합니다...

당신의 요점은 절대적으로 정확합니다. 그러나 일부 비디오에서 MS 직원은 [보안] 바퀴를 재발명하고 타사 [IS4] 시스템을 사용하지 않을 것이라고 말했습니다. 그래서 저는 이것이 우리 모두에게 윈/윈 상황이 되기를 바랍니다.

산업적으로 강력한 인증/인가가 최소한으로 요구되는 시대입니다. 오픈 소스(OSS)는 대부분의 경우 문제가 없지만 일부 OSS 보안 제품에는 기업 웹사이트에서 허용되지 않는 심각한 우려가 있었습니다. 프로젝트의 85%는 수용할 수 없는 보안 위험이 있는 오래된 라이브러리를 사용합니다. 예를 들어, 45%의 웹 서버는 IIS(https://www.cvedetails.com/product/3436/)보다 훨씬 더 많은 취약점이 있는 Apache(https://www.cvedetails.com/vendor/45/Apache.html)를 사용합니다. Microsoft-IIS.html?vendor_id=26). Identity Server와 같은 제품은 괜찮을 수 있지만 개발자가 조정하면 완전히 안전하지 않을 수 있습니다. 우리는 항상 안전한 Net Core에 내장된 솔루션이 필요합니다...

"항상 안전한" 것은 없으며 특히 Microsoft의 것이 아닙니다. ;)
그것을 만들고 안전하게 유지하는 것은 항상 이러한 것들을 사용자의 손에 달려 있습니다.

IdentityServer는 2.2 이후 출시되는 새 템플릿에 포함될 것입니다. 초기 초점은 API 액세스 제어이지만 향후 확장할 계획이 있습니다.

ASP.NET Core는 템플릿 시나리오만 다루는 간소화된 구성 API와 함께 제공되지만 시작하기는 매우 쉽습니다. 고급 시나리오를 제공하는 IS 기본 구성 시스템으로 언제든지 전환할 수 있습니다.

IdentityServer는 2.2 이후 출시되는 새 템플릿에 포함될 것입니다. 초기 초점은 API 액세스 제어이지만 향후 확장할 계획이 있습니다.

ASP.NET Core는 템플릿 시나리오만 다루는 간소화된 구성 API와 함께 제공되지만 시작하기는 매우 쉽습니다. 고급 시나리오를 제공하는 IS 기본 구성 시스템으로 언제든지 전환할 수 있습니다.

정보 감사합니다 Dominick;
나는 이 "디딤돌"이 많은 사람들이 시작하고 완전한 IS로 전환하는 데 도움이 될 것이라고 생각합니다. 호수.

IdentityServer는 2.2 이후 출시되는 새 템플릿에 포함될 것입니다. 초기 초점은 API 액세스 제어이지만 향후 확장할 계획이 있습니다.

ASP.NET Core는 템플릿 시나리오만 다루는 간소화된 구성 API와 함께 제공되지만 시작하기는 매우 쉽습니다. 고급 시나리오를 제공하는 IS 기본 구성 시스템으로 언제든지 전환할 수 있습니다.

알아 둘만 한! 감사합니다.

이 API 액세스 제어는 OAuth 범위를 기반으로 합니까?
policyserver.io에 설명된 것처럼 더 휘발성인 사용자 권한에 대한 직접적인 지원이 없습니까?

IdentityServer는 2.2 이후 출시되는 새 템플릿에 포함될 것입니다. 초기 초점은 API 액세스 제어이지만 향후 확장할 계획이 있습니다.
ASP.NET Core는 템플릿 시나리오만 다루는 간소화된 구성 API와 함께 제공되지만 시작하기는 매우 쉽습니다. 고급 시나리오를 제공하는 IS 기본 구성 시스템으로 언제든지 전환할 수 있습니다.

알아 둘만 한! 감사합니다.

이 API 액세스 제어는 OAuth 범위를 기반으로 합니까?
policyserver.io에 설명된 것처럼 더 휘발성인 사용자 권한에 대한 직접적인 지원이 없습니까?

PolicyServer는 상용 솔루션입니다.

이 API 액세스 제어는 OAuth 범위를 기반으로 합니까?
policyserver.io에 설명된 것처럼 더 휘발성인 사용자 권한에 대한 직접적인 지원이 없습니까?

"전용" IdentityServer. ASP.NET Core에는 사용자 인증을 위한 기본 제공 API가 있으며 PolicyServer(제품)가 흥미롭게 보이면 알려주세요.

ASP.NET Core 2.2가 출시되었으므로 이 문제를 종료합니다.

이것은 ASP 3.0으로 업데이트되지 않아야 합니다.

Authorization Server 개선 사항이 언제 제공되는지에 대한 업데이트가 있습니까?