在前后端分离、Restful API盛行的年代,完美的接口文档,成了交流的纽带。在项目中引入Swagger (也称为OpenAPI),是种不错的选择,它可以让接口数据可视化。下文将会演示
本系列文章,主要分享一些.NET Core比较优秀的社区资料和微软官方资料。我进行了知识点归类,让大家可以更清晰的学习.NET Core。
前面为了方便我们只是简单实现了基本业务功能的增删改查,但是登录功能还没有实现,而登录又是系统所必须的,得益于 ASP.NET Core的可扩展性因此我们很容易实现我们的登录功能。今天我将带着大家一起来实现下我们的ASP.NET Core2.2开发的CMS系统的登录及验证码功能。如果你觉得文中有任何不妥的地方还请留言或者加入DotNetCore实战千人交流群637326624跟大伙进行交流讨论吧!
这两天比较忙,周末也在加班,所以更新的就慢了一点,不过没关系,今天我们就进行千呼万唤的系统开发框架的设计。不知道上篇关于架构设计的文章大家有没有阅读,如果阅读后相信一定对架构设计有了更近一部的理解,如果你没有阅读也希望大家能好好阅读一下!其实说白了,架构是为了应对软件系统复杂度而提出的一个解决方案,架构设计的最终目的也就是为了让复杂的问题简单化!今天我们就结合架构设计的思想来进行我们的CMS实战项目的架构设计,接着再设计下开发框架吧。
趁着假期的时间所以想重新学习下微软的官方文档来巩固下基础知识。我们都知道微软目前已经发布了.NET Core3.0的第三个预览版,同时我家里的电脑也安装了vs2019。So,就用vs2019+.NET Core3.0来跟着做一下Contoso University这个WEB应用,但是在基于3.0进行操作的时候遇到了一些问题,所以我就查看了微软的《从 ASP.NET Core 迁移 2.2 到 3.0 预览版 2》这篇文档,就着今天遇到的问题,所以我整理下,希望对大伙有所帮助,当然大伙也可以直接阅读微软的官方文档进行查看。但是我在阅读官方说明的时候,总感觉翻译的不是很准确,读起来很拗口,所以这里我是自己的理解对官方文档的一个补充。
这些示例不由IdentityServer团队维护。 IdentityServer团队提供链接到了社区示例,但不能对示例做任何保证。 如有问题,请直接与作者联系。 各种ASP.NET Core安全示例 https://github.com/leastprivilege/AspNetCoreSecuritySamples IdentityServer4 EF 和 ASP.NET Identity ASP.NET Identity:https://github.com/IdentityServer/Identit
端点路由(Endpoint Routing)最早出现在ASP.NET Core2.2,在ASP.NET Core3.0提升为一等公民。
很多.net项目在开发的时候,.net core还没有出现或者还么有成熟,如今.netcore3.1已经出现,其技术风险已经比较低,今天对项目如何迁移到.net core做一个简单的梳理,瑾做参考。
手动管理依赖关系注入过于繁琐。当存在多个无法统一注入的存储库和服务时,Scrutor 可以帮助我们简化 ASP.NET Core 的DI注册。
我们很高兴地宣布发布.NET Core 2.2。它包括对运行时的诊断改进,对ARM32 for Windows和Azure Active Directory for SQL Client的支持。此版本中最大的改进是在ASP.NET Core中。
将 Swagger 生成器添加到 Startup.ConfigureServices 方法中的服务集合中:
耗时两个多月,坚持写这个入门系列文章,就是想给后来者更好更快的上手体验,这个系列可以说是从入门到进阶,适合没有 .NETCore 编程经验到小白同学,也适合从 .NET Framework 迁移到 .NETCore 的朋友。
那么,如何使用 C# 的 HttpClient 访问一个 JWT 认证的 WebAPI 呢?
KestrelServer最大的优势体现在它的跨平台的能力,如果ASP.NET CORE应用只需要部署在Windows环境下,IIS也是不错的选择。ASP.NET CORE应用针对IIS具有两种部署模式,它们都依赖于一个IIS针对ASP.NET CORE Core的扩展模块。本文提供的示例演示已经同步到《ASP.NET Core 6框架揭秘-实例演示版》)
本文主要翻译自Security Code Scan的官方Github文档,结合自己的初步使用简单介绍一下这款工具,大家可以结合自己团队的情况参考使用。此外,对.NET Core开发团队来说,可以参考张队的《.NET Core 必备安全措施》看看可以使用哪些方法提高我们.NET Core应用程序的安全性,此文也算是对张队的那篇文章的一个补充。此外,本文不会介绍常见的Web攻击及其场景,有兴趣的园友可以读读参考书《白帽子讲Web安全》一书。
全文翻译自微软官方文档英文版 What's new in ASP.NET Core 3.0
在现实网络中即存在着安全的流量,又存在着不安全的流量在,这些不安全的流量常常会对我们的网站服务造成威胁,严重的甚至会泄露用户的隐私信息。这篇文章我们通过对常见的网络攻击跨站脚本攻击、跨站请求伪造(CSRF)、SQL注入、敏感数据泄露、身份验证与授权防范 方面讲解如何防范网络攻击。
后台框架:.Net Core 3.1 + EF Core yrjw.ORM.Chimp
我很高兴地宣布ASP.NET Core 2.2现在作为.NET Core 2.2的一部分提供!
本文为翻译,原文地址:https://blogs.msdn.microsoft.com/webdev/2018/12/04/asp-net-core-2-2-available-today/
用户认证在网络安全中起着至关重要的作用。首先,它可以确保只有经过授权的用户才能访问特定的资源或服务,从而保护了系统和数据的安全。其次,用户认证可以帮助追踪和记录用户的活动,如果出现安全问题,可以追踪到具体的用户。此外,用户认证还可以实现个性化服务,根据用户的身份提供定制化的内容或服务。因此,用户认证对于任何需要保护数据安全或提供个性化服务的系统来说都是必不可少的。
通过 ASP.NET Core,开发者可轻松配置和管理其应用的安全性。 ASP.NET Core 中包含管理身份验证、授权、数据保护、SSL 强制、应用机密、请求防伪保护及 CORS 管理等等安全方面的处理。 通过这些安全功能,可以生成安全可靠的 ASP.NET Core 应用。而我们这一章就来说道说道如何在ASP.NET Core中处理“跨站请求伪造(XSRF/CSRF)攻击”的,希望对大家有所帮助
在上一篇的文章中,主要是搭建了我们的开发环境,同时创建了我们的项目模板框架。在整个前后端分离的项目中,后端的 API 接口至关重要,它是前端与后端之间进行沟通的媒介,如何构建一个 “好用” 的 API 接口,是需要我们后端人员好好思考的。 在系统迭代的整个过程中,不可避免的会添加新的资源,或是修改现有的资源,后端接口作为暴露给外界的服务,变动的越小,对服务的使用方造成的印象就越小,因此,如何对我们的 API 接口进行合适的版本控制,我们势必需要首先考虑。
通常,服务所公开的资源和 API 必须仅限受信任的特定用户和客户端访问。那进行 API 级别信任决策的第一步就是身份认证——确定用户身份是否可靠。
我们很高兴地宣布.NET Core 2.2版本。它包括对运行时诊断的改进、对 Windows 的 ARM32 和 SQL 客户端的 Azure Active Directory 的支持。此版本中最大的改进是 ASP.NET Core。
我在 B 站的视频是基于.NET Core 2.2 提供的案例,在书籍中提供的是.NET Core 3.1 的案例。有人问,默认进程到底是进程外还是进程内。
在.NET8 新的 Web API 项目模板中增加一个新的文件,该文件以“项目名.http”命名。这个文件是 Visual Studio 2022 版本的 17.6 以后提供的一个新功能,一种便捷的方式来测试 ASP.NET Core项目,尤其是 API 应用。并且带有一个UI界面,类似于单元测试。
在ASP.NET Core中,Identity是一个用于处理用户身份验证和授权的框架。它包含了一系列组件,用于管理用户、角色、声明等身份相关的功能。以下是ASP.NET Core Identity的主要组成部分:
在进行 Web 项目开发的过程中,可能会存在一些需要经常访问的静态数据,针对这种在程序运行过程中可能几乎不会发生变化的数据,我们可以尝试在程序运行前写入到缓存中,这样在系统后续使用时就可以直接从缓存中进行获取,从而减缓因为频繁读取这些静态数据造成的应用数据库服务器的巨大承载压力。
简单整理了 ASP.NET Core 从1.0到5.0的变迁,不包括小版本, 内容主要来自 MS Docs。
ASP.NET 5 的路线图(详见 ASP.NET 5 Schedule and Roadmap : https://github.com/aspnet/home/wiki/roadmap ):Beta8版本在10月15日发布了,在微软的.NET Web开发工具博客上发布了详细的说明文章:http://blogs.msdn.com/b/webdev/archive/2015/10/15/announcing-availability-of-asp-net-5-beta8.aspx 。 ASP.NET 5
在本篇博客中,我将描述与之前版本相比,ASP.NET Core 3.0 中已经被标记为废弃的类型。我将解释一下为什么这些类型被废弃了,它们的替换类型是什么,以及你应该什么时候使用它们。
集成Entity Framework Core(EF Core)是在ASP.NET Core Web API中进行数据库访问的常见方式。以下是集成EF Core的基本步骤:
通过《服务承载系统[2]: 承载长时间运行的服务[下篇]》的介绍可知,IHostBuilder接口中定义了ConfigureHostConfiguration方法和ConfigureAppConfiguration方法,它们可以帮助我们设置面向宿主(IHost对象)和应用(承载服务)的配置。针对配置的初始化也可以借助IWebHostBuilder接口来完成。[本文节选自《ASP.NET Core 3框架揭秘》第11章, 更多关于ASP.NET Core的文章请点这里]
P5第2段 原文:由于创建的是一个针对 ASP.NET Core 的可执行控制台应用,所以将 OutputType 和 TargetFramework 的属性分别设置为“Exe”和“net6.0”。 改为:由于创建的是一个针对 .NET 6的可执行控制台应用,所以将 OutputType 和 TargetFramework 的属性分别设置为“Exe”和“net6.0”。 P7第2段 原文:由于创建的是 ASP.NET Core 的应用程序,所以最终生成的程序集被保存在“\bin\Debug\net6.0\
摘要 通过本文你将了解ASP.NET身份验证机制,表单认证的基本流程,ASP.NET Membership的一些弊端以及ASP.NET Identity的主要优势。 目录 身份验证(Authentication)和授权(Authorization) ASP.NET身份验证方式 理解表单验证流程 认识ASP.NET Membership 拥抱ASP.NET Identity ASP.NET Identity主要组成部分 总结 身份验证(Authentication)和授权(Authorization) 我们先
作为ASP.NET CORE请求处理管道的“龙头”的服务器负责监听和接收请求并最终完成对请求的响应。它将原始的请求上下文描述为相应的特性(Feature),并以此将HttpContext上下文创建出来,中间件针对HttpContext上下文的所有操作将借助于这些特性转移到原始的请求上下文上。除了我们最常用的Kestrel服务器,ASP.NET CORE还提供了其他类型的服务器。
ASP.NET Core应用本质上就是一个由中间件构成的管道,承载系统将应用承载于一个托管进程中运行起来,其核心任务就是将这个管道构建起来。从设计模式的角度来讲,“管道”是构建者(Builder)模式最典型的应用场景,所以ASP.NET Core先后采用的三种承载方式都是采用这种模式。(本篇提供的实例已经汇总到《ASP.NET Core 6框架揭秘-实例演示版》)
提到“配置”二字,我想绝大部分.NET开发人员脑海中会立即浮现出两个特殊文件的身影,那就是我们再熟悉不过的app.config和web.config,多年以来我们已经习惯了将结构化的配置定义在这两个XML格式的文件之中。到了.NET Core的时代,很多我们习以为常的东西都发生了改变,其中就包括定义配置的方式。总的来说,新的配置系统显得更加轻量级,并且具有更好的扩展性,其最大的特点就是支持多样化的数据源。我们可以采用内存的变量作为配置的数据源,也可以将配置定义在持久化的文件甚至数据库中。在对配置系统进行系统介绍之前,我们先从编程的角度来体验一下全新的配置读取方式。
我们直接利用Visual Studio 打开前面这个helloworld.csproj项目文件。为了能够使用ASP.NET Core 框架提供的程序集,我们可以通过修改项目文件(.csproj)添加针对“Microsoft.AspNetCore.App”的框架引用(FrameworkReference)。在Visual Studio中修改项目文件非常方便,我们只需要右键选择目标项目,并从弹出的菜单中选择“Edit Project File”就可以了。如下所示的是修改后的项目文件,针对“Microsoft.AspNetCore.App”的框架引用被添加到<ItemGroup/>节点下。
在上一篇文章介绍ASP.NET Core Authentication的三个重要概念,分别是Claim, ClaimsIdentity, ClaimsPrincipal,以及claims-base authentication是怎么工作的。
ASP.NET Core应用本质上就是一个由中间件构成的管道,承载系统将应用承载于一个托管进程中运行起来,其核心任务就是将这个管道构建起来。在ASP.NET Core的发展历史上先后出现了三种应用承载的编程方式,而且后一种编程模式都提供了针对之前编程模式的全部或者部分兼容,这就导致了一种现象:相同的更能具有N种实现方式。对这个发展历程不是特别了解的读者会有很多疑问?为什么这么多不同的编程模式都在作同一件事?它们之间的有什么差别之处?为什么有的API在最新的Minimal API又不能用了呢?[本文部分内容来源于《ASP.NET Core 6框架揭秘》第15章]
.NET Core大大简化了.NET应用程序的开发。它的自动配置和启动依赖大大减少了开始一个应用所需的代码和配置量,本文目的是介绍如何创建更安全的.NET Core应用程序。
包和构建 IdentityServer有许多nuget包 IdentityServer4 nuget | github 包含IdentityServer核心对象模型,服务和中间件。 仅支持内存配置和用户存储,但您可以通过插件配置对其他存储的支持。 Quickstart UI github 包含一个简单的启动界面包括登录、注销和同意页。 Access token validation middleware nuget | github 用于在API中验证令牌的ASP.NET Core 中间件。 提供验证访问
作为《ASP.NET Core 3框架揭秘》的升级版,《ASP.NET Core 6框架揭秘》提供了很多新的章节,同时对现有的内容进行大量的修改。虽然本书旨在对ASP.NET Core框架的架构设计和实现原理进行剖析,但是其中提供的258个实例演示却可以作为入门材料,这个系列会将这些演示实例单独提取出来并进行汇总。对于想学习ASP.NET Core的同学,如果你觉得没有必要“钻的这么深”,倒是可以看看。本篇提供的20个简单的演示实例基本涵盖了ASP.NET Core 6基本的编程模式,我们不仅会利用它们来演示针对控制台、API、MVC、gRPC应用的构建与编程,还会演示Dapr在.NET 6中的应用。除此之外,这20个实例还涵盖了针对依赖注入、配置选项、日志记录的应用。(本篇提供的实例已经汇总到《ASP.NET Core 6框架揭秘-实例演示版》)
Azure SignalR 服务是一种完全托管的用于实时消息传递的 Azure 服务。它是扩展 ASP.NET Core SignalR 应用程序的首选方法。但是,SignalR 服务是用 ASP.NET Core 2.0 的 SignalR 上构建的,它与 ASP.NET SignalR 不是100% 兼容。要使 ASP.NET SignalR 应用程序使用 SignalR 服务,需要更改代码。服务 SDK 还需要专门添加 ASP.NET 支持。
.NET Core 3.0将会在 .NET Conf 大会上正式发布,截止今日发布了9个预览版,改动也是不少,由于没有持续关注,今天将前面开源的动态WebApi项目迁移到.NET Core 3.0还花了不少时间踩坑,给大家分享一下我在迁移过程中遇到的坑。迁移的版本是当前Release最新版本 .NET Core 2.2 到 .NET Core 3.0 Preview 9。
对于一个 .NET Core开发人员,你可能没有使用过Docker,但是你不可能没有听说过Docker。Docker是Github上最受欢迎的开源项目之一,它号称要成为所有云应用的基石,并把互联网升级到下一代。Docker是dotCloud公司开源的一款产品,从其诞生那一刻算起,在短短两三年时间里就成为了开源社区最火爆的项目。对于完全拥抱开源的.NET Core来说,它自然应该对Docker提供完美的支持。对于接下来的内容,我们假设你已经对Docker有了基本的了解,并且在你的机器上(Windows)上已经安装了Docker。
如果您使用过以前版本的ASP.NET,那么您可能对此文件非常熟悉,但此文件中包含的格式和内容在asp.ne Core 中发生了很大变化。
领取专属 10元无门槛券
手把手带您无忧上云