Martijn Cuppens tweets the link to this code snippet and a screenshot of how the code renders in different browsers. Yup. Each browser produces a different result. The Twitter thread has more examples.
This is yet another example of how CSS and cross-browser compatibility can drive a web developer insane.
“Capture and Report JavaScript Errors with window.onerror” tutorial shows an easy way to capture, log and troubleshoot client-side errors:
onerroris a special browser event that fires whenever an uncaught JavaScript errorhas been thrown. It’s one of the easiest ways to log client-side errors and report them to your servers. It’s also one of the major mechanisms by which Sentry’s client JavaScript integration (raven-js) works.
window.onerror = function(msg, url, lineNo, columnNo, error) {
// ... handle error ...
return false;
}
“Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet” is a list of general recommendations and specific techniques to protect web applications against the CSRF attacks. That is, before the CSRF attacks will become obsolete.
A List Apart runs an excellent article “Going Offline“. In it, among other things, there’s one of the simplest explanations of the Service Workers technology that I’ve seen so far:
A service worker is like a cookie. Cookies are downloaded from a web server and installed in a browser. You can go to your browser’s preferences and see all the cookies that have been installed by sites you’ve visited. Cookies are very small and very simple little text files. A website can set a cookie, read a cookie, and update a cookie. A service worker script is much more powerful. It contains a set of instructions that the browser will consult before making any requests to the site that originally installed the service worker.
A service worker is like a virus. When you visit a website, a service worker is surreptitiously installed in the background. Afterwards, whenever you make a request to that website, your request will be intercepted by the service worker first. Your computer or phone becomes the home for service workers lurking in wait, ready to perform man-in-the-middle attacks. Don’t panic. A service worker can only handle requests for the site that originally installed that service worker. When you write a service worker, you can only use it to perform man-in-the-middle attacks on your own website.
A service worker is like a toolbox. By itself, a service worker can’t do much. But it allows you to access some very powerful browser features, like the Fetch API, the Cache API, and even notifications. API stands for Application Programming Interface, which sounds very fancy but really just means a tool that you can program however you want. You can write a set of instructions in your service worker to take advantage of these tools. Most of your instructions will be written as “when this happens, reach for this tool.” If, for instance, the network connection fails, you can instruct the service worker to retrieve a backup file using the Cache API.
“How JavaScript works” is a series of articles on SessionStack, describing some of the lesser known bits and pieces of JavaScript. One particular chapter that caught my attention is “The Mechanics of Web Push Notifications“.
Push and notification are two different APIs.
- Push — it is invoked when the server supplies information to a Service Worker.
- Notification — this is the action of a Service Worker or a script in a web app that shows information to the user.