Skip to content

Instantly share code, notes, and snippets.

View Micrified's full-sized avatar
🇫🇷
Collating...

Micrified

🇫🇷
Collating...
  • Rotterdam, Nederlands
View GitHub Profile
@Micrified
Micrified / 2b.go
Last active December 3, 2024 22:46
2b.go
package main
import (
"bufio"
"os"
"fmt"
"sync"
"strings"
"strconv"
)
@Micrified
Micrified / 1b.go
Created December 2, 2024 23:30
Puzzle 1, part B
package main
import (
"bufio"
"os"
"fmt"
)
func main() {
var i, j, sum int
@Micrified
Micrified / 1.c
Last active December 2, 2024 20:47
AOC 1
/**
0.00 real 0.00 user 0.00 sys
1277952 maximum resident set size
0 average shared memory size
0 average unshared data size
0 average unshared stack size
191 page reclaims
10 page faults
0 swaps
0 block input operations

SAML2 Implementation

Below you will find information about the SAML2 implementation. A short description of what is involved is described here. Put simply:

  • Identity Provider: An identity provider, or idp, is ESA's authoritative service for performing authentication on behalf of other services (it enables the SSO function).
  • Service Provider: A service provider, or sp, is any service that wants to be involved in the federated identity network. It performs a service for users, like offering a portal to manage Activites on.

In SAML2, both identity provider and service-provider need to configure themselves to know about one another

  • idp.xml: An XML file that describes the identity provider service. It's usually available at a public URL for services to read.
  • sp.xml: In this case, sp.xml refers to our service provider. This document must be given to the idp so that they can authorize your service to use their identity provider. It can be given by email, but is often also hos
@Micrified
Micrified / hook_example_permissions.md
Last active November 11, 2024 22:56
Hook Example

Hook based example

The following example uses a User-Role relation in order to codify the more complex permission behavior required for Activites. The relation allows both:

  1. A hierarchical page structure for organizing permissions
  2. Fine-grained rules around page permissions, no matter their position in the hierarchy.

Basics

We begin by defining a Role type listing all possible roles that a user may have in Activities. Furthermore, we define the Perm type to enumerate possible permissions

@Micrified
Micrified / permissions_users.md
Last active October 23, 2024 17:29
Permissions & Users

The following product requirements cause implementation challenges:

  1. Authentication via third party providers
  2. No storage of user credentials
  3. Access to the Wagtail CMS

The contradiction

A key stakeholder requirement is that users login via third-party services. This means:

  1. The credentials are handled and stored by the identity provider
  2. We only receive the user identity, and an affirmation of their authenticity.
@Micrified
Micrified / adapter.go
Created June 6, 2024 23:19
Wrapping interface methods
package main
import (
"fmt"
"encoding/json"
)
func ExpectJSON [T any] (b []byte) (T, error) {
var (
err error
// Online Go compiler to run Golang program online
// Print "Try programiz.pro" message
package main
import "fmt"
// ---
type Restful interface {
Get() string
@Micrified
Micrified / fail.go
Last active April 23, 2024 06:00
Yet another fail
package main
import "fmt"
type R interface {
A() string
B() string
}
type C interface {
R
Method(string) func(C)string
@Micrified
Micrified / sensor_reader.cpp
Created April 21, 2024 09:59
Safe sensor example
#include <chrono>
#include <cstdlib>
#include <iostream>
#include <ratio>
#include <string>
#include <thread>
#include <vector>
#include <mutex>
// [ Written to C++11 standard ]