EF Core 2.2ロードマップはどうですか？

EF Core 2.2ロードマップはどうですか？

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

ロードマップ、特にヘルスチェックとHTTP2.0は良さそうです。 ただし、可能な限り親切に、単純なファーストパーティのマイクロソフト認証サーバーを構築する必要性には同意しません。 IdentityServer4はこのギャップをうまく埋めており、より単純なバージョンの再実装に費やされた時間は、他の場所でより適切に費やされる可能性があります。 目標は単純なソリューションを提供することであることを理解していますが、認証は難しく、IdentityServerはほぼ同じくらい単純なAPIを提供します。 より単純な抽象化のアイデアがある場合は、IdentityServerの上に構築して、人々が単純な抽象化を使用できるようにすることができますが、必要に応じて強力になります。

アップデート

ASP.NET Communityのスタンドアップでは、ASP.NETCoreチームがIdentityServerの上に何かを構築することを含め、オプションについてIdentityServerチームと話し合っていると述べられました。 それが私たち全員が望んでいることだと思います。

ASP.NET Core WebHooksに関する現在の計画は何ですか？

ディスパッチャに関して、これはミドルウェアで可能ですか？ 😱
C# public async Task Invoke(HttpContext context, [FromRoute] SomeModel someModel)
^{[FromQuery]？}

Simple Auth Serverだけでなく、Katana simple AuthServerで何が起こったかを覚えておいてください

@RehanSaeedの懸念を反映したいと思います。また、この新しいサーバーが満たすはずの正確なユースケースについていくつか説明を求めたいと思います。 これが主に、Web APIに、アプリの既存の認証内で有効なベアラートークンを取得する方法がある場合は、それで問題ありません。 しかし、その上にあるものはすべて、IdentityServer、OpenIddict、AspNet.Security.OpenIdConnect.Serverなどの製品でさまざまな複雑さと柔軟性の多くのオプションをすでに提供している既存のソリューションに任せたほうがよいでしょう。

IISインプロセスホスティングはどうですか？

「APIクライアント生成（C＃＆TypeScript）」のTypeScriptの部分について詳しく教えてください。

これは本当に私が楽しみにしていることです。 現在、Angular ClientAPIサービスの自動生成にNSwagを使用しています。 しかし、クライアント構成には非常に多くの異なる組み合わせが可能であるため、これはすべての人を満足させるのに問題になる可能性があると思います。

頭のてっぺんから、考慮すべきことがいくつかあります（可能であれば構成可能である必要があります）。

• フェッチを備えたTypeScriptクライアントまたはHttpClientを備えたAngularサービスだけですか？
• Angularの場合、どのバージョンをサポートしますか（RxJSにとっても重要です）？
• null /未定義の処理
• 列挙型の処理
• 日付タイプのJS日付またはmomentjs？
• 例外処理、検証エラー処理
• クライアントで生成されたコードを拡張するにはどうすればよいですか？
• 名前の生成に影響を与える可能性（たとえば、生成されたクライアントクラスのxxxDTOからDTO部分を削除するか、すでにOpenAPI定義にある）

機能に投票することができれば、既存のミドルウェアに対するこれらの改善/修正は私のウィッシュリストに含まれます。

• Encryptはhttps://github.com/aspnet/Home/issues/1190をサポートし
• Response Cacheミドルウェアは、現在のように基本的に使用できません。 Redis応答キャッシュストアとキャッシュされた応答のユーザー操作の拡張性を追加すると、 https：//github.com/aspnet/Home/issues/2606が解決するはず
• pre-GZIPおよびpre-BRでエンコードされたファイルの提供をサポートします。
• Brotli圧縮プロバイダーをに関するいくつかの問題を修正

また、AuthorizationServer製品をスキップすることに投票します。 セキュリティは複雑であり、メンテナンスを削除するためにクラウドサービスに移行することが大きく求められています。より詳細な制御が必要な場合は、十分に構築、テスト、文書化、サポートされているIdentityServer4をすでに使用できます。 簡単なセットアップには5分かかり、スターターサンプル、ビデオ、チュートリアルがたくさんあります。

セキュリティを「ゼロ設定」として機能させる方法がわかりません。 これにより、（名前付けと使用法で）混乱が増えるだけでなく、他の機能から継続的に努力を払うことで、何年にもわたってサポートおよび維持するもう1つのものになるようです。 これを考え直してください。

また、IISインプロセスホスティングがこの2.2ロードマップに含まれていない理由にも興味があります。 これが大きな特徴であり、ここでスタックオーバーフローで私達のリリース戦略とスケジュールの主要な因子であり、それはすでに代わりに2.2時間枠を約束し、2.1リリースの前に非常に最後の分を取り除きました。 これは単なる見落としであり、別の計画変更ではないことを教えてください。

編集： @DamianEdwardsはTwitterで、これは確かに見落としだった

他のコメントをエコーし​​ます。 承認/ポリシーに投資する場合、特に簡単にする場合は、個人的には、ドキュメントやスキャフォールディングへの投資に関して、OpenIddictやIdentityServerなどとのパートナーシップを望んでいます。 どんなに単純な作業でも、サードパーティの素晴らしい作業が重複し、aspnetチームに不要なメンテナンスコストがかかることになると感じざるを得ません。

あまり人気のない見方かもしれませんが、私たちの意見とサポートを備えた、世間の注目を集めているMicrosoft AuthServerを見てみたいと思います。

現在のもの（Id4、OpenIddict）は明らかに優れたOSSプロジェクトであり、その背後にあるMSのサポートがあるものが悪いことになる可能性があると感じずにはいられません...？

少人数のグループから利用できるサポートの量には制限があり、これらは結局のところミッションクリティカルな製品です。

MS OSSの行動規範に、「Nugetリクエストで持ち込むことができるものを複製し、2人のビジネスをさりげなく押しつぶすような機能を宣伝しないでください」という行が含まれていないのは残念だと思います。私たちのエコシステムに貢献しています。」

私の中の皮肉屋は、一部のインサイダーにとって、ブロックとドミニクに血まみれの鼻を与えることがバグではなくこの提案の特徴であったかどうか疑問に思わずにはいられません。 これは、ASPチームが行っていることを批判する気性を持っている中小企業に何が起こるのでしょうか。

また、UIやドキュメントなど、上に何かを構築する以外の認証機能を複製することについても疑問に思います。

さらに、十分にテストされたJSON-LD 1.1ライブラリは、ロードマップへの優れた具体的な追加となるでしょう。 :)

他の人が言ったことを繰り返します-私は、自分で新たに実装するよりも、IdentityServer4のようなものから承認作業がもたらされることを望んでいます。 ギャップがある場合は、コントリビューション、サンプル、および統合ポイントの改良を通じてそれらを確実に橋渡しするのがより良い方法です。 恐ろしい状態にあるこのスペース（B2C）で提供されているクラウドにも注意を払う必要があります。

それを超えて、目的は既存のオープンソース製品の機能を複製することではなく、物事をシンプルに保つことであると述べていますが、これは古典的な書き換えの罠と幾分同等です。 "。 それは素朴で、nバージョンの時間では、現実世界のソリューションが必要とし、IdentityServerのようなものがすでに扱っている多くのエッジケースに対処したことにお金をかけます。

より広義には、GitHubの買収に伴い、最近、オープンソースに対するMicrosoftの姿勢について多くの議論がありました。 マイクロソフトがオープンソースで多くの作業を行っていることは素晴らしいことですが、優れたオープンソース市民であることの一部は、既存のオープンソースが存在する場合にそれを活用することです。

これは、あなた自身のようなプラットフォーム所有者にとって特に重要です。プラットフォーム所有者は、既存のオープンソースオファリングの機能を複製し、それらのオファリングに関与しながら、貢献を_奨励_します。

私も承認に費やされている努力のポイントを見ることができませんが、ASP.NET CoreIdentityの_管理_が改善されることを望んでいます。 ダミアン・エドワーズは、live.asp.netで、独自のセキュリティをロールするべきではないことを明確に示していましたが、見逃していない限り、ASP.NET Core Identityにはユーザー管理ツールが含まれていないため、ロールする必要があります。私たち自身の。 私はセキュリティの専門家ではなく、自分で作ったセキュリティホールを残すことを致命的に恐れているので、これは少し恐ろしいことです。

2.2でコンテンツフォーマッターをMVCレベルからAspNetCore.Http抽象化に移動するのはどうですか？

おそらく、担当のPMは、このIdentity Server Liteのより詳細な説明を作成して、ASP.NETチームが対処しようとしている既存のサードパーティのオープンソースソリューションの欠点を正確に明らかにすることができます。 現状では、ホイールの再発明について話しているのですが、スポークの一部を削除している可能性があり、それはあまり意味がありません。 他の誰かが言ったように、AAD B2Cを修正し、それとのファーストクラスの統合を提供することは素晴らしいことであり、MSにとってビジネス上理にかなっています。

また、@ blowdartを超えて、新しい、ゼロからのAuthサーバー製品を入手するのがどれほど難しいかを考えたことはありますか？

djangoのような組み込みのRESTfulAPIサポートを計画していますか？
これは、すべての開発者が毎回書く傾向があるものです。

私は最近、汎用RESTfulAPIコントローラーとして記述できるものを作成しました。

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の改善により、一般的にこれを冗長性を減らすことができます。 しかし、いいえ、デフォルトでエンティティのCRUDAPIを提供するだけのものはおそらく表示されません。 そのようなことはあなたのDALと認可についてあまりにも多くの仮定をしなければならないでしょう。

アプリケーションで特定のパターンに従う場合は、2.2で独自の基本タイプまたは規則を作成して、作業を一般化することに何の問題もありません。

@kieronlanning

現在のもの（Id4、OpenIddict）は明らかに優れたOSSプロジェクトであり、その背後にあるMSのサポートがあるものが悪いことになる可能性があると感じずにはいられません...？ 少人数のグループから利用できるサポートの量には制限があり、これらは結局のところミッションクリティカルな製品です。

あなたはそれが悪いことかもしれないかどうかについて尋ねたので：

ASP.NETチームも比較的小規模で、容量が限られている何百万もの開発者にサービスを提供しているため、新しいプロジェクトは他のものから時間と労力を奪います。 それは、おそらくより多くの価値を提供するであろう真新しい機能を手に入れるために、私たち全員がより長く待たなければならないことを意味します。

さらに悪いことに、Microsoftが「公式」パッケージをリリースしたために、サードパーティのエコシステムを傷つけ、新製品を思いとどまらせています。有能。 ASP.NETはすでにJson.NET、Polly、AutoMapper、および他の多くのライブラリを統合しているため、優れたオプションがすでに存在する場合、このような複雑なセキュリティ製品（同じベースコードの80％が必要）を再構築するのは失敗のようです。ロードマップ上で取り組むべきもっと多くの興味深いことがあります。

@ポーク
そうです、私のアプリの基本クラスを書くのは良い考えです。

実際、私はそれらがフレームワークの責任の範囲内にないと信じています：

CRUD resources (repository responsibility)

Manipulating data (sieve responsibility)
    Paging
    Filtering
    Searching
    Sorting
    Shaping

しかし、（AspNetCore.RestFrameworkパッケージを使用することで）AspNetCoreの方がうまくいくと思った

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.NETCoreと.NETCoreはオープンソースであり、それらのエコシステムはオープンソースコミュニティを包含しており、今後もそうする必要があります。 .NET Foundationの一部であるオープンソースソリューションだけでなく、実際のソリューションも含まれます。

しかし、このライブラリは、作者が忙しくなった瞬間にメンテナンスされなくなる可能性があります

同様に、「公式」パッケージは、会社が関心を変えるとすぐに維持されなくなる可能性があります。 これは、Microsoftが公開した複数のオープンソースパッケージなど、以前はMicrosoft固有の問題で発生していましたが、どの企業にとっても当然のことです。

あなたが別のもののライブラリの依存を取ることにした場合、それはあなたがそれと一緒に暮らすことができ、あなたの責任です。 その作者が誰であるかに関係なく。 オープンソースの良いところは、作者が応答しなくなったとしても、自分で変更する権利が完全にあることです。

私は、あなたが思いつく可能性のあるすべてのものに対して、公式のマイクロソフトソリューションを期待することに本当にひどく傷つけます。

エンタープライズアプリケーションを構築していて、まだこのNIH症候群に苦しんでいる（または「<大企業>で発明されていない」）場合は、2018年であり、今すぐオープンソースを採用する必要があるため、本当に目を覚ます必要があります。

確かに、Microsoftはパッケージの保守を停止できますが、少なくとも特定のLTSがあります： https ：

たとえば、.NET Core 1.1のサポートは2019年6月27日に終了します...このようにして、このバージョンを使用しても途中で機能しなくなることはありません。

私はかつてサードパーティのページ付けタグヘルパーを使用していましたが、それは快適ではありませんでした。著者は基本的に、.NET Core 1.1で修正しないと言っていました。プロジェクトを更新する必要があります。これは、大学のシステムでした。 2.0（そして、彼はそのパッケージを無料で書いたので、

ここに問題があります。企業では、これは機能しません... pagination-tag-helperが機能しないという理由だけで、アプリが稼働している間に2.0に移行する必要があることをチーム全体に納得させることはできません。仕事だ！
したがって、デコレータを使用して行ったように、ソースのハッキングを開始するだけです： https ：

そして、ええ、私はオープンソースの大ファンではないと誰が言ったのですか：confused：？

@ 0xRumpleは、貢献してコラボレーションするためのオープンソースのアイデアではありませんか？

そのサードパーティのページ付けタグヘルパーが存在しなかった場合は、自分で作成して、とにかく「企業内」で維持する必要があります。

ここに問題があります。企業では、これは機能しません... pagination-tag-helperが機能しないという理由だけで、アプリが稼働している間に2.0に移行する必要があることをチーム全体に納得させることはできません。仕事だ！

「2.0に移行する必要があることをチーム全体に納得させる」ことを試みるのではなく、他の誰かに作業を任せたり、Microsoftが同等のものを提供するのを待つのではなく、更新を提供して支援します。 所有者があなたの貢献を受け入れたくない場合は、あなたのニーズに合わせてフォークを進めてください。

あなたのタイプの考え方（まったく攻撃を意図していない）が、「Microsoft認証サーバー」とIDサーバーについての議論がある理由の大きな部分だと思います。 開発者が参加したくない場合、オープンソースはどのように機能しますか。 Microsoftが必要なすべてのコードを提供するのを待つ必要がありますか？

私はここにいる多くの人に同意します。マイクロソフトは、すべてを独自に置き換えることによって、エコシステム内の優れたオープンソースプロジェクトを殺さないように注意する必要があります。

私は実際には@ 0xRumpleで言及されているページネーションtaghelperライブラリの作成者です。彼の問題は、実際には1.xaspnetコアをサポートする古いnugetを備えたtaghelperではなくpagedlistコンポーネントにありました。 ページングリストは、実際には、ライブラリの設計を通知し、デモページで一度に使用された、以前のオープンソースページングライブラリの一部でしたが、ページングリストヘルパーはページングリストの実装に依存せず、他のページングもありました。ポケットベルtaghelperを使用しながら、彼が使用できた可能性のある実装を一覧表示します。 実際、ページングされたリストはタグヘルパーの一部ではなく、一度も含まれていなかったため、そのライブラリから完全に削除しました。

OSS開発者からのnugetパッケージを使用する場合、Microsoftと実際に違いはありません。aspnetcore1.1で立ち往生している場合、新しいフレームワークに更新しない限り、aspnet core2.xから修正や改善を得ることができません。

@joeaudette
組み込みソリューションとサードパーティソリューションのポイントを説明するためにその例を説明しましたが、そのページ付けタグヘルパーに関する作業に感謝しています...大学はページ付けパッケージを使用しており、彼らは満足しています：heart：

@alhardy

Microsoftが必要なすべてのコードを提供するのを待つ必要がありますか？

これが主な問題です。マイクロソフトが公式のソリューションを提供すると、他のオープンソースソリューションと戦うか、コードのすべての行を自分で作成すると思います：smile：

もちろんそうではありません。マイクロソフトが適切なソリューションを採用し、不足しているソリューションを作成すれば、公式ソリューションとコミュニティベースのソリューションの両方の長所を活用できるため、開発者はそれらに貢献することに集中できます。

djangoコミュニティはそれを正しく理解し、RESTfulフレームワークなどの特定の問題に対する最初の簡単なソリューションを公式に提供/採用し、その上にコミュニティを構築しています... django-rest-を構築する最初の段階をここで見てください。フレームワーク： https ：

彼らは最初のプロジェクトを開始し、コミュニティはその上で改善/構築しています。これは彼らのリポジトリです：
そして、コミュニティは、 django-rest-authやdjango-rest-framework-jwtような、そのパッケージの上に問題を解決するパッケージを構築するように駆り立てられています。

少なくとも、 django-admin-siteやdjango-debug-toolbarように、ほとんどの開発者が必要とするような「公式ソリューション」を提供します。 これも「バッテリーを含む」というPythonの哲学に由来します。最初は、最小公分母のソリューションを目指しているので悪いと思いましたが、後でそれがもたらすそよ風に気づきました。

* PS：Dapper（StackExchangeによる）とEFCore（Microsoftによる）はどちらもORMですが、異なるアプローチで同じ問題を解決することを目的としています。 Dapperは最初2011年に作成されましたが、EFCore 2014 ... EFCoreはオープンソースプロジェクトに悪影響を及ぼしましたか？ もちろんそうではありません、そしてそれは公式の解決策です！
https://github.com/crhairr/EntityFrameworkCore.MongoDb/のように、人々はすでにその素晴らしいものの上に構築してい

EFCoreはオープンソースプロジェクトに悪影響を及ぼしましたか？

うーん、誰もがNHibernate（機能的にEFに最も近い）を覚えていますか？ いいえ、おそらくそうではありません。EFがリリースされた後は死んでいるのと同じくらい良いからです😕

@ 0xRumple

もちろんそうではありません。マイクロソフトが適切なソリューションを採用し、不足しているソリューションを作成すれば、公式ソリューションとコミュニティベースのソリューションの両方の長所を活用できます。

この場合、それは既存のソリューションを再作成しているためではなく、意図的に機能が少なくなっているためです。

EntityFrameworkとDapperは大きく異なります。 EFは常にフル機能のORMになるように設計されており、どちらも2007年の最初の

しかし、あなたも間違っているとは思いませんし、私たち全員がお互いを超えて話しているようです。 スレッドは主に、REST関連のライブラリについて話している間、認証サーバー製品についてのコメントです。これらのライブラリは、Webフレームワークに含めるのに十分なほど小さく、焦点が絞られているように見えます。 標準化されたsearch/paging/filterパラメーターがWebAPIコードの組み込みに役立つことに同意します。

この議論は、一部の組織では、開発者がソリューションに導入されたすべてのオープンソースパッケージを説明する必要があるという厄介な真実を認めていません。 場合によっては、これは自動スキャンであり、技術的でないリスク管理者が頻繁に確認する必要がある「リスク」レポートを生成します。 これらのツールは、アクティブに保守されていないものや、コピーレフトライセンスのように見えるものすべてにフラグを立てます。

また、これらの組織では、オープンソースに貢献することはクレイジーな話と見なされていることも想像できます。

はい、Identity Server4は素晴らしいです。 しかし、技術的でないリスク管理者にとって、それは保証がないものであり、少数の人々によってサポートされているものであり、さらに悪いことに、誰もが見ることができるソースコードを備えたものです。 この人は見当違いですが、現場の平均的な開発者はこの戦いに勝つつもりはありません。

@markrendleが適切に述べている「IdentityServerLite」は、主にMicrosoftのスタッフによって書かれたものであり、特に組織内に$$を主張するエンタープライズアーキテクトがいる場合は、

@edandersen

しかし、技術的でないリスク管理者にとって、それは保証がないものであり、少数の人々によってサポートされているものであり、さらに悪いことに、誰もが見ることができるソースコードを備えたものです。

IdentityServerの人々は、Microsoftに支払うのと同じように、支払いをすればある程度のサポートを提供すると確信しています。 OSSは無料と同じではありません。

マイクロソフトのASP.NETCoreチームが「少数の人々」ではないと思う理由は何ですか。 ネタバレ…全部で20〜30人くらい。 そのような製品に取り組むのはカップルだけです。

「誰もが見られるソースコード」がなぜ悪いのか、本当に気になります。 そして、マイクロソフトのこの製品がオープンソースではないと思う理由は何ですか？ これが新しいデフォルトです。

@khellang 「誰もが見ることができるソースコード」を明確にすることは良いことです！ しかし、一部の開発者が仕事で持っている必要がある議論に驚かれることでしょう。 残念ながら、「Microsoftが書いた」という点が唯一の受け入れ可能な議論である場合があります。 私は架空の、しかし典型的な機能不全の会社のために悪魔の代弁者を演じていることに注意してください。

そしてもちろん、同じ開発者は、雇用主がIdentity Serverのサポートにお金を払うことを主張することもできますが、調達プロセスはおそらく彼らの生きる意志を奪うでしょう。

さて、これらの非技術マネージャーの議論を使い始めると、物事はおかしくなり始めます。 技術者ではない私見は、何を使うべきかを指示するべきではありません。 彼らがことわざを持ちたいのなら、少なくとも彼らは彼らが話していることを知っているべきであり、IdentityServerのようなよく知られているパッケージはMSのものよりも品質が低いと言っています、私にとってはそれは明らかに間違っています。 私はそのような会社から経営します！

しかし、ここでのポイントは、ほとんどの人が、すでにそこにあるものに時間を費やすことに同意しているということです。それは堅実で、多くの人々がそれを使用しているのは少し奇妙です。 この背後にある本当の理由は何だろうか..私はそれが次のようなものではなかったと思います：ああ、私たちができるという理由だけで、私たち自身のものを作りましょう。 顧客は実際に私たちがおそらく気づいていないこれを求めていますか？

個人的には、OAuth-Serverスペースで別の競合他社を問題とは見なしていませんが、良いことです。

それは、この分野での開発を促進するのに役立つかもしれませんし、それ以上のものを必要としない人々のための迅速で汚い解決策として役立つかもしれません-迅速で汚い解決策。

OAuthサーバーからさらに多くのものが必要な場合は、既存のソリューションの使用を妨げるものは何もありません。 または、ワンクリックテンプレートで基本的なOAuthを実行し、それ以上のことは何もしないようにしたい場合、少なくとも私にとっては、これは価値のある目標のように思えます。

このスレッドは、.NET Core 2.2のロードマップにあるものに焦点を当てるのではなく、OSSとは何か、MSが得意なこと、MSが得意ではないことについてのしっぺ返しにな​​っていると思います。ここで重要です。

@khellang
「NHibernateは死んでいる」と誰が言ったのですか？ プロジェクトはまだ生きていて、Dapperよりも勢いがあります
https://github.com/nhibernate/nhibernate-core/graphs/contributors
https://github.com/StackExchange/Dapper/graphs/contributors

ああ、これまでIdentityServerについては、公式のaspcoreパッケージ内にRESTfulフレームワークを含めることに固執することについては触れていませんでした...これがIdentityServerについての私の考えです。これは本当に堅実で素晴らしいですが、2人のプロジェクトです。メトリックを見てください：
https://github.com/IdentityServer/IdentityServer4/graphs/contributors

作業の約85％は2人で行われ、セキュリティ関連のプロジェクトでも問題ありませんが、企業では多くの企業がそのようなプロジェクトの将来の保守性について考えています。 最近、ある会社から、「vue.jsはほとんどEvan Youだ」と言われたという理由だけで、プロジェクトでVus.Jsの代わりにReactを使用してほしいと言われました...そして私は彼らが正しいと思います。 そしてこれは、公式パッケージ内にRESTfulパッケージを含めることについてことです。大企業は、プロジェクトで「潜在的な」非保守パッケージを使用することを受け入れません。

ほとんどすべてのプロジェクトにこれらの要件が含まれているため、データ操作/ふるい分け（ページング、シェーピング、並べ替えなど）にも同じことが言えます。 @ manigandhamが言ったように、それらは標準化されており、簡単です。

@manigandham
まさにそれが正しいと思います...財政的であれ、githubを介した貢献であれ、少なくともドキュメントやコースでそれらについて言及している場合でも、ソリューションを公式に適応させてサポートします（HanselmanがMicrosoftVirtualのコースの1つでSwashBuckleについて言及しているのを見ました。本当に素晴らしいアカデミーであり、そのようなプロジェクトへのより多くの適応を見るのはもっと素晴らしいでしょう！）。

@kieronlanning
あなた私たちはあまりにも遠く、メイントピックから行ってきた...しかし、私は前に述べたように、ASPコアはちょうど非常に（パフォーマンスと信頼性）外ので開始することの時間を考えている右、

2人の主な貢献者がいるのでプロジェクトを割り引くのはかなりばかげていると思います。 IS4は非常によく維持されており、これら2人は質問への回答と人々の支援に多くの時間を費やしています。 また、市場に出回っているOAuth2サーバーに最適なFOSSソリューションの1つとして広く認識されています。

「NHibernateは死んでいる」と誰が言ったのですか？ プロジェクトはまだ生きていて、Dapperよりも勢いがあります

@ 0xRumple私は「死んだのと同じくらい良い」と言いました😉あなたはOSSプロジェクトの健全性と使用法に関していくつかの非常に奇妙な指標を持っているようです。 2003年からのプロジェクトのコミット数を2011年以降に行われているコミット数と比較するのは公正ですか？ それらはまた_非常に_異なる獣です（スレッドで前述したように）。 Dapperはしばらくの間「完全」（つまり、保守されていない、放棄されているなどを意味するわけではありません）ですが、NHibernate（およびその機能セット）は遅れをとっています。
プロジェクトがまだ順調に進んでいることは知っていますが、最後の7年間で、.NETスペースでコンサルティングを行ったとき、野生でNHibernateに遭遇しました（ Entity Frameworkに移行されます）。 ここ数年このスペースをフォローしている人は誰でも、NHibernateが遅れを取り、EntityFrameworkの市場シェアを失っていることをよく知っています。 NuGetのダウンロード数だけを見てください。EntityFrameworkのダウンロード数は45.8Mであるのに対し、NHibernateのダウンロード数は340万です。

とにかく、ポイントはEntityFrameworkとNHibernateではありません。 それはただの1つの例でした。 私たちはこの議論を何度も繰り返してきました。 最近では、MicrosoftがASP.NET Coreで独自の軽量IoCコンテナー実装をロールしたとき、またはMicrosoftが独自のオブジェクトマッパーのロールを検討していたとき。 マイクロソフトがOSSコミュニティのスペースに入るときはいつでも、部屋から多くの（ほとんど？）空気を吸い込みます。 多くの場合、小規模なコミュニティ主導のプロジェクトが時間の経過とともに窒息するのに十分です。 私とほとんどのコミュニティは、それをよく知っています。 Microsoft独自の（.NET）世界でMicrosoftと競争することは不可能です。 私は彼らが満足する必要がある有料の顧客を持っていることを完全に理解しているので、私はこのフィードバックが彼らの心を変えることを期待していません：smile：

素晴らしい機能:)

ヘルスチェック機能の詳細はどこで入手できますか？

自己署名証明書の管理を改善する

関連するWebAPIを呼び出すWebアプリを開発する場合、ローカルネットワークを介して社内ユーザーでそれらをテストすると便利な場合があります。 ユニットテスト、機能テスト、統合テストのすべてに合格したかもしれませんが、実際に物事を壊すのは人間のようなものではありません。

懸念を切り離すという精神で、私のWebアプリは複数のWebAPIを呼び出します。 最初に、 https：// localhostを使用してこれらのWebAPIを開発し。 Web APIの準備ができたら（十分に）、ローカルマシンのIISに公開します。 各サイトには、内部DNSサーバーに設定した適切なホスト名があります。 この時点で、BarryDorransの- @ blowdart - ： //gist.github.com/blowdart/1cb907b68ed56bcf8498c16faff4221cを使用してサーバー証明書を作成します。 提供する証明書をすべての適切なストアにインポートすると、すべてがアラームなしでマシン上で機能します。

これは、ネットワーク上の他の人がWebアプリにアクセスすると変更されます（API呼び出しはすべて私の開発ボックス内にあります）。 ユーザーは悲惨な警告を受け取ります。 私は、これらの警告を無視し、可能で十分に簡単な場合は、証明書をインポートするように指示します。 これらの自己署名証明書は同じ発行者名と共通名を持っているため、新しいWebアプリごとに警告ページがトリガーされます

組織内のユーザーに警告ページを確認するように依頼するのは悪い考えだと思わずにはいられません。

セキュリティの専門家ではないので、私が見たいことがいくつかあります。

• 私が作成したすべての開発証明書のローカルルート証明書を取得し、それをPC、Mac、Android、iPad、iPhoneデバイスにインポートする許可された方法を教えられる機能。これにより、これらの警告ページが発生しなくなります。

• IISおよびKestrelで使用できるAPIの証明書を生成する簡単な方法で、すべての正しい証明書ストアに正しく入力します

@CrispinH正直に言うと、ルートCAをサポートすることは、ルートCAを問題になります。 その時点にいる場合は、ルートCAを自分で起動して管理することを検討してください。 グローバルツールまたは私のスクリプトはそのためだけのものですが、自己署名サポートは開発です。 人々にそれを付けさせ始めると、あなたはその機能の範囲外になります。 組織内にいて、人々にサービスにアクセスしてもらいたい場合、組織は証明書戦略を理解し、WindowsまたはOpenSSLを介して内部CAを実行し、ADポリシーまたはその他の手段を介してルートをプッシュする必要があります。

@blowdart私の悲鳴の理由の1つは、ルートCAを起動しようとして数日を費やし、この分野での能力が不足しているにもかかわらず、正しく取得できなかったことです。 ローカルルートCAを受け入れるように要点を変更する方法を考え出すことさえ試みました。
私が見つけたすべてのドキュメントはあまりにも一般的でした-私が欲しかったのは、サーバー証明書でAPIとWebアプリを保護するためだけに証明書（理想的にはルートCAに基づく）を作成するプロセスでした。 おそらく、特定のケースのドキュメントだけが必要です。

@CrispinH Window Serverには、完全に実行したい場合に設定できる認証局が付属しています。

一般に、証明書は簡単なトピックではなく、正しく行うにはかなりのことを学ぶ必要があります。

開発目的では、自己署名証明書はまったく問題なく、使いやすいです。 CAの設定と管理を含む、それを超えるすべてのものは、もはや開発目的ではなく、間違いなく範囲外であり、Webアプリケーションフレームワークには複雑すぎます。

@CrispinH @pokeが言ったように、それを正しくするのは難しいです。 ルートCAを信頼するマシンを作成すると、発行されたすべての証明書が信頼され、開発者は開発ボックスで信頼されていないコードを実行します。これが、結局のところnugetパッケージです。 したがって、ルートCAを盗むものを検討してください。 実際のルートCAはオフラインに保たれる傾向があり、2番目の証明書に署名します。これは、通常、サーバー証明書とクライアント証明書の機能に制約があり、それによって証明書が発行されます。これにより、多くの開発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が必要な場合は、ウィンドウに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のコミュニティの取り組みを学び、受け入れ、関与し、最小限の労力でnugetとセットアップから含めることができる意見のあるIdentityServer "Lite"バージョンの作成に貢献するために、さらに別の実装ではなく、新しいOpenID実装を検討します。

あなたはすべて過剰反応しています。
ASP.NETチームは、すでに皆さんのように考えています。 @DamianEdwardsは、最新のコミュニティスタンドアップでそれについて話しました。

最も関連性の高い部分は次のとおりです（ただし、すべてを聞くことをお勧めします）。

「私たちは実際に今それについてIdentityServerの人々と話し合っています。」
https://youtu.be/Tzh2EXwgEk8?t=25m15s

「MSFT認証サーバー」プロジェクトに関する議論がどれほど情熱的であるかを見るのは本当に興味深いです：smile：

ちなみに、Vittorio Bertocciは、OpenIddict（私が開発および保守しているOIDCサーバー）をこのプロジェクトのベースとして使用することを検討していたため、ちょうど2年前にこのプロジェクトについてチャットするために私に連絡しました。
昨年、ビジネスの観点から「戦略的すぎる」と考えられてれました（これは私が理解できることです）。

彼らが考えを変えて、最初から別のものを作成する代わりに、IdentityServer4のような既存のOSSソリューションの使用を最終的に検討しているのを見てうれしいです：それは.NETコミュニティに送信される非常に良いシグナルです：clap：

これはスレッドから少し外れますが、 @ CrispinH 、 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の実行に関するコメントも参照してください。 ライブラリツールはほぼそこにあり、組織によっては、多くの内部構造を設定しなくても、一部のサーバーで制御された方法で証明書を使用できる場合があります。 そのトークンでは、（DERでエンコードされた）証明書署名要求（CSR）をすぐに読み取ることは、JSON-LDライブラリーとともに優れた追加機能です。 そして、一般的にはより多くの暗号。 :)

LetsEncryptのサポートのようなミドルウェアが欲しいです-WindowsのAppServices、Linux、AzureのDockerで動作します。

@kieronlanning前述のCSR署名に関するDERエンコーディングに加えて、同意します（ただし、エッジケースなしでサポートを追加することはそれほど難しくはありません）。 .NET用のライブラリがいくつかありますが（Let's Encryptページにもリストされています）、少し問題があります。 例えば、最も積極的であることのようにしてみましょうEncryptc 1ルックスに関して.NETを維持Certesが、それは上dependecyを取るBouncyCastle 。 誰かがそれを.NETStandard2.0のみにするのを手伝ってくれたらいいのにと思います。 私の理由の1つは、BouncyCastleがOrleans TaskSchedulerとうまく機能しないことです。 :)

暗号について言及することについては、厳密にはASP.NET Coreの問題ではありませんが、MSはブロックチェーンを強く推進しているようですが、.NETには暗号機能がありません。 _表面的には_これの多くはASP.NETコアにも関係しています（たとえば、https：//etherscan.io/などのさまざまなブロックチェーンエクスプローラーの実装など）。 Infernoのようなライブラリと、プラットフォームに組み込まれたさらに多くの機能。 未解決の問題の1つは、 https： //github.com/sdrapkin/SecurityDriven.Inferno/issues/10#issuecomment -395778931にあり

@kieronlanningからのこれは、私の一番の機能リクエストになります。

「LetsEncryptのサポートのようなミドルウェアが欲しいです。」

未解決の問題は次のとおりです： https ：

SignalRだけでなく、すべてのフレームワークのasp.netコアで利用できるメッセージパックと見なされていますか？ Http2フレーミングはバイナリなので、そのためのメッセージパックを検討していますか？

承認サーバーはpreview3でリリースされましたか？

それはすでに存在しています。 Https://IdentityServer.io

@leastprivilege
私はIdentityServerが好きで使用しています
しかし、私はマイクロソフトの実装を見て、（マイクロソフト）があなたのコアにアイデンティティサーバーを組み込んでいない理由を理解することに非常に興味があります

@ danroth27-最新情報を共有できますか？

MicrosoftはIdentityServerを使用しています。

では、これはどのように機能していますか？ MicrosoftはIDS4コードを直接使用していますか？ マイクロソフトはIDS4機能を削減しますか？ ここのモデルは何ですか？ 私たちの期待は何ですか？ それらの間に可能な移行パスはありますか？

Microsoftは、標準のnugetパッケージを使用し、構成APIを使用して、テンプレートとASP.NETIdentityでうまく機能するようにいくつかのデフォルト設定を提供します。 それで全部です。

あなたは今日すでにまったく同じことを達成することができます。

おそらく私ですが、Microsoft認証サーバーのギャップがIdentityServer4によって埋められていることを読んで驚いています。 私の理解によると、IdentityServerの主な関心事は認証であり、承認ではありません。

私にとって、IdentityServerは認証サーバーとしては問題ありませんが、承認サーバーとしては機能しません。 それがPolicyServerが作成された理由だと思いました。

@leastprivilege IdentityServerはPolicyServerのようなもので拡張されますか？

@Ruardそれで、それは紛らわしいです（そして、ドミニクはおそらく私の説明にうんざりするか、選ぶでしょう）。

OAuthは認証ですが、最初のステップとして承認があり、スコープなどに基づいて付与を発行します。したがって、ラッピングでは、Identity Serverがログインを実行し、検証し、必要なスコープを検証します（最初の場合はデフォルトのスコープを使用しているため、常に成功します）、トークンを呼び出し元に返します。このトークンは、APIに送信されて検証されます。その後、オプションで、API内の承認ルールをさらに進めることができます。 OIDCは、アプリに許可されている認証など、ユーザーのID情報を取得する方法として、さらに混乱したOIDCを提供します...

したがって、基本的に、Identity ServerはIDを提供し、アプリがIDを持つことを許可されていることを承認します。その後、ASP.NETの承認部分を使用してアクセスをさらに制御できます。

@MichelZは大人の話があります。 単純なシナリオ用に構成します。シナリオの外に出ると、IdentityServer構成モデルの全機能を調べることができます。

@blowdart私たちはすでにIdentityServerを使用しています（そしてその機能に感銘を受けています！）が、Microsoftの「長期サポート」ポリシーの恩恵を受けることも私たちにとって大きなプラスです。 したがって、ここで提供できる相乗効果はどれでも大歓迎です。
ASP.NET CoreとIdentityServer（4）の両方の製品が同じように気に入っています。 それは間違いなく私見の正しい方向への一歩です。
ただし、これらすべてのプロトコルが正確に「単純な」ものではないことも認識しています。 彼らはあなたが彼らを理解しているロケット科学ではありませんが、それでも彼らは単純ではありません。

誰かが本当に単純なプロトコルを発明し、すべてのレガシー実装を残して将来に焦点を合わせてくれることを願っています。

あなたがすでにそれを使用しているなら、あなたの使用は実際には変わらないでしょう、あなたはそれを機能させています:)

私たちは、個別認証を使用した[ファイルの新規作成]> [Web API]を目指しており、次に他のAPIを追加しています。すべて、規則に基づいています。 規則が新しくなるため、これは既存のアプリでは機能しません。 私はあなたの設定を私たちのものに置き換えるつもりはありません:)

誰かが本当に単純なプロトコルを発明し、すべてのレガシー実装を残して将来に焦点を合わせてくれることを願っています。

これが問題です。アプリはますます複雑になっています。 それらを保護するために、セキュリティも複雑です。 IdentityServerは複雑だと人々が言うのを聞いたとき、私はいつも押し返してきましたが、そうではありません。 複雑なのは、アプリケーションのセキュリティ要件です。 多くの場合、人々はそれを認識する視点を持っていません。

はい、それは機能しています-そしてそれはうまく機能しています-それでも、マイクロソフトがテクノロジーを公式に「承認」し、最終的に「サポート」するとき、それがあなたに与える追加の保証は純粋な金です....！
あなたはまったく新しいレベルに引き上げられました！

@brockallenはい、アプリケーションはおそらく物事を

私たちが今持っているものが「悪い」と言っているのではありません。私たちが持っているものに本当に感謝しています。それは私たちの目的にとって本当に機能的です。

@チーム;
プレビュー3については、「認証サーバー」に関する詳細なドキュメントと、WebAPIおよびVueなどのクライアント側JSでどのように機能するかを教えてください。
決定を下す必要があります。承認サーバーでのこのプレビューは重要なプレビューであり、詳細なドキュメントから決定に関する情報が得られます。

ありがとう！

前に説明したように

https://identityserver.io

米国のオープンデータ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を使用してそれを効率的に処理する方法が明確でないことに注意したいと思います。

私見ですが、IdentityServer4をASP.NetCoreのコアに追加するのは悪い考えです。
.NetCoreをモノリシックフレームワークとして作成しないでください。
.NetCoreがあり、IdentityServer4があります。人々は、独自の認証と承認のニーズに基づいてアーキテクチャを作成します。

@mikeandersun計画は、プロジェクトに追加してすぐに機能させることができる簡単なデフォルト構成を

あなたはまだそれを使うことができません、そしてそれはあなたに影響を与えません。 IdSrvを引き続き使用して、自分で完全に構成できます。 プロジェクトに含めるコンポーネントを引き続き選択できます。 これはいずれもASP.NETCoreをモノリシックにしているわけではありません。

ASP.NET Core！= .NETCoreところで。

2.2はLTSリリースになりますか？ （新しい発表をするように求めるのではなく、すでに発表されているかどうかを尋ねます。）

@yzorgいいえ、発表されていません。 その決定は、多くの場合、品質/安定性に基づいてリリース後に行われます。

@blowdart 、このテンプレートは、APIの代わりにWebアプリMVCクライアントをIDサーバーに提供しますか？

@Ponantいいえ。APIのみを対象としています。 3.xタイムラインでそれを再評価します。

興味深い...この質問は昨日の会議で出ました。 Web APIを使用せずに完全な「MVC」プロジェクトを構築する場合、2.2に統合されている新しいASP.Net 2.2 IS4テンプレートを使用できますか？
ビッグボス（バリー）が質問に答えたようです。

@blowdart alliasビッグボス：なぜそれが一発で行われないのですか？ asp.netコアIDIS4サーバーと通信するmvcクライアントまたはWebAPIを使用することは一見簡単に思えます。

@Ponant無限のリソースがないからです。 新しい機能を提供せず、既存の機能の動作を変更するだけで、MVCフローの主要部分を変更できるようにするために、どの機能を削除してほしいと思いますか？ 個々の認証済みAPIは、完全なフレームワークとASP.NETCoreの間のギャップでした。 仕事の焦点はそのギャップを埋めることでした。 Identity Serverには、IdentityServerを「コア」として使用するMVC用の作業用テンプレートがすでにあります。

@CrispinH @blowdart私はあなたに-この数百の開発者と企業について

->ユーザー/グループ/テナント管理に対する非常に多くのリクエスト

->もう一度ここで人々が不平を言っています...それはツイッターやフェイスブックでも続きます..これが理由です-WPやPHPのような他のプラットフォームがより簡単な理由です！

@manigandhamは、IDサーバーが、GUI管理ツールには多くの費用がかかり、多くの国や開発者にとって安くはありません。また、TCOの低い開発者にも反します。 本当にこれを買う余裕のある人は何人いますか。 これは大きな障害であり、後退しました。ユーザー/ロール/ロール-ユーザーグループ/テナントを管理するための基本的なバニラ機能とGUIが必要であり、開発

@papyrこのためのオープンソースプロジェクトを始めてみませんか？ すべての完全なGUIをフレームワーク（テンプレート）に組み込む必要はありません。 そして、たとえばBootstrapの変更など、チームがテンプレートの更新を維持することがすでにどれほど難しいかを見て、私はチームがそれにもっと労力を費やしてほしくないのです。 しかし一方で、これは存在するのに役立つものだと私は完全に理解しているので、これをコミュニティの努力だけにしてみませんか？

@papyr @poke新しいオープンソースプロジェクトは必要ありません。優れた既存のプロジェクトがあります。

WordPressと競合するように設計されたMSのオープンソースが必要な場合は、Orchardをご覧ください。
https://github.com/OrchardCMS/OrchardCore

フレームワークの代わりにライブラリアプローチをもっと必要とする場合は、クラウドスクライブをチェックしてください。クラウドスクライブには、オプションのidentityserver4統合とオプションのcms（cloudscribe.Simple / content）が事前に構築されたマルチテナンシーとユーザーおよびロールとクレーム管理のUIがあります。追加のnugets。
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

私はこの推奨事項を2番目にしています。

また、オーチャードコアは非常にモジュール化されるように設計されています。 たとえば、マルチテナンシーモジュールだけを

あなたは彼らのチャンネルでその様々な機能の多くのデモを見ることができ

@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 （Gitter）など、基本的なニーズから少しでも外れたときに覗くための追加の説明とコードを提供します。 名前やプロジェクトを追加するのを忘れてしまいました。 :)

なぜ.netコアに通常のかみそりのWebページがないのですか？ 複雑なレポートを作成するときは、1つのかみそり（c＃）ページからすべてを実行するのが好きです。 または、少なくとも、モデルやコントローラーがない場合にのみビューのみを使用する機能。

言い換えれば、ビューでsqlに接続し、GETおよびPOSTリクエストを受信する基本的な機能は、もちろんサニタイズされています。現在、Striptag.cs​​というクラスを使用しています。

なぜ.netコアに通常のかみそりのWebページがないのですか？

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

私はmvcasp.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と入力すると、2番目の区分が「hello」になりますが、
@ Model.myvar何も得られません。

私は.netCoreを初めて使用しますが、かみそりのページを簡単に表示するのが難しい、または難しいとは想像もしていませんでした。

VSコミュニティ2017で

@ Model.myvar何も得られません。

フォーム値psearch ;を使用して、POSTリクエスト（ OnPost ）にmyvar値を設定します。 その値を設定するには、その値を使用して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が完全に統合され、WebAPIとMVCの両方がサポートされることを願っています。

最近では、最低限、産業強度の認証/承認が必要です。 オープンソース（OSS）はほとんどの場合問題ありませんが、一部のOSSセキュリティ製品には深刻な不安があり、どの企業のWebサイトでも受け入れられません。 プロジェクトの85％は、許容できないセキュリティリスクである古いライブラリを使用しています。 たとえば、45％のWebサーバーは、IIS（https://www.cvedetails.com/product/3436/）よりもはるかに多くの脆弱性を持つApache（https://www.cvedetails.com/vendor/45/Apache.html）を使用しています。 Microsoft-IIS.html？vendor_id = 26）。 Identity Serverなどの製品は問題ないかもしれませんが、開発者の調整によって完全に安全でなくなる可能性があります。 常に安全なNetCoreに組み込まれたソリューションが必要です...

最近では、最低限、産業強度の認証/承認が必要です。 オープンソース（OSS）はほとんどの場合問題ありませんが、一部のOSSセキュリティ製品には深刻な不安があり、どの企業のWebサイトでも受け入れられません。 プロジェクトの85％は、許容できないセキュリティリスクである古いライブラリを使用しています。 たとえば、45％のWebサーバーは、IIS（https://www.cvedetails.com/product/3436/）よりもはるかに多くの脆弱性を持つApache（https://www.cvedetails.com/vendor/45/Apache.html）を使用しています。 Microsoft-IIS.html？vendor_id = 26）。 Identity Serverなどの製品は問題ないかもしれませんが、開発者の調整によって完全に安全でなくなる可能性があります。 常に安全なNetCoreに組み込まれたソリューションが必要です...

あなたの主張は絶対に正しいです。 しかし、一部のビデオでは、MSスタッフは、[セキュリティ]ホイールを再発明し、サードパーティの[IS4]システムを使用するつもりはないと述べていました。 ですから、これが私たち全員にとってお互いに有利な状況になることを願っています。

最近では、最低限、産業強度の認証/承認が必要です。 オープンソース（OSS）はほとんどの場合問題ありませんが、一部のOSSセキュリティ製品には深刻な不安があり、どの企業のWebサイトでも受け入れられません。 プロジェクトの85％は、許容できないセキュリティリスクである古いライブラリを使用しています。 たとえば、45％のWebサーバーは、IIS（https://www.cvedetails.com/product/3436/）よりもはるかに多くの脆弱性を持つApache（https://www.cvedetails.com/vendor/45/Apache.html）を使用しています。 Microsoft-IIS.html？vendor_id = 26）。 Identity Serverなどの製品は問題ないかもしれませんが、開発者の調整によって完全に安全でなくなる可能性があります。 常に安全なNetCoreに組み込まれたソリューションが必要です...

「常に安全」なものはありません。特にMicrosoftの製品ではありません;）
それを作り、安全に保つことは、常にこれらのもののユーザーの手に委ねられています。

IdentityServerは、2.2以降に出荷される新しいテンプレートに含まれる予定です。 最初の焦点はAPIアクセス制御ですが、将来的にはそれを拡張する計画があります。

ASP.NET Coreには、テンプレートシナリオのみをカバーする簡略化された構成APIが付属していますが、開始は非常に簡単です。 高度なシナリオを提供するISネイティブ構成システムにいつでも移行できます。

IdentityServerは、2.2以降に出荷される新しいテンプレートに含まれる予定です。 最初の焦点はAPIアクセス制御ですが、将来的にはそれを拡張する計画があります。

ASP.NET Coreには、テンプレートシナリオのみをカバーする簡略化された構成APIが付属していますが、開始は非常に簡単です。 高度なシナリオを提供するISネイティブ構成システムにいつでも移行できます。

ドミニクの情報をありがとう。
この「踏み石」は、多くの人が始めて完全なISに移行するのに役立つと思います。 良い動き。

IdentityServerは、2.2以降に出荷される新しいテンプレートに含まれる予定です。 最初の焦点はAPIアクセス制御ですが、将来的にはそれを拡張する計画があります。

ASP.NET Coreには、テンプレートシナリオのみをカバーする簡略化された構成APIが付属していますが、開始は非常に簡単です。 高度なシナリオを提供するISネイティブ構成システムにいつでも移行できます。

知っておくと良い！ ありがとうございました。

このAPIアクセス制御はOAuthスコープに基づいていると思いますか？
policyserver.ioで説明されているような、より揮発性の高いユーザー権限の直接サポートはありませんか？

IdentityServerは、2.2以降に出荷される新しいテンプレートに含まれる予定です。 最初の焦点はAPIアクセス制御ですが、将来的にはそれを拡張する計画があります。
ASP.NET Coreには、テンプレートシナリオのみをカバーする簡略化された構成APIが付属していますが、開始は非常に簡単です。 高度なシナリオを提供するISネイティブ構成システムにいつでも移行できます。

知っておくと良い！ ありがとうございました。

このAPIアクセス制御はOAuthスコープに基づいていると思いますか？
policyserver.ioで説明されているような、より揮発性の高いユーザー権限の直接サポートはありませんか？

PolicyServerは商用ソリューションです

このAPIアクセス制御はOAuthスコープに基づいていると思いますか？
policyserver.ioで説明されているような、より揮発性の高いユーザー権限の直接サポートはありませんか？

「のみ」IdentityServer。 ASP.NET Coreには、ユーザー認証用のAPIが組み込まれています。PolicyServer（製品）がおもしろいと思われる場合は、お知らせください。

ASP.NET Core 2.2が出荷されたため、この問題を解決します。

これをASP3.0に更新しないでください

Authorization Serverの拡張機能がいつ出荷されるかについての更新はありますか？