-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2.2 Roadmap discussion #3265
Comments
What about EF Core 2.2 Roadmap? |
|
Roadmap looks good, particularly health checks and HTTP 2.0. However, in the kindest possible way, I disagree with the need to build a simple first party Microsoft authorization server. IdentityServer4 fills this gap nicely and the time spent re-implementing a simpler version of it could be better spent elsewhere. I understand the goal is to provide a simple solution but auth is hard and IdentityServer provides an API that is about as simple as it gets. If there are ideas for a simpler abstraction, it could be built on top of IdentityServer so people can use the simple abstraction but have the power if they need it. UpdateIn the ASP.NET Community standup, it was mentioned that the ASP.NET Core team is talking to the Identity Server team about the options, including building something on top of Identity Server. I think that's what we all want, well done! |
What are the current plans around ASP.NET Core WebHooks? |
Regarding the dispatcher, will this be possible in the middleware then? 😱 public async Task Invoke(HttpContext context, [FromRoute] SomeModel someModel) [FromQuery]? 🤔 |
Simple Auth Server but also remember what happened with Katana simple Auth Server |
I want to echo @RehanSaeed’s concerns and would like to ask for some clarifications on what exact use cases this new server is supposed to fill. If this is primarly so web APIs have a way to get their bearer token that is valid within the existing authentication of the app, then that would be fine. But everything on top of that is probably better left to the existing solutions which already offer many options of different complexity and flexibility with products like IdentityServer, OpenIddict, and AspNet.Security.OpenIdConnect.Server. |
What about IIS in-process hosting? |
Could you elaborate more on the TypeScript part of "API client generation (C# & TypeScript)"? This would be really something I would look forward to. Currently I'm using NSwag for auto-generating my Angular Client API Services. But there are just so many different combinations possible for client configurations that I think this could be problematic to please everyone. Just off the top of my head, some thing that should be considered (and if possible should be configurable):
|
If it was possible to vote for features, these improvements/fixes to existing middlware would be on my wishlist:
|
I also vote to skip the Authorization Server product. Security is complicated and there has been a big push to move to cloud services to remove maintenance, and anyone who wants more control can already use IdentityServer4 which is well-built, tested, documented, and supported. A simple setup takes 5 minutes and they have plenty of starter samples, videos, and tutorials. I fail to see how you can make security work as "zero config" any more than they can. It seems like this will just add more confusion (in naming and usage), while becoming yet another thing to support and maintain for years, taking effort away from other features continuously. Please rethink this. |
I'm also curious why IIS in-process hosting isn't on this 2.2 roadmap. This is a major feature and is a major factor in our release strategy and schedules here at Stack Overflow and it was already removed very last minute before the 2.1 release, promising a 2.2 timeframe instead. Please tell me this is just an oversight and not another plan change. Edit: @DamianEdwards replied on Twitter that this was indeed an oversight (meaning it's planned for 2.2). Phew! |
I'll echo other comments. If you're going to invest in Authorization/Policy, specifically making it simpler, I'd personally much rather see a partnership with the likes of OpenIddict and IdentityServer on docs and investments in scaffolding. I can't help but feel that any work, no matter how simple, is just going to end up duplicating terrific third-party efforts and incurring an unnecessary maintenance cost on the aspnet team. |
It maybe an unpopular view, but I'd like to see a Microsoft Auth Server, one that's built in the public eye, with our input and support. The current ones - Id4, OpenIddict - are obviously excellent OSS projects, and I can't help feeling that one with the support of MS behind it could ever be a bad thing...? There's a limit on just how much support is available from a small group of people, and these are mission critical products afterall. |
I think it's a pity that the MS OSS Code of Conduct doesn't include a line which says "Don't promote features that duplicate something that can be brought-in with a Nuget request and which will casually crush a two-man business that contributes to our ecosystem". The cynic in me can't help wondering if, for some insiders, giving Brock and Dominick a bloody nose was a feature of this suggestion rather than than a bug. Is this what happens to small businesses that ever have the temerity to criticise anything the ASP team does? |
I also wonder that about duplicating auth functionality other than building something on top, such as UIs and documentation. Addtionally, a well tested JSON-LD 1.1 library would be a nice, specific addition to the roadmap. :) |
Repeating what others have said - I'd much rather see authorization work being brought in from something like IdentityServer4 than implemented afresh by yourselves. If there are gaps then surely bridging those through contributions, samples, and refining integration points would be a better way to go. Perhaps also pay some attention to your cloud offering in this space (B2C) which is in an appalling state. Beyond that while you state the aim is not to replicate the functionality in existing open source offerings and to keep things simple this is somewhat equivalent to the classic rewrite trap: "this solution is over-complex, and a bit messy, lets rewrite it!". It's naive and in n versions time I would put money on you having dealt with the many edge cases that real world solutions require and that something like IdentityServer is already dealing with. More broadly, with the acquisition of GitHub, there's been a lot of discussion recently around Microsoft's attitude towards open source. It's great that Microsoft are doing so much work in the open but part of being a good open source citizen is leveraging existing open source when it exists. This is particularly important for platform holders such as yourselves - a platform holder duplicating functionality in existing open source offerings discourages contributions while engaging with those offerings encourages contributions. |
I too can't see the point of effort being expended on authorisation, but would like to see the management of ASP.NET Core Identity improved. Damian Edwards was quite clear on live.asp.net that we shouldn't roll-our-own security but - unless I've missed it - ASP.NET Core Identity does not contain any user management tools and so we do have to roll our own. This I find a bit terrifying as I'm not a security expert and am mortally afraid of leaving a security hole of my own making. |
How about moving content Formatters from MVC level to AspNetCore.Http abstractions in 2.2? |
Maybe the PM responsible could write up a more detailed description of this Identity Server Lite to make clear exactly what shortcomings in the existing third party open source solutions the ASP.NET team are looking to address. Because as it stands, you're talking about reinventing a wheel but maybe removing some spokes, and that doesn't make much sense. As somebody else has said, fixing up AAD B2C and providing first-class integration with that would be great, and make business sense for MS. Also, have you even considered how difficult it's going to be to get a new, ground-up Auth server product past @blowdart? |
Any plans to have a built-in RESTful API support like the one django has ? I built recently something that could be written as a Generic RESTful API controller: |
Also agree with "I fail to see how you can make security work as "zero config" any more than they can" and "you're talking about reinventing a wheel but maybe removing some spokes", identity server is an awesome product, very simple to get started with and provides extensibilty for more complicated scenarios, not sure why we require a "simplified" version. On a much much smaller scale, why do we need another health check implementation. There are already several open source solutions e.g.
What will be the feature difference with these and what's provided in 2.2? |
@0xRumple The improvements to the ApiController should help make this less verbose in general. But no, you probably won’t see something that just gives you a CRUD API for your entities by default. Such a thing would have to make far too many assumptions about your DAL and authorization. If you follow certain patterns in your application, there’s nothing wrong with creating your own base types or conventions in 2.2 that will generalize the work for you. |
Since you asked about whether it could be a bad thing: The ASP.NET team is relatively small too, serving millions of developers with limited capacity, so any new project will take away time and effort from other things. It means we all have to wait longer to get any brand new features that would probably deliver more value. Much worse is that it hurts the 3rd-party ecosystem and discourages new products because of Microsoft releasing an "official" package, which many companies get stuck choosing just because it's from Microsoft even if it's technically (and in this case supposed to be) less capable. ASP.NET already integrates Json.NET, Polly, AutoMapper, and many other libraries so it seems like a misstep to rebuild such a complex security product (which will need 80% of the same base code) when great options already exist, and with so many more interesting things on the roadmap to work on. |
@poke Actually I believe those aren't within the framework responsibilities:
But there are many things I thought the AspNetCore could've done better (by having a AspNetCore.RestFramework package):
I know there are tons of libraries out there, I found some here: https://github.com/thangchung/awesome-dotnet-core... But, 3rd party libraries aren't really a good option for the enterprise apps ! Same goes to the sieve, if there is an OFFICIAL package for pagination, filtering... etc, developers won't tend to write buggy or non-maintained libraries, I used this sieve in my app I mentioned above: https://github.com/Biarity/Sieve, but this library can go non-maintained any second the author got busy. I think AspNetCore is mature enough to start thinking about out-of-the-box solutions as in django, this way we can have the luxury of asp performance and the agility of django. |
https://github.com/IdentityManager/IdentityManager2 |
This UI thing can be tricky, albeit helpful to get basic things quickly. It seem recently I've come across cases building the UI isn't the biggest task, but figuring out how to fullfil the "process needs" such as pre-approving some emails (that do something application specific), calling APIs that call APIs, some of which might mean joins in the database or calls to somewhere else etc. and then adding them to tokens and UI logic. So having good tutorials such as https://mcguirev10.com/2018/01/28/login-identity-management-best-practices.html or those at https://mcguirev10.com/page2/ feels more important than UI (especially if one can't or doesn't want to use EF). Then maybe search for UI for one's chosen tech (Aurelia/Angular/Razor/React/Vue etc.) and how they implement some data handling. On naming projects and names, besides @scottbrady91, I've found it very educating to check @LindaLawton, https://github.com/abergs/fido2-net-lib (@abergs, @aseigler), @TomCJones, @mackie1001 (Gitter) etc. to provide additional explanations and code to peek into when stepping even a bit outside of the basic need. I've forgot to add some names and projects. :) |
Why cant .net core have normal razor web pages? When I do complex reports I like doing all from a single razor (c#) page. Or at least the ability to use just a view at times only with no model or controller. In other words the basic ability to connect to sql in the view and receive GET and POST request, sanitized of course, I currently use a class called Striptag.cs. |
You can use Razor pages for this https://docs.microsoft.com/en-us/aspnet/core/razor-pages/?view=aspnetcore-2.1&tabs=visual-studio Having a backing page model class is optional; you can just have a single page |
benaadams thanks for the answer, how would I use GET and POST request directly in a razor page, and make a basic connection to sql server. The connection for regular queries, not ado entities, or linq, or ORM. I always prefer normal queries. Like:
I know the connection string is in a json file now, but don't know how to use it in view. Some things aren't deeply documented. |
Well, it has a learning curve. If you want to fetch data before loading the view, you do it in the corresponding action. So, for public class HomeController
{
public ActionResult ViewReports()
{
// fetch data from the SQL using...something...
return View(data);
}
} If you want to fetch data after page load, you typically use AJAX requests to some pure GET/POST endpoint that returns JSON formatted data. |
Can still do it on a page without any controller or action; something like @page
@using System.Data.SqlClient
@using Microsoft.AspNetCore.Http
@using Microsoft.Extensions.Configuration
@inject 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 @lastname
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>
}
} |
I have used mvc asp.net and webforms and old razor pages, so I am not new to this. I have spent 3 hours and still cannot get a simple test razor page to work, I have:
Just an html page and loads. Model
View:
3 hours and all I get is a blank page. I tried a return statement, etc If I just type in http://localhost:51307/pets/razdb3 I get the second divisions "hello", but I am new to .net core, and would have never imagined it would or could be so hard to simple display a razor page. In VS community 2017 |
You set the In the GET request ( Try setting it to a default value so it shows up when you don't set it to confirm the model is flowing through:
|
Changed to
And still a blank page. Is @Model.myvar correct? even changed to
It builds fine no error, but a blank page no matter what I try. |
Sorry, I realize I should have used the forum. Thank you @benaadams your code got me on the right track and I found this: https://www.c-sharpcorner.com/article/razor-page-web-application-with-asp-net-core-using-ado-net/ This is how I normally did stuff anyway, using the "new" key word, like
It was reassuring to see you could still use custom classes in .net core. You have to admit, .net core has a steeper learning curve than some prior asp.net frameworks. Thanks so much. |
The release notes talk about an "Authorization Server" feature to be expected as add-on in the upcoming months. Is there more information available about this feature? I'm trying to decide whether we should wait for it. Or build our own solution. |
I think the current plan is to use https://github.com/IdentityServer/IdentityServer4 in a "pre-packaged" way. |
Following the notes from IS4 team and MS security team, it seemed like MS was simply trying to do a quick & dirty packaging of IS4 and call it the day. But looks like someone with more wisdom, decided to hold back and do it the right way, as security can create ripple effects when it is not done right. I hope a full integration between IS4 and ASP is made to support BOTH Web API and MVC. |
In these days and industrial strength authentication/authorization is required as a bare minimum. Open Source (OSS) is fine for most things but there have been serious misgivings in some OSS security products that are not acceptable in any enterprise website. 85% of projects use outdated libraries that are unacceptable security risk. For example, 45% web servers use Apache (https://www.cvedetails.com/vendor/45/Apache.html) which has far more vulnerabilities than IIS (https://www.cvedetails.com/product/3436/Microsoft-IIS.html?vendor_id=26). Products such as Identity Server may be fine but developer tweaks may render them completely insecure. We need a solution built into Net Core that is always safe... |
Your point is absolutely correct. But in some videos, MS staff had said, that they're not going to reinvent the [security] wheels and use a third party [IS4] system. So I'm hoping this will be a win/win situation for all of us. |
Nothing is "always safe", especially not something from Microsoft ;) |
IdentityServer will be included in new templates shipping post 2.2. The initial focus will be API access control - but there are plans to expand that in the future. ASP.NET Core will ship with a simplified config API that covers the template scenarios only - but will be very easy to get started. You can at any point transition to the IS native config system which gives you advanced scenarios. |
Thanks for the information Dominick; |
Good to know! Thank you. I guess this API access control will be based on OAuth scopes? |
PolicyServer is commercial solution |
"Only" IdentityServer. ASP.NET Core has a built-in API for user authorization - and if PolicyServer (the product) looks interesting to you, let me know. |
Closing this issue because ASP.NET Core 2.2 has shipped. |
should this not be updated to ASP 3.0 |
Any update on when the Authorization Server enhancements will ship? |
Discussion for the 2.2 Roadmap announcement: aspnet/Announcements#307
The text was updated successfully, but these errors were encountered: