一,简介 Signal 是微软支持的一个运行在 Dot NET 平台上的 html websocket 框架。它出现的主要目的是实现服务器主动推送(Push)消息到客户端页面,这样客户端就不必重新发送请求或使用轮询技术来获取消息。 可访问其官方网站:https://github.com/SignalR/ 获取更多资讯。 二,实现机制 SignalR 的实现机制与 .NET WCF 或 Remoting 是相似的,都是使用远程代理来实现。在具体使用上,有两种不同目的的接口:PersistentConnection 和 Hubs,其中 PersistentConnection 是实现了长时间的 Javascript 轮询(类似于 Comet),Hub 是用来解决实时信息交换问题,它是利用 Javascript 动态载入执行方法实现的。SignalR 将整个连接,信息交换过程封装得非常漂亮,客户端与服务器端全部使用 JSON 来交换数据。 下面就 Hubs 接口的使用来讲讲整个流程: 1,在服务器端定义对应的 hub class; 2,在客户端定义 hub class 所对应的 proxy 类; 3,在客户端与服务器端建立连接(connection); 4,然后客户端就可以调用 proxy 对象的方法来调用服务器端的方法,也就是发送 request 给服务器端; 5,服务器端接收到 request 之后,可以针对某个/组客户端或所有客户端(广播)发送消息。 三,Hub 示例教程 1,工具准备 SignalR 运行在 .NET 4.5 平台上,所以需要安装 .NET 4.5。为了方便演示,本示例使用 ASP.NET MVC 在 Win 7 系统来实现。这需要安装 ASP.NET MVC 3 或 ASP.NET MVC 4。 2,建立工程 打开 VS2010/VS2012 新建名为 SignalRTutorial 的 ASP.NET MVC 3 Web Application 工程,选择 Internet Application 模板, Razor […]
View DetailsASP.NET SignalR 是为 ASP.NET 开发人员提供的一个库,可以简化开发人员将实时 Web 功能添加到应用程序的过程。实时 Web 功能是指这样一种功能:当所连接的客户端变得可用时服务器代码可以立即向其推送内容,而不是让服务器等待客户端请求新的数据。 ASP .NET SignalR 是一个ASP .NET 下的类库,可以在ASP .NET 的Web项目中实现实时通信。什么是实时通信的Web呢?就是让客户端(Web页面)和服务器端可以互相通知消息及调用方法,当然这是实时操作的。 WebSockets是HTML5提供的新的API,可以在Web网页与服务器端间建立Socket连接,当WebSockets可用时(即浏览器支持Html5)SignalR使用WebSockets,当不支持时SignalR将使用其它技术来保证达到相同效果。 SignalR当然也提供了非常简单易用的高阶API,使服务器端可以单个或批量调用客户端上的JavaScript函数,并且非常 方便地进行连接管理,例如客户端连接到服务器端,或断开连接,客户端分组,以及客户端授权,使用SignalR都非常 容易实现。 SignalR 将与客户端进行实时通信带给了ASP .NET 。当然这样既好用,而且也有足够的扩展性。以前用户需要刷新页面或使用Ajax轮询才能实现的实时显示数据,现在只要使用SignalR,就可以简单实现了。 最重要的是您无需重新建立项目,使用现有ASP .NET项目即可无缝使用SignalR。
View DetailsWeb API入门指南有些朋友回复问了些安全方面的问题,安全方面可以写的东西实在太多了,这里尽量围绕着Web API的安全性来展开,介绍一些安全的基本概念,常见安全隐患、相关的防御技巧以及Web API提供的安全机制。 目录 Web API 安全概览 安全隐患 1. 注入(Injection) 2. 无效认证和Session管理方式(Broken Authentication and Session Management) 3. 跨站脚本(Cross-Site Scripting (XSS)) 4. 直接引用非安全对象(Insecure Direct Object References) 5. 错误的安全配置(Security Misconfiguration) 6. 暴露敏感数据(Sensitive Data Exposure) 7. 功能级权限控制缺失(Missing Function Level Access Control) 8. 伪造跨站请求(Cross-Site Request Forgery) 9. 使用已知安全隐患组件(Using Components with Known Vulnerabilities) 10. 未验证跳转(Unvalidated Redirects and Forwards) Web API安全机制 认证与授权(Authentication and Authorization) 伪造跨站请求(Cross-Site Request Forgery Attacks) 安全链接(SSL) 跨域请求(Cross-Origin Requests) Web API 安全概览 先引用下wikipedia信息安全的定义:即保护信息免受未经授权的进入、使用、披露、破坏、修改、检视、记录及销毁,从而保证数据的机密性(Confidentiality)、完整性(Integrity)和可靠性(Availability)。 机密性和完整性都很好理解,可靠性作为信息安全的一个重要原则这里特别解释一下,即访问信息的时候保证可以访问的到,有一种攻击方式叫DOS/DDOS,即拒绝服务攻击,专门破坏网站的可用性。 Information security, sometimes shortened to InfoSec, is the practice of defending information from unauthorized access, use, disclosure, disruption, modification, perusal, […]
View DetailsWeb API是一个比较宽泛的概念。这里我们提到Web API特指ASP.NET Web API。 这篇文章中我们主要介绍Web API的主要功能以及与其他同类型框架的对比,最后通过一些相对复杂的实例展示如何通过Web API构建http服务,同时也展示了Visual Studio构建.net项目的各种强大。 目录 什么是 Web API 为什么要用 Web API 功能简介 Web API vs MVC Web API vs WCF Web API 实战 (Web API + MongoDB + knockoutjs) 涉及技术 服务URI Pattern 准备工作 代码实现 什么是 Web API 官方定义如下,强调两个关键点,即可以对接各种客户端(浏览器,移动设备),构建http服务的框架。 ASP.NET Web API is a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework. Web API在ASP.NET完整框架中地位如下图,与SignalR一起同为构建Service的框架。Web API负责构建http常规服务,而SignalR主要负责的是构建实时服务,例如股票,聊天室,在线游戏等实时性要求比较高的服务。 为什么要用 Web API Web API最重要的是可以构建面向各种客户端的服务。另外与WCF REST […]
View Details在实际的项目应用中,很多时候都需要保证数据的安全和可靠,如何来保证数据的安全呢?做法有很多,最常见的就是进行身份验证。验证通过,根据验证过的身份给与对应访问权限。同在Web Api中如何实现身份认证呢?接下来的内容就详细的分享 Web API身份认证。 首先扩展自定义身份验证 添加类 CustomAuthorizeAttribute.cs 该类继承自System.Web.Http.AuthorizeAttribute(身份认证类)通过重写其身份认证核心方法来达到 web API 身份认证的效果。 完整代码: public class CustomAuthorizeAttribute : System.Web.Http.AuthorizeAttribute { public override void OnAuthorization(System.Web.Http.Controllers.HttpActionContext actionContext) { //判断用户是否登录 if(!HttpContext.Current.User.Identity.IsAuthenticated) HandleUnauthorizedRequest(actionContext); } protected override void HandleUnauthorizedRequest(System.Web.Http.Controllers.HttpActionContext actionContext) { var challengeMessage = new System.Net.Http.HttpResponseMessage(System.Net.HttpStatusCode.Unauthorized); challengeMessage.Headers.Add("WWW-Authenticate", "Basic"); throw new System.Web.Http.HttpResponseException(challengeMessage); } } 增加身份认证(必须登录后才能进行查询等操作)在Controller上加上属性,可以直接通过VS快捷键感应出来 完整代码 PS:写在controller类上是表示这个controller的每个action都受身份认证,如果想为某一个action制定 可以直接写在action上,就不要写在类上了。 接下来编写登录方法 public ActionResult Login() { return View(); } [HttpPost] public ActionResult Login(FormCollection fol) { ///此处为了演示简化登录过程 ///可以在此处扩展验证用户名或者密码是否正确 System.Web.Security.FormsAuthentication.SetAuthCookie(fol["username"], false); return Redirect("/HTMLPage5.htm"); } 有了后台的方法,就剩下最后的前段页面了 通过在Login的方法中右键可以快速生成页面(vs给我们带来的提高效率的工具,就不多做介绍了) 在生成的Login.cshtml中编写以下登录代码 @using (Html.BeginForm()) { <fieldset> <label>账号:</label><input type="text" name="username" /><br /> <label>密码:</label><input type="text" name="password" /><br /> <input type="submit" value="登录" /> </fieldset> } 这个时候还需要有两个小地方做配置. 第一个就是web.config 配置form认证 <authentication mode="Forms"> <forms loginUrl="~/home/Login" timeout="2880" /> </authentication> 第二个就是修改HTMLPage5.html的js(HTMLPage5.html可以直接复制HTMLPage4.html) 将这段获取数据的代码修改为带验证身份进行跳转的 原JS $.get('/api/userInfo', function (data) { // 从API中 // 得到返回的数据,更新 Knockout 模型并且绑定到页面UI模板中 viewModel.userinfos(data); }); 修改后的js $.ajax({ url: '/api/userinfo', type: 'GET', contentType: 'application/json; charset=utf-8', statusCode: { 200 /*Created*/: function (data) { viewModel.userinfos(data) }, 401: function (jqXHR, textStatus, errorThrown) { window.location.href = '/home/login'; } } }); Ok 到此,代码就已近编写完成了,来进行测试 测试第一步直接访问 /api/userinfo […]
View Details在和银行做数据对接时,涉及到数据传输时的验签及加密。其中数据签名方案中就要求数据项根据属性名按 ASCII码 进行升序排序。C#中的ASCII码排序并不是表面上那么简单,一不小心就入坑了。因为C#的排序默认并不是按照ASCII码进行排序的。举个例子, 我有这样一个字符串数组,然后对其排序。
1 2 3 |
string[] vv = { "1", "2", "A", "a", "B", "b" }; Array.Sort(vv); //结果 1 2 a A b B |
如果是按照ASCII码进行排序的话,顺序应该是: 1, 2, A, B, a, b 而实际排序后的结果则是:1, 2, a, A, b, B . 这也就是说Sort()方法默认情况下并不是按ASCII码进行排序的。之后我也同样测试了C#中的OrderBy()的排序,发现它默认情况下也并不是按照ASCII码进行的排序。
1 2 3 |
string[] vv = { "1", "2", "A", "a", "B", "b" }; vv.OrderBy(x => x); //结果 1 2 a A b B |
那么既然默认排序不是按ASCII码进行的排序,我们要怎么做呢? 看下面代码,只需要在原来排序方法上再加个参数: string.CompareOrdinal。string.CompareOrdinal会把每个字符先转成相应的数值(如 a 转为数值 97),然后再对数值进行比较。
1 |
Array.Sort(vv, string.CompareOrdinal); //ASCII排序 |
注:掉入这个坑是因为起初不知道如何对字符做ASCII码排序,于是百度了一把。得到的结果就是这个 C# 参数按照ASCII码从小到大排序(字典序) 而当我采用这种方式时,银行验签那步始终通不过,调试发现我排序后的结果和银行那边的不同。这篇博文的博主可能自己也没发现这个坑吧。 from:http://www.cnblogs.com/similar/p/6739293.html
View Details前言 今天给大家介绍一下在 ASP.NET Core 日常开发中用的比较多的两个中间件,它们都是出自于微软的 ASP.NET 团队,他们分别是 Microsoft.AspNetCore.ResponseCompression 和 Microsoft.AspNetCore.ResponseCaching , 下面让我们一起看看的功能以及如何去使用吧。 Getting Started Microsoft.AspNetCore.ResponseCompression Microsoft.AspNetCore.ResponseCompression 这个中间件是 .NET Core 1.1 版本中新增加的,看名字应该知道,它主要是负责对输出的内容进行压缩, 那么在我们WEB开发中主要就是 GZip 压缩了。 Gzip 压缩是我们在 WEB 中经常会使用的一项性能优化技术,它可以对页面输出的内容使用压缩算法(GZip)进行体积的压缩, 那在以前的时候,我们可以使用 IIS 来做这项工作,但是现在我们的程序脱离 IIS了,就必须有一个中间件来帮我们做这件事情了,它就是我们要介绍的这个中间件。 1、添加 Microsoft.AspNetCore.ResponseCompression 包 你可以使用 Visual Studio 打开 NuGet 包管理器控制台输入一下命令安装
1 |
Install-Package Microsoft.AspNetCore.ResponseCompression |
也可以使用 NuGet包管理器UI界面安装。 添加完成之后,你就可以在 project.json 中看到你添加的包了。注意目前版本是 1.0.0. 2、更新 Startup.cs 文件 修改 Startup , 在ConfigureServices 和Configure 两个方法中添加如下代码:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
public class Startup { ... public void ConfigureServices(IServiceCollection services) { services.AddResponseCompression(); ... } public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory) { app.UseResponseCompression(); ... } } |
现在你就可以测试一下输入的 Http Response 是否被压缩了。 前: 后: 通过 前 后 对比,可以看出来,在 Response Headers 里面多了一个 Content-Encoding:gzip 的头部信息,说明我们的中间件生效了。 Microsoft.AspNetCore.ResponseCaching Microsoft.AspNetCore.ResponseCaching 这个中间件也是 .NET Core 1.1 版本中新增加的,同样看名字应该知道,它主要是负责对输出的内容进行缓存设置。在以前我们可以同样在 IIS 中设置这些东西,但是粒度可能并没有这么细。 我之前写过一篇关于 ASP.NET Core 缓存的文章,里面介绍了 ASP.NET Core MVC 中的 Response 缓存,它是通过一个 ResponseCacheAttribute 来实现的设置缓存头信息:
1 2 3 4 |
[ResponseCache(VaryByHeader ="Accept-Encoding", Location = ResponseCacheLocation.Any, Duration = 10)] public IActionResult About() { } |
那,除了 MVC […]
View DetailsNPOI .NET Core 2.0 http://www.cnblogs.com/savorboard/p/dotnetcore-npoi.html 前言 最近项目中,需要使用到 Excel 导出,找了一圈发现没有适用于 .NET Core的,不依赖Office和操作系统限制的 Office 组件,于是萌生了把 NPOI 适配并移植到 .NET Core 的想法。 NPOI 的介绍不多说了,不了解的可以看一下 NPOI百度百科 的介绍,在此感谢瞿总和他的团队的贡献。 NPOI 的移植之路并非想象的那么容易,因为其依赖了 System.Drawing 和 System.Window.Forms 两个组件,还有一个第三方的 SharpZipLib 库,在 GitHub 克隆了最新的代码并且转换为 NetStandrad 1.6 编译之后,出现了数不清的错误,应该有上千个吧,在经过一天的努力之后(包括删除,修改,重写),错误数量已经减少到了100多个,50多个,20多个,编译通过。 在移植的过程中可以真切感受到当初NPOI的作者在写这些代码时候的辛苦努力,因为NPOI最初是基于 .Net Framework 1.1 框架写的,那个时候没有泛型,没有var,没有很多的现成的类库,全都是靠最基础的一些数据结构来实现,虽然里面的很多种写法在目前看来可以很大程序的精简,但是在当时的条件下 真的是不容易。 在通过编译之后,心里想着应该问题不大了,于是测试了一下,不幸的是,各种问题,又经过半天的调整之后,打算放弃了。 于是又去 github 上面搜索看看有没有其他什么解决方案之类的,无意间搜索到了一个 NPOI.Core 的一个项目,是一个老外移植的 NPOI 到Core平台,原来已经有人做了Core的移植了,克隆下来之后发现编译不过,又进去看了一下代码,这个库目前依赖于Windows平台,而我们项目是运行在CentOS的,其并不能在Linux上运行,看来还是空欢喜一场。 怎么办? 于是,又一次重构开始了,有了前一次的重构经验之后,这一次可谓是轻车熟路了,NPOI Core 库 里面使用了很多.NET Core netstandrad 标准不支持的 Hashtable 和 ArrayList 等数据结构,这些已经被新的泛型 Directory 和 List 替代了,还有依赖的 SharpZipLib 等压缩组件也都替换成了 NetStandrad 的实现,当然还有其他很多杂七杂八的就不细说了,最后,终于 netstandrad 1.6 下编译通过。 通过之后,本地 visual studio 下 新建了一个项目,简单测试了导出 Excel 的功能,没问题,也没有报错,心里很开心…。 这个时候我在想,最关键的就是能不能在Linux上正常运行了,其实这个时候我心里想我已经把依赖于.NET Framework 的各种类都换成了net standrad了,应该问题不大了。 然后在一顿 dotnet publish 之后,把部署包传到了 Linux 下进行测试,果然,运行通过,并没有抛出任何异常,而且Excel也生成了,把Excel传输到windows上使用office打开,完美… 然后紧接着就是继续各种测试了,在测试到 […]
View Details前言 性能是我们日常生活中经常接触到的一个词语,更好的性能意味着能给我们带来更好的用户体检。比如我们在购买手机、显卡、CPU等的时候,可能会更加的关注于这样指标,所以本篇就来做一个性能评测。 性能也一直是我们开发人员一直追求的一个目标,我们在做语言选择,平台选择,架构选择的过程中都需要在性能之间做衡量。 同样性能对 .NET Core 团队来说也是至关重要的,一项新技术的诞生,除了对生产力的提高,还有技术团队对性能的追求。 今天,我们就来做一个对比测试,来看看微软的这样新技术性能到底怎么样,俗话说的好:“是骡子是马,拉出来溜溜”。 下面让我开始吧。 目录 测试目标 测试工具 环境准备 开始测试 ASP.NET Core Kestrel vs ASP.NET Core IIS ASP.NET Core IIS vs ASP.NET IIS ASP.NET Core Kestrel vs ASP.NET IIS ASP.NET Core vs Python Django ASP.NET Core vs Java Servlet ASP.NET Core vs NodeJS 总结 测试目标 在测试之前,我们必须要明确我们本次测试想达到的一个目标。本次测试主要是测试应用程序的一个吞吐量。其中QPS,并发数,响应时间是我们衡量吞吐量的几个重要指标。 以下是本次对比测试的任务目标: 编号 对比方 系统环境 宿主环境 测试目标 1 ASP.NET Core vs ASP.NET Core Windows Kestrel vs IIS 相同平台不同宿主间性能差距 2 ASP.NET Core vs ASP.NET Windows IIS vs IIS 相同平台相同宿主不同框架间性能差距 3 ASP.NET Core vs ASP.NET Windows Kestrel vs IIS 相同平台不同宿主不同框架间性能差距 4 ASP.NET Core vs Python Django Linux Kestrel vs uwsgi 相同平台不同语言不同宿主不同框架间性能差距 5 ASP.NET Core vs Java Servlet Linux Kestrel vs Tomcat […]
View Details在ASP.NET Core中,如果在Kestrel中想使用HTTPS对站点进行加密传输,可以按照如下方式 申请证书 这一步就不详细说了,有免费的和收费的,申请完成之后会给你一个*.pfx结尾的文件。 添加NuGet包 nuget中查找然后再程序中添加引用Microsoft.AspNetCore.Server.Kestrel.Https 配置 把*.pfx结尾的文件拷贝的程序的Web根目录,然后修改Programs.cs文件:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
public class Program { public static void Main(string[] args) { var config = new ConfigurationBuilder().AddCommandLine(args).AddEnvironmentVariables("ASPNETCORE_").Build(); var host = new WebHostBuilder().UseConfiguration(config).UseKestrel(ConfigHttps()).UseContentRoot( Directory.GetCurrentDirectory()).UseIISIntegration().UseStartup<Startup>().Build(); host.Run(); } private static Action<KestrelServerOptions> ConfigHttps() { return x => { var pfxFile = Path.Combine(Directory.GetCurrentDirectory(), "*.pfx"); //password 填写申请的密钥 var certificate = new X509Certificate2(pfxFile, "password"); x.UseHttps(certificate); }; } } |
然后命令行窗口运行dotnet xxx.dll --server.urls https://www.example.com:port即可。 本文地址:http://www.cnblogs.com/savorboard/p/aspnetcore-kestrel-https.html 作者博客:Savorboard 欢迎转载,请在明显位置给出出处及链接
View Details