Download the PHP package liquidedge-app/htmlsanitizer without Composer
On this page you can find all versions of the php package liquidedge-app/htmlsanitizer. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package htmlsanitizer
JS Html Sanitizer
Client-side HTML Sanitizer (front-end only, i.e. "needs a browser", won't work in Node) to prevent XSS and unwanted tags in UGC.
- Very fast (8000 ops/sec)
- Very small (1.7kb unminified!)
- Zero dependency, vanilla JS, works even in IE (duh)
Please note: to prevent XSS attacks you should always sanitize input on the server too. Never trust the client!
Install
or
or
(simply puts the script into /node_modules)
Usage:
The sanitizer uses whitelisting approach (as opposed to "blacklisting") to clean out everything that's not allowed.
Speed & Benchmarks
It uses browser/DOM to parse the html by using DOMParser object (hence the browser "front-end only" requirement) which makes it much faster than "pure JavaScript" sanitizers.
Tested on https://www.bbc.co.uk homepage - the page is sanitized ~370 times per second on an i5 core CPU in Firefox Quantum (tested via benchmark.js)
Comparing HtmlSanitizer vs DOMPurify benchmark:
Tags allowed by default
a, abbr, b, blockquote, body, br, center, code, div, em, font, h1, h2, h3, h4, h5, h6, hr, i, img, label, li, ol, p, pre, small, source, span, strong, table, tbody, tr, td, th, thead, ul, u, video
Attributes allowed by default
align, color, controls, height, href, src, style, target, title, type, width
CSS styles allowed by default
color, background-color, font-size, text-align, text-decoration, font-weight
Schemas allowed by default
http:, https:, data:, m-files:, file:, ftp:, mailto:, pw:
(allowed in 'src', 'href' and similar "uri-attributes". To clean up stuff like <a href='javascript:alert()'></a>)
Configuring
Allowed tags, attributes, schemas and styles are listed in AllowedTags, AllowedAttributes, AllowedSchemas and AllowedCssStyles public properties. To disallow a tag remove it from the dictionary like this:
To add an allowed tag globally:
To allow an extra tag only once during invocation - specify extra selector to allow in the second parameter
Browser support
Supported by all major browsers, IE10 and higher.
BUT WHY?
Why create a front-end HTML sanitizer if the input has to be sanitized on the server anyway?
Users often copy-paste awful HTML generated by MS Word, MS Outlook or Apple Mail that needs a clean-up. Or you need to remove excessive formatting in an WYSIWYG editor. Or you need to display an (ugly) email message in a (beatuful) mobile app. Or (my favorite) you simply need to ease the load in the server-side sanitizer. And many many other use-cases.
© Jitbit
