arcseldon

[merge]
  tool = vimdiff
[mergetool]
  prompt = true
[mergetool "vimdiff"]
  cmd = nvim -d $LOCAL $REMOTE $MERGED -c '$wincmd w' -c 'wincmd J'
[difftool]
  prompt = false
[diff]
  tool = vimdiff

arcseldon

tmux cheat sheet

(C-x means ctrl+x, M-x means alt+x)

Prefix key

The default prefix is C-b. If you (or your muscle memory) prefer C-a, you need to add this to ~/.tmux.conf:

remap prefix to Control + a

arcseldon

tmux cheatsheet

As configured in my dotfiles.

start new:

tmux

start new with session name:

arcseldon

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

---

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

---

arcseldon

function (user, context, callback) {

 // console.log("context.request.query: ", context.request.query);
  
 if (context.request.query && context.request.query.response_mode === 'web_message') {
   console.log('sanitizing tokens...');
 
   var namespace = 'https://arcseldon.com/';
   context.idToken[namespace + '/CRIS_ABC'] = "";
   context.idToken[namespace + '/CRIS_DEF'] = "";

arcseldon

extends layout

block content
  br
  .w3-container
    .w3-card-4.w3-center(style="padding: 15px;")
      img(src=user.picture)
      p Welcome #{user.nickname}
      h2 User Profile
      pre #{userProfile}

arcseldon

function (user, context, callback) {
  // 
  // this rule can be used if you have chosen to use Username as the way to identify a user in Salesforce. Notice that we are mapping the email to the nameidentifier.
  //
  if (context.clientName === 'Salesforce') { 
    context.samlConfiguration.mappings = {
      'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier': 'email',
      'User.Username': 'email',
      'User.Email':   'email',
      'User.FirstName': 'given_name',

arcseldon

Configuration Properties

Configuring your Service Provider through configuration properties is pretty straight forward and most configurations could be accomplished this way. The two limitations that exists are: You can only configure what is exposed as properties, obviously, and you cannot provide specific implementations or instances of the different Spring Security SAML classes/interfaces. If you need to provide custom implementations of certain types or a more dynamic configuration you'll need to use the Java DSL approach for that configuration, but as expressed before, you can configure as much as you can through properties, while using the DSL configuration for any dynamic or custom implementations configuration. You can mix the two flavors.
The following table shows all the available properties (Parsed from Spring Configuration Metadata file).

Key	Default Value	Description
saml.sso.default-failure-url	/

arcseldon

Docker - How to cleanup (unused) resources

Once in a while, you may need to cleanup resources (containers, volumes, images, networks) ...

delete volumes

// see: https://github.com/chadoe/docker-cleanup-volumes

$ docker volume rm $(docker volume ls -qf dangling=true)

$ docker volume ls -qf dangling=true | xargs -r docker volume rm

arcseldon

package com.auth0;

import java.io.Serializable;

/**
 * Holds the user's credentials returned by Auth0.
 * <ul>
 * <li><i>idToken</i>: Identity Token with user information</li>
 * <li><i>accessToken</i>: Access Token for Auth0 API</li>
 * <li><i>type</i>: Token Type</li>