I'm not clear on how to use the AntiXSS library in my .Net WebAPI 2 project.
I have installed the AntiXSS NuGet package (which gives me v4.3), and have set the encoderType property of httpRuntime in web.config.
Which class should I now use to take advantage of AntiXSS? Does it override the behaviour of System.Web.HttpUtility?
If using the AntiXSS NuGet package, the correct use is to use Microsoft.Security.Application.Encoder.
According to bdorrans of the MS Web Protection Library (AntiXSS) project, you can indeed use HttpUtility once encoderType is set.
However, it shouldn't normally be a concern to encode output from an API. My scenario is that I'm serving a Single Page Application, and was worried I was injecting unsafe values in to the page via my model. But unless injecting values via .html() or .eval(), any malicious values will not be executed on the client.
Related
In the latest bot samples, we can see that bot is being added to services collection as below
services.AddTransient<IBot, MyBot>();
but in older samples, we saw below approach
services.AddBot<MyBot>(options => { });
Here I am trying to understand the benefits of adding bot using AddTransient() over using AddBot().
What I know is that internally AddBot uses AddTransient only, then why use AddTransient. Referred remarks section from this link.
You can see in the source code that the AddBot methods are used for automatically adding a bot adapter to DI in addition to the bot and for configuring bot-related options like credentials and error handling. The conventions for using the Bot Builder v4 SDK were very different when those samples were made, and the bot's configuration along with its credentials were loaded from something called a bot file. The current convention for using the SDK is much easier because it takes advantage of ASP.NET Core automatically loading the app's configuration from appsettings.json. Since we're not using AddBot anymore you'll notice that the adapter is added to DI explicitly, and you can configure things like error handling and middleware either by accessing the properties and methods of the adapter directly or by deriving your own adapter class, as seen in the samples.
I'm using mini profiler in my asp.net Web API project and want to track the performance of some code that runs in a custom DelegatingHandler.
The calls MiniProfiler.Current.Step() inside the DelegatingHandler don't show up in the results. Other calls in the same project show up ok.
Further investigation revealed that MiniProfiler.Current is retrieved from HttpContext.Current in the WebRequestProfilerProvider. And HttpContext.Current is null when called from DelegatingHandler.
Is there a better way to retrieve the MiniProfiler.Current so that it works inside the handler?
MiniProfiler Timings are stored in HttpContext.Current by default (as you discovered). Thus if you are calling MiniProfiler from a place where HttpContxt.Current is null, the results cannot be saved. The solution is to save (and retrieve) the results from somewhere else.
MiniProfiler offers the option of the option of changing the location where all results should be stored and retrieved from (using MiniProfiler.Settings.Storage). The new v3 MiniProfiler (beta nuget here) offers the option of configuring different IStorage for each request, and for using a MultiStorageProvider to designate multiple locations into which results can be stored and retrieved. You can see an example of this in the Sample.Mvc project on github.
In your case, the best approach might be to set a MultiStorageProvider for your global MiniProfiler.Settings.Storage that will first save/retrieve from HttpRuntimeCacheStorage and then afterwards will use some other IStorage that is accessible from the DelegatingHandler. Then in the DelegatingHandler, set the MiniProfiler.Current.Storage to only use the second storage option that you set in the MultiStorageProvider (since it is pointless to try to save the the HttpCache). In this was, profiles from the DelegatingHandler will be saved into your second storage option, and will be retrieved for view with your other results (since MultiStorageProvider will Load results from the first place it can get them - if it doesn't find the result in HttpCache, it will go to the second option.
Note - having multiple storage options is useful in this case, but it can have a negative impact on the performance of retrieving profiles.
What is the suggested way to implement output caching of service responses when using http://razor.servicestack.net?
Not used it since it's 4.5 and our current projects are 4.0, but perhaps CacheStack may be of use?
Otherwise handle it yourself via wrapping existing services with the ToOptimizedResultUsingCache extension method, and manually expiring cache keys on CRUD type operations.
I am currently working on a ASP.NET MVC 3 project and I am setting up the solution file on VS2010.
I am not sure of what is the standard approach. I am using the following approach
Company.Dept.Data (contains the dbml file - Data Model)
Company.Dept.Business (Business logics)
Company.Dept.Web (contains ASP.NET MVC3 webapplication)
The first two are class libraries and the last one is MVC3 web application.
Anyother recommendations?
There is no single "standard" approach. It all depends on your project and what problems you are trying to solve with the software. Your proposed structure of having 2 class libraries and 1 web project is one way to go for sure.
If you are going to do any kind of Dependency Injection using an Inversion of Control container, you might also want to consider having an "API" project for interfaces and an "Impl(ementation)" project for concrete classes that fulfill the interface contracts.
To echo danludwig, there really is no standard. I prefer breaking up libraries and namespaces according to functionality. Company.Db is my library for interacting with the database, Company.Mail are my wrappers around the Postmark mail service, etc.
I then tend to group like libraries into single repositories. So the 'storage' repository in source control holds Company.Db, Company.Caching, Company.FileStorage, etc. I have another repository 'messaging' that holds Company.Mail and Company.SMS (for interacting with Twilio to send text messages). When I branch out with new apps or new services (maybe a WCF endpoint for mobile clients), I can just pull down the 'messaging' repository, and I have all my class libraries for communicating with the user.
An application then looks like
Company.Application.Webite
\Libraries\Messaging
\Libraries\Messaging\Company.Mail
\Libraries\Storage
\Libraries\Messaging\Company.Db
\Libraries\Messaging\Company.Caching
\Libraries\Web
...
Company.Application.Wcf
\Libraries\Messaging
\Libraries\Storage
\Libraries\Messaging\Company.Db
\Libraries\Messaging\Company.Caching
...
This way, whether someone registers via the site, or via the mobile app, Company.Mail.MailServices.SendWelcomeEmail() sends the exact same welcome email, and there's no code duplication.
Whether this works for you, or even makes sense, who knows. I've also changed this scheme a hundred times, trying to find a layout that works with my development style/workflow. I wouldn't worry or stress too much about it, because whatever you pick, you're going to find things you like about it, and you'll find things you hate about it. I sometimes fall into the trap of spending more time trying to make everything "perfect", than to just code and change things I don't like.
Do I even need this rule anymore?
I don't see any requests incoming for resource.axd files (as opposed to when I ran webform applications)
WebResource.axd is an HTTP Handler that is part of the .NET Framework
that does one thing and one thing only – it is tasked with getting an
embedded resource out of a DLL and returning its content. What DLL to
go to and what embedded resource to take are specified through the
querystring. For instance, a request to
www.yoursite.com/WebResource.axd?d=EqSMS…&t=63421… might return a
particular snippet of JavaScript embedded in a particular assembly.
Its still part of the framework and you can still retrieve embedded resources using the above handler. You dont want your route handler to handle such requests and that is why it is ignored. My guess is that you can get rid of it if you are completely sure that your app/libraries that you use dont use it.