I'm trying to prevent cross-site scripting in the backend of my web-application. I was researching and I came accross the AntiXss nuget library. I noticed that there has not been a new release for a while. I was just wodering if it is recommended to user this library or if I should try a different approach.
In .Net versions 4.5 and later, AntiXSS is part of the framework and not a separate library anymore. It is in the System.Web.Security.AntiXss namespace, with almost all functionality of the original separate library.
Docs are here.
Compared to other built-in classes like HttpUtility, AntiXss is more secure, because it's a whitelist-based encoder, as opposed to blacklisting provided by other classes.
One part that did not make it into the framework is Sanitizer, but that was not very useful anyway. There are other libraries for html sanitization if needed (mostly not, it's a special case when dealing with user-supplied html code).
Related
Good day, I've been using ServiceStack for many years, I currently designing and planning a rewrite of an ASP MVC (Razor) project. #Script seems to be an almost perfect fit, without hands-on experience of the technology I have some doubts and questions.
My question is how relevant is #Script today and what is the future plans of this technology. I ask these questions because when I looked at GitHub example I noticed that there is not a lot of activity, and searching the internet I am also not finding a community around it.
As #Script's author I would say that #Script is a complete library for what it's designed for as an embeddable sandboxed .NET scripting and templating language that's ideal for exploratory programming with seamless integration into .NET APIs (including Win32 APIs) that includes a vast built-in library (1000+) of filters that's easily and highly extensible to the point that it's even able to natively support multiple languages (inc. built-in LISP Repl) within the same page that's been a joy to develop with thanks to its built-in Hot Reloading support where changes are instantly visible upon save - so technology-wise IMO it's pretty great.
If we were to compare it to comparable libraries in other languages like the Ruby's Liquid it should be pretty clear that #Script is vastly more capable where it scales from a user-friendly templating language to a powerful scripting language where it's capable of developing entire Windows Desktop Apps that fits in a Gist.
On the activity front, Liquid is also an established library with low activity with only a handful of commits in 2021, the difference is that it's vastly more popular and used in popular products like Jekyll as used in GitHub Pages which ensures it will always have a rich, vibrant ecosystem which is the most important indicator for assessing a technology's longevity.
Technology not as important as ecosystem
However in the end the technology doesn't matter nearly as much as its user base, community and ecosystem behind it which is where #Script is sorely lacking. Unfortunately this is the reality of libraries that compete Microsoft's defaults like Razor which are exclusively promoted for .NET and will always retain the majority of adoption in .NET.
#Script is a "complete" library in that I've added all the features I planned for it and there's basically nothing I can think of to add to it to make it more appealing, but facing the realization of its indefinite lack of adoption I wouldn't recommend using it for large living (i.e. multi-year) Websites, given it will never have the community and adoption enjoyed by other ecosystems since the benefits of a community and ecosystem are ultimately the most important attributes in order to continue investing in a technology.
Continue to be actively supported
Like all of ServiceStack, #Script is still an actively supported library with no outstanding issues so it's safe to use in that any issues will be promptly resolved should you wish to.
Website Development Recommendations
I'd say it's still a fine option for smaller definitively-scoped projects since its compile-time-free and Hot-Reload makes for a very productive Dev UX for server-generated dynamic pages. However even then I'd first evaluate if a static generated framework like Jekyll, Hugo or other popular static generators would be more appropriate since they enjoy a vibrant community and a statically generated site results in a more performant, resilient and cheaper to host and deploy website.
Static Site Generators
Having recently redeveloped the servicestack.net website to split it out into using Jekyll for static content and ServiceStack.Razor for dynamic content, my recommendation for large websites with large static and dynamic components is to use a static site generator for its static content which yields several benefits:
Although it does require a fair bit of overhead to setup as you're effectively maintaining 2 different websites however it greatly benefits if the static content is actively updated as there's a lot less friction to change and update content on a static generated site then a dynamic one and it results in a superior end user UX thanks to CDN Edge caches that's also cheaper to host from free sites like GitHub Pages and Netlify.
In order to preserve existing URLs we needed extra functionality not possible from a static host so our static content is deployed to a S3 bucket where we use CloudFront for CDN edge caching, CF Behaviors for proxying "external static" routes to our .NET5 dynamic website and a CF Function for supporting pretty URLs. For internally deployed websites you'll be able to accomplish similar functionality with reverse proxy and redirect rules.
SPA or Razor
For small websites or mostly dynamic websites that wont benefit from a content site split I'd recommend either an SPA Project Template if you prefer TypeScript and an established SPA FX like Vue, React, Svelte or Angular or Razor or MVC if you instead prefer C# server generated websites.
Progressive Enhancement
My personal preference is for read-heavy dynamic sites to use ServiceStack Razor utilizing API First Development approach so that all writes are made to the same clean ServiceStack APIs that Mobile and Desktop Apps would also call. This typically involves using some kind of progressive enhancement like our Client TypeScript Validation example which utilizes the Form & Validation Binding in #servicestack/client to take over <form> submissions to perform TypeScript API calls and apply any validation errors back to the Form's UI.
The Client jQuery example accomplishes the same thing without the tsc -w watched build step whose form & validation binding utilizes the older jQuery ss-utils.js library but it does mean you'd need to author logic in an older broadly ECMAScript 5 supported version of JS.
Future of #Script
As I don't expect #Script Pages will ever achieve any meaningful adoption required for self-sustained active development, it's unlikely we'll continue in investing in further development for usage in dynamic websites (i.e. the script project template), it's a complete and extensible library so further development isn't strictly necessary as it can be easily extended with your own local Plugins, Methods, Transformers and Blocks. But it does mean we're unlikely to be creating and including new methods/plugins designed for dynamic websites in the library OOB.
Still a critical ServiceStack component
#Script is still a critical component of ServiceStack where it's used to provide integrated SPA templates since it's able to render dynamic websites from static *.html pages in npm dev hot-reload servers which can't use Razor's *.cshtml pages. It's also what makes ServiceStack's Declarative Validation possible where validation rules can be defined on dependency-free DTOs as it allows defining binary-decoupled logic in dep-free attributes. It's also what makes vuedesktop.com Desktop Apps like ServiceStack Studio possible as well as command tools like Post Command - HTTP API Command Line Utils and cross-platform dotnet scripts which makes usage of its internal functionality, so it's going to continue on as a actively developed & supported library.
Good future use-cases of #Script
However I'd limit any #Script usage to where it excels, e.g. as an embeddable scripting .NET sandbox given it's more versatile & flexible than Razor for tasks like Rendering Emails, authoring & rendering Live Documents (e.g. if needing to maintain live user-generated reports in an RDBMS) or as an embeddable Template, JS or LISP DSL or for evaluating adhoc JS/LISP Expressions or .NET logic.
Future replacement project templates
For developing server-generated websites with ServiceStack we're looking at shipping a couple of new templates which encompasses our latest recommendations (e.g. embracing an API First Development style), if they result in a great Dev UX we're looking at:
An Integrated Static generated (e.g. Hugo/Jekyll) + Dynamic Project template
An API First MVC Pages + ServiceStack template with integrated progressive enhancement
Please follow #ServiceStack to get notified as soon as they become available.
Accessing controls values, what is the recommended way to use ?
document.getElementById(...) or XSP.getElementById(...)
The XSP object acts a "wrapper" and would hide implementation details (browser incompatibilities, etc.) for you, therefore I would prefer the use of XSP.getElementById(...):
The XSPClientDojo library defines a global XSP object which exposes
some JavaScript functions to the XPages runtime. As its name suggests,
XSPClientDojo utilizes the Dojo JavaScript library, however other
implementations may be developed in the future (for example, when
supporting handheld devices).
document.getElementById(...) places the reliance on browser implementation. XSP.getElementById(...) places the reliance on the IBM Dojo extension and IBM support.
The same rules hold for any of the XSP.... methods. If browsers changes should ever affect it, IBM code will be updated and as long as your server is on the current release and fix packs you will not need to make changes to your application. So as with relying on any framework, it comes down to whether you are willing to keep the framework up to date to leverage the extra layer of abstraction.
I am currently researching GWT as a means to develop web apps for a future project, and the more I read, the more I like the features it provides. Yet I am not quite sure what features of HTML5 are fully supported. I am more interested in multithreading (the new worker threads that work straight from JavaScript), WebGL rendering through the canvas element and possibly audio.
If these features are not supported yet, does anyone know any good libraries that are somewhat fast / stable for such features, or if it's possible to create custom widgets / wrappers, or a combination of writing code in GWT and pure JavaScript.
I know there are simpler ways of implementing these through various plugins, but I want something which is fully complaint with open web standards, meaning it has to run straight from the browser, without any plugins. That is why GWT seems like the best candidate, it "compiles" straight into JavaScript and uses features only from the official specifications of html.
GWT is ultimately compiled to javascript, so it has all the features of Javascript.
GWT provides classes (Widget, etc..) that wrap javascript/DOM functionality, but this is limited to standard functionality.
You can access all new/non-standard functionality (WebGL, ..) via JSNI. JSNI allows you to call JS, be called by JS and access properties/objects.
So if what you need can be coded in JS it can be coded in GWT via JSNI.
The two Haskell web frameworks in the news recently are Yesod (at 0.8) and Snap (at 0.4).
It's quite obvious that Yesod currently supports a lot more features than Snap. However, I can't stand the syntax Yesod uses for its HTML, CSS and Javascript.
So, I'd like to understand what I'd be missing if I went with Snap instead. For example, doesn't look like database support is there. How about sessions? Other features?
Full disclosure: I'm one of the lead developers of Snap.
First of all, let's talk about what Snap is. Right now the Snap team maintains five different projects on hackage: snap-core, snap-server, heist, snap, and xmlhtml. snap-server is a web server that exposes the API defined by snap-core. heist is a templating system. xmlhtml is an XML/HTML parsing and rendering library used by heist. snap is an umbrella project that glues them all together and provides the powerful snaplets API that makes web apps composable and modular.
Yesod has a host of projects on hackage. Most (all?) of them are listed in the Yesod category. Some of the notable ones are yesod-core, warp, persistent, and hamlet.
The reality of Haskell web development is that it's much less of an exclusive-or choice than seems to be perceived. In general the projects are very loosely coupled and fairly interchangeable. You could build a website using warp (the Yesod team's web server), heist (the Snap team's template system), and acid-state (the Happstack project's persistence system). You could also use snap-server with hamlet or persistent.
That said, the two projects definitely have some differences. The biggest difference I can point out objectively is that Yesod projects typically make heavy use of Template Haskell and quasiquoting to create concise DSLs, while Snap projects stick to building combinator libraries that favor composability. Just about any other differences I can think of will be subjectively biased towards Snap. The umbrella packages named after both projects are obviously going to make specific choices for the above mentioned components, and these choices will be reflected in the project dependencies. But that still doesn't mean that you can't pull in something different and use it as well.
Snap does have sessions and authentication, interfaces to several databases, and nice form handling (here and here) using digestive-functors that includes prepackaged support for arbitrarily nested dynamically sizable lists. These are just some of the growing ecosystem of pluggable snaplets. The sessions and authentication snaplets are written in a way that is back-end agnostic. So with a small amount of glue code you should be able to use it with just about any persistence system you can think of. In the future, Snap will stick with this policy as often as possible.
For the most part I think the choice of Snap vs Yesod vs Happstack is less an issue of features and more one of personal taste. Whenever someone says that one of the frameworks doesn't have something that another one has, most of the time it will be pretty easy to pull in the missing functionality from the other framework by importing the necessary package.
EDIT: For a more detailed comparison of the big three Haskell web frameworks check out my recent blog post. For a rougher (but possibly more useful) comparison using some broader generalizations, see my Haskell Web Framework Comparison Matrix
Fair warning: I'm the lead developer of Yesod.
I'm not sure what you don't like about the Javascript syntax: it is plain javascript with variable interpolation. As for CSS Yesod now has Lucius which allows you to also use plain CSS. For HTML, you can easily use any other library you want, including Heist (what Snap uses). That said, it's a bit of a funny thing to skip Yesod over CSS/Javascript syntax, when Snap doesn't even have a syntax for it. You are certainly welcome to their solution of just static files.
Yesod comes with seamless support for authentication/authorization, type-safe URLs, widgets, email, and a bunch of little things all over the place (breadcrumbs, messages, ultimate destination). Plus, Yesod has a fairly rich set of add-on packages for things like comments and markdown, and a few large real-world code bases to pick at for examples. If any of these are attractive to you, you might want to check if your alternatives supports them.
Give hamlet a try- you might end up liking it. A negative reaction at a superficial level is not uncommon. However, nobody that has actually used hamlet complains.
Also, why not use Happstack? Just because they aren't "in the news" doesn't mean they don't have a solid framework.
You probably referring to old version of yesod. Latest yesod versions have plain syntax for html, javascript and css.
The html syntax of yesod's template library hamlet is plain html with complete opening and closing tags and all normal html attributes. Yes you can omit closing tags and use shortcuts for id and class attributes. But you do not have to. You can continue to write plain html.
Not only that but html templates can reside in separate files, just like in Snap's template library Heist.
Java script templates (julius) are plain javascript files, also residing in separate files.
The css template does indeed have a different syntax, but recent version of yesod now provides also plain css syntax.
If you go with Heist you will not have type safe urls.
In Heist html templates are read from harddrive everytime. Yesod compiles all templates directly into the executable. No file is read from harddrive. Thus the response is much faster. You can see the benchmarks yourself.
In Yesod you can create widgets that cooperate nicely. Snap does not deal with widgets at all. You will have to roll your own.
Is it possible to use Subsonic with VistaDB? I see it as a supported database for Subsonic 3 on the project website, But can't find a T4 template for it?
Will I need to use SR or I can use AR?
Vikas
Although the underlying architecture of SubSonic (System.Data.Common) supports VistaDB there aren't currently any templates for it. So although in theory it's supported it won't be supported in practice until someone creates those templates.
I wrote a vistadb provider for subsonic 2.x that was never made part of the official project. The main reason it's not in subsonic is that it's not freely available, the required dll for it is very encumbered with licensing. So no one wanted the hassle. You could take this provider code and use it to prepare a template, or just copy the sql server template, and make the required edits for reading the schema. I don't think that vistadb will ever be an official part of subsonic 3 since the vistadb dll is not freely available even for testing. I dropped vistadb because of performance issues.