6220119

Security-Reviewing Uses of postMessage()

The postMessage() API is an HTML5 extension that permits string message-passing between frames that don't share the same origin. It is available in all modern browsers. It is not supported in IE6 and IE7.

postMessage is generally considered very secure as long as the programmer is careful to check the origin and source of an arriving

6220119

/*
  Made by Elly Loel - https://ellyloel.com/
  With inspiration from:
    - Josh W Comeau - https://courses.joshwcomeau.com/css-for-js/treasure-trove/010-global-styles/
    - Andy Bell - https://piccalil.li/blog/a-modern-css-reset/
    - Adam Argyle - https://unpkg.com/[email protected]/normalize.min.css / https://codepen.io/argyleink/pen/KKvRORE

  Notes:
    - `:where()` is used to lower specificity for easy overriding.
*/

6220119

WebSockets - An Introduction

WebSockets is a modern HTML5 standard which makes communication between client and server a lot more simpler than ever. We are all familiar with the technology of sockets. Sockets have been fundamental to network communication for a long time but usually the communication over the browser has been restricted. The general restrictions

• The server used to have a permanent listener while the client (aka browser) was not designated any fixed listener for a more long term connection. Hence, every communication was restricted to the client demanding and the server responding.
• This meant that unless the client requested for a particular resource, the server was unable to push such a resource to the client.
• This was detrimental since the client is then forced to check with the server at regular intervals. This meant a lot of libraries focused on optimizing asynchronous calls and identifying the response of asynchronous calls. Notably t

6220119

// Copyright: Hiroshi Ichikawa <http://gimite.net/en/>
// License: New BSD License
// Reference: http://dev.w3.org/html5/websockets/
// Reference: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol
(function () {

    if (window.WebSocket || window.MozWebSocket) return;

    var console = window.console;
    if (!console || !console.log || !console.error) {

6220119

image: gitlab.dev.terastrm.net:4567/terastream/cisco-nso/ci-cisco-nso:4.2.3

stages:
  - build
  - mr-robot

variables:
  NCS_VERSION: "4.2.3"
  DOCKER_REGISTRY: "gitlab.dev.terastrm.net:4567/terastream/cisco-nso"
  TARGET_REGISTRY: "repo.dev.terastrm.net:5000/"

6220119

var fs = require('fs');
var crypto = require('crypto');

fs.readFile('file.pdf', function(err, data) {
  var checksum = generateChecksum(data);
  console.log(checksum);
});

function generateChecksum(str, algorithm, encoding) {
    return crypto

6220119

Better local require() paths for Node.js

Problem

When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:

const Article = require('../../../../app/models/article');

Those suck for maintenance and they're ugly.

Possible solutions

6220119

How we incorporate next and cloudfront (2018-04-21)

Feel free to contact me at [email protected] or tweet at me @statisticsftw

This is a rough outline of how we utilize next.js and S3/Cloudfront. Hope it helps!

It assumes some knowledge of AWS.

Goals

6220119

Default

Powerlevel10k

6220119

$ curl --help
Usage: curl [options...] <url>
     --abstract-unix-socket <path> Connect via abstract Unix domain socket
     --alt-svc <file name> Enable alt-svc with this cache file
     --anyauth       Pick any authentication method
 -a, --append        Append to target file when uploading
     --basic         Use HTTP Basic Authentication
     --cacert <file> CA certificate to verify peer against
     --capath <dir>  CA directory to verify peer against
 -E, --cert <certificate[:password]> Client certificate file and password