DEV Community: Cibrax

Cookie-Based authentication for Next.js 13 apps

Cibrax — Wed, 11 Oct 2023 17:01:44 +0000

This post is for you if you want a simpler alternative to NextAuth to implement authentication in your Next.js application using Iron-Session and the App Router.

What's iron-session ?

It's a popular open-source project for Node.js for encrypting/decrypting data that can be persisted in cookies. You can find more about the project in Github.
My implementation uses a middleware that relies on iron-session to create an encrypted session cookie for the authenticated user. I wrote two functions: getSession for decrypting the data associated with the authenticated user in the existing session cookie and setSession for creating the session cookie.

import {unsealData} from "iron-session/edge";
import {sealData} from "iron-session/edge";
import {cookies} from "next/headers";

const sessionPassword = process.env.SESSION_PASSWORD as string;
if(!sessionPassword) throw new Error("SESSION_PASSWORD is not set");

export type User = {
    login: string;
}

export async function getSession() : Promise<User | null> {
    const encryptedSession = cookies().get('auth_session')?.value;

    const session = encryptedSession
        ? await unsealData(encryptedSession, {
            password: sessionPassword,
        }) as string
        : null;

    return session ? JSON.parse(session) as User : null;
}

export async function setSession(user: User) : Promise<void> {
    const encryptedSession = await sealData(JSON.stringify(user), {
        password: sessionPassword,
    });

    cookies().set('auth_session', encryptedSession, {
        sameSite: 'strict',
        httpOnly: true,
        // secure: true, # Uncomment this line when using HTTPS
    });
}

It's important to note that the authentication cookie has been set with the following attributes,

sameSite: strict, so only requests coming from our application receive the authentication cookie. This prevents cross-forgery attacks.
httpOnly: true, so the cookie could not be updated on the client side.
secure: true, so the cookie is only sent over https.

Next.js middleware

The new App Router only supports a single middleware function per application. That function must be called "middleware" and also exported in a file "middleware" at the same level as the "app" directory. If you need to address different concerns as middleware, all those should be combined in this function. Probably not a good idea, but that's a topic for another discussion.

import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

import { getSession } from "@/services/authentication/cookie-session";

export async function middleware(request: NextRequest) {

    const user = await getSession();

    if(!user) {
        return NextResponse.redirect(new URL('/login', request.url))
    }

    return NextResponse.next();
}

// See "Matching Paths" below to learn more
export const config = {
    matcher: '/((?!api|_next/static|_next/image|favicon.ico|login).*)',
}

Matcher is a regular expression that Next.js uses to determine if the middleware should run or not. The code for this implementation just checks if there is an active session or sends the user to the login page otherwise.

The Login form

The login form combines a component that runs the client side with a server action that authenticates the user and issues the session cookie.

'use client'

import Button from '@mui/material/Button';
import Typography from '@mui/material/Typography';
import Container from '@mui/material/Container';
import Paper from "@mui/material/Paper";
import TextField from "@mui/material/TextField";

import {
    experimental_useFormState,
    experimental_useFormStatus,
} from "react-dom";

import login from "@/app/login/action";

function SubmitButton() {
    const { pending } = experimental_useFormStatus()

    return (
        <Button
            type="submit"
            fullWidth
            variant="contained"
            color="primary"
            style={{ margin: '10px 0' }}
            aria-disabled={pending}
        >
            Login
        </Button>
    )
}

export default function Form() {
    const [state, dispatch] = experimental_useFormState(login, {
        username: '',
        password: '',
    });

    return (
        <Container component="main" maxWidth="xs">
            <Paper elevation={3} style={{ padding: '20px', marginTop: '20px' }}>
                <Typography variant="h5" align="center">Login</Typography>

                <form action={dispatch}>
                    <TextField
                        id='username'
                        name='username'
                        variant="outlined"
                        margin="normal"
                        required
                        fullWidth
                        label="Username"
                        autoFocus
                        aria-describedby={state.error ? "" : undefined}
                    />

                    <TextField
                        id='password'
                        name='password'
                        variant="outlined"
                        margin="normal"
                        required
                        fullWidth
                        label="Password"
                        type="password"
                        autoComplete="current-password"
                    />
                    <SubmitButton/>
                </form>

                {state.error && (
                    <Typography color='red' gutterBottom>
                        {state.error}
                    </Typography>
                )}
            </Paper>
        </Container>
    )
}

The component below representing the view of the login form runs as a client component to use experimental_useFormState. That function allows capturing results back from the server action.

The server action is straightforward; it only authenticates the user and sets the cookie. For the sake of simplicity, the code only checks for "admin" as username and password.

'use server'
import {setSession} from "@/services/authentication/cookie-session";
import {redirect} from "next/navigation";

export default async function login (
    previousState: { username: string; password: string, error?: string },
    form: FormData
) {
    const username = form.get('username');
    const password = form.get('password');

    if(username === 'admin' && password === 'admin') {
        await setSession({ login: 'admin' });

        return redirect('/home');
    }
    else {
        return {
            username: previousState.username,
            password: previousState.password,
            error: 'Invalid username or password'
        }
    }
}

There is something tricky about the experimental_useFormState function, which requires a client component to be used but a server component acting as a parent to invoke the server action. That part took me a while to figure out. You need a new server component to wrap the form.

import Form from "./form";

export default function Login() {
    return (
        <>
            <Form></Form>
        </>
    );
};

Complete example

You can find the complete implementation in this Github repo

Contratos Hibridos, Oraculos y Chainlink

Cibrax — Wed, 29 Dec 2021 13:07:12 +0000

Una de las caracteristicas principales de los Smart Contracts o contratos inteligentes en Blockchain programables como Ethereum es que se ejecutan de manera aislada. Eso signfica que la maquina virtual de Ethereum o EVM ejecuta los contratos en un sandbox en donde solo tienen acceso a los datos locales o datos provistos por otros contratos en la misma red.
La idea de Oraculos aparecen como solucion a esa problematica. Pareciera ser que el termino esta relacionado de alguna manera a la pelicula The Matrix. El oraculo era el personaje que sabia todo sobre la matriz y asesoraba a Neo, el persona principal sobre lo que ocurria en el mundo exterior.
Aplicando el mismo principio, podriamos decir que un oraculo es un smart contrat que sabe como conectarse con aplicaciones o servicios correndo fuera del Blockchain.

En muchos casos, proveen cotizaciones en tiempo real de distintos tokens a los smart contracts que forman parte de los protocolos Defi, y son criticos para el funcionamiento de los mismos.

Un contrato hibrido es un termino que introdujeron los del proyecto Chainlink. Es una combinacion de un contrato que corre en el Blockchain pero tiene acceso a servicios fuera del Blockchain que son provistos por nodos de la red de Chainlink (O mejormente llamados DoNs). En otras palabras, un contrato hibrido seria equivalente a un Oraculo.

Sergey Nazarov, uno de los fundadores de Chainlink hizo incapie en la importancia de los Oraculos para muchos de los protocolos que corren en un Blockchain, y la lanzo esta frase popular, "Un Blockchain sin Oraculos, es como una computadora sin internet".

Los modelos push y pull

Los modelos push y pull hacen referencia al modo en que un Oraculo provee informacion a otros contratos.

En el modelo push, aplicaciones o servicios corriendo fuera del Blockchain estan constantemente actualizando informacion en los contratos que actuan como Oraculos. Otros contratos pueden luego consultar esta informacion a demanda.

Por otro lado, el modelo pull es lo opuesto. Un contrato que necesita acceder a informacion no disponible en el Blockchain llama a un Oraculo a traves de una transaccion. Una aplicacion que esta corriendo por fuera del Blockchain y monitoreando las transacciones hacia ese Oraculo intercepta la transaccion, ejecuta codigo o llama a un servicio externo y devuelve el resultado como otra transaccion al contrato que originalmente llamo al Oraculo.

Chainlink

Chainlink es un proyecto que busca proveer toda la infrastructura que se necesite para poder correr una red de Oraculos que se integran con cualquier Blockchain programable existente (Ethereum y otros).
No es un Blockchain, pero brindan el software para que cualquiera pueda correr un nodo que internamente provee Oraculos que actuan como intemediarios entre Smart Contracts corriendo en un Blockchain y aplicaciones fuera del mismo.

El modelo de negocios de Chainlink es proveer mecanismos para vender datos a las aplicaciones corriendo en el Blockchain. Si un protocolo Defi necesita una cotizacion o algun dato que un servicio externa pueda proveer, los mismos se publican a traves de Oraculos que corren en uno o mas nodos de Chainlink. Esos nodos reciben fracciones del token nativo $Link cada vez que pueden satisfacer alguno de esos pedidos. El token $Link es una implementacion del estandard ERC-677.
La conexion con sistemas externos se realizar a traves un componente llamado "Adapter" o adaptador. Cualquier programador puede crear o implementar un "Adapter"

Cualquiera puede correr un nodo de Link, pero la gracia esta en poder tener acceso a algunos de los adapters que mas se utilizan.
Mucho de ese hosting se lo delegan a socios estrategicos o tambien llamados operadores de nodos. Al fin y al cabo, Chainlink representa en su totalidad al conjunto de todas las redes de nodos que corren su software.

Uno de los aspectos criticos de cualquier procolo de Defi es que no puede confiar en una sola fuente de datos para tomar decisiones. Si esa fuente de datos no esta disponible o brinda informacion erronea, de pronto se vuelve un verdadero problema y puede generar perdidas enormes.
Chainlink ataca ese problema juntando y procesando datos de muchas fuentes y haciendolo disponible a traves de distintos nodos. Si uno de esos nodos deja de responder, los otros lo pueden remplazar. Lo mismo con la calidad de la informacion, si uno de los nodos empieza a brindar datos invalidos, los otros pueden realizar correcciones. Cabe aclarar que esto solo aplica para el price feed de cotizaciones, el cual lo manejan ellos y es uno de los caballos de batalla de este proyecto. Si alguien quiere algo similar, lo tiene que implementar desde cero, y Chainlink no lo provee.

La arquitectura de Chainlink

Como definicion a alto nivel, una red de Chainlink esta compuesta por nodos. Un nodo es un proceso que esta corriendo todo el tiempo y permite la configuracion de tareas de integracion o que se conectan al Blockchain. Cuando arrancas un nodo, tenes que configurar una clave privada, la cual se usa para firmar cualquier transaccion que el nodo enviee al Blockchain. Si no tenes ningun clave, el nodo automaticamente genera una cuando arranca.
Esa clave tambien tiene que tener fondos en ETH, por que de lo contrario, el nodo no va a poder pagar por el gas para enviar las transacciones. Esa clave privada tambien brinda la contraparte publica o direccion para identificar al nodo.

Las tareas de integracion que corre un nodo con Oraculos en el Blockchain se configuran en algo que se llaman Jobs. Un job esta representado por un documento json que tiene dos partes, una tarea de arranque (initiator) y otras tareas de integracion. La tarea de arranque es la que vigila que se cumpla cierta condicion para dar comienzo a la ejecucion del resto de las tareas del job. Esas condiciones por lo general son transacciones o eventos que ocurren en el Blockchanin. Chainlink ya ofrece algunas implementaciones que podes reutilizar cuando configuras un job en un nodo. Tambien podes crear tu propia tarea de arranque si asi lo precisas.

Estas tareas de arranque son las que determinan el modelo push o pull del Oraculo. Las tareas que vigilan el transaction log del Blockchain por transacciones o eventos, soportan el modelo pull. Por el contrario, tambien tenes tareas que se ejecutan en intervalos de tiempo predeterminados y continuan con otras tareas que actualizan el estado de un smart contract. Estas ultimas son para soportar el modelo push.

Una vez que la tarea de arranque se ejecuto, esta devuelve datos que se pasan al resto de las tareas que se ejecutan a continuacion. La ultima tarea en ejecutarse puede llamar a un sistema externo o bien enviar los datos resultantes al Blockchain.

Esto es un ejemplo de un job,

{
  "name": "Integracion Web",
  "initiators": [
    {
      "type": "web"
      }
    }
  ],
  "tasks": [
    {
      "type": "myadapter"
    }
  ]
}

La tarea de arranque "web", es una de las tareas predefinidas por Chainlink y permite arrancar el job desde una interface web que provee el nodo. Una vez que este job arranca, ejecuta otra tarea que se llama "myadapter" y que probablemente envie datos a un sistema externo.

Como podes ver, los job implementan el patron de Tuberias o Pipeline, en donde tenes datos de ingreso que se van pasando entre las distintas tareas para luego convertirlos en un resultado final.

Un nodo nos da dos interfaces para configurar jobs y adapters (se explica a continuacion), por linea de comando con un tool, o por una interface web. Ambos necesitan de un usuario y contrasena que se registran cuando el nodo se configura por primera vez.

Adaptadores o Adapters

Un adaptador o external adapter es un componente para integrar Chainlink con sistemas externos.

Un adaptador no es otra cosa que una API que sigue ciertas convenciones para los parametros de entrada y lo de salida. El desarrollador escribe esta API y la puede publicar como un adaptador en un nodo de Chainlink. Se registra especificando la URL en donde esta hosteada. Una vez que se registro en el nodo, se la puede referenciar desde un job.

La API de un adaptador solo puede recibir HTTP POSTs con el siguiente JSON,

{"data":{}, "meta": {}, "id": "<job id>", "responseURL": "<url>"}

data: Son los datos de ingreso que la API necesita para pasarle al sistema externo
meta: Opcional. Son argumentos de configuracion.
responseURL: Opcional. Si la API tiene que devolver una respuesta con un callback a esta URL (para llamadas asyncronicas)
id: Opcional. El identificador del job.

La respuesta de un adaptador debe ser la siguiente:

{"data": {}, "error": {}, "pending": true|false}

data: Un objeto que representa la respuesta de la llamada externa.
error: Opcional. Detalles de error si la llamada fallo.
pending: Opcional. Para llamadas asincronicas, nos indica si la llamada esta pendiente de esperar una respuesta.

Un adaptador no devuelve codigos de estado HTTP para especificar si la llamada fallo o no. Y si el sistema externo necesita credenciales de autenticacion, se le deben pasar al adaptador como parte de los datos de entrada, o se deben configurar en el nodo.

Al momento de escribir este post, el nodo no pasa ningun token de autenticacion al adapter cuando lo llama. Si el adapter corre como una API en un servidor externo al nodo, y queres restringir quien puede hacer una llamada al mismo, vas a tener que restringer las llamadas por IP en el subnet en donde corren los nodos.

Correr un nodo de Chainlink

Cualquiera puede correr un nodo de Chainlink bajandose el codigo fuente o a traves de una imagen de Docker.

Este post solo va a discutir como hacerlo con Docker. El contenedor de Docker va a necesitar de los siguientes requisitos.

1- Una base de datos Postgres. (Tambien se puede correr como otro contenedor de Docker)
2- Acceso a un nodo de Ethereum, ya sea un nodo propio o un nodo publico en Infura.

Para este ejemplo voy a mostrar como correr la base de datos Posgres tambien como un contenedor de Docker.

El primer paso es crear una red en Docker para que nodo y la base de datos pueden comunicarse entre si.

docker network create chainlink-net

El segundo paso es correr el contenedor de Postgres

docker run -d -p 5432:5432 --name chainlink-db --net=chainlink-net -e POSTGRES_PASSWORD=password postgres

El tercer paso es crear un archivo con la configuracion del nodo de Chainlink (Este nodo va a utilizar Rinkeby). El archivo se debe llamar .env

LOG_LEVEL=debug
ETH_CHAIN_ID=4
MIN_OUTGOING_CONFIRMATIONS=2
LINK_CONTRACT_ADDRESS=0x01BE23585060835E02B77ef475b0Cc51aA1e0709
CHAINLINK_TLS_PORT=0
SECURE_COOKIES=false
GAS_UPDATER_ENABLED=true
ALLOW_ORIGINS=*
ETH_URL=<YOUR INFURA Rinkeby ETH URL>
DATABASE_URL=postgresql://postgres:password@chainlink-db:5432/postgres?sslmode=disable

Finalmente, se necesita ejecutar este comando arrancar el nodo de Chainlink

docker run -v ~/.chainlink-rinkeby:/chainlink -p 6688:6688 -it --net=chainlink-net --env-file=.env smartcontract/chainlink:0.10.8 local n

Una vez que el nodo esta corriendo, tambien ofrece acceso a un portal de administracion. Si lo corren en forma local, esta disponible en el puerto 6688 por defecto. Pueden navegar a https://localhost:6688 para comenzar a configurar jobs y adapters.

Si queres asociarle fondos en ETH a la clave privada del nodo, podes usar el tool por linea de comando para exportarla y luego importarla en un wallet externo. Necesitas correr estos comandos,

docker exec -it <container> bash
chainlink admin login
chainlink keys eth list
chainlink keys eth export <node-address> -p .password --output key.json

Node-Address es la direccion publica del nodo, esta se muestra una vez que arrancas al mismo o en la interface web. Una vez que corren este comando, van a obtener la clave privada en un archivo json. Pueden importar el mismo directamente en un wallet como Metamask.

Sign-In with Solana

Cibrax — Mon, 20 Dec 2021 15:27:44 +0000

Solana has become lately one of the hottest programmable Blockchains after Ethereum. Since the adoption of Solana is growing, and also the number of people using one of their wallets, it might be convenient to start looking into how to support one-click authentication for web sites.

This post will show how to enable that scenario with Phantom.

One-Click authentication with signatures

Either Ethereum or Solana supports the idea of signing text messages with the user's private key available on a wallet. Since only the user owns that private key, and it is the only one who can generate an equivalent signature, this is proof enough to use it as an authentication mechanism. A This scenario uses a combination of Signature + Public Key/Address. As an analogy to a traditional authentication method like username and password, the Public Key/Address would be equivalent to the username, and the signature to a password.

Signing a text message with Phantom

The following code shows how to use Phantom to sign a message. The user will be prompted to authorize this operation.

const message = `Sign this message for authenticating with your wallet. Nonce: ${nonce}`;
const encodedMessage = new TextEncoder().encode(message);
const signedMessage = await solana.request({
   method: "signMessage",
   params: {
     message: encodedMessage,
   },
});

A nonce was generated server-side and injected in the text message to avoid reply attacks, in which the user signature is intercepted and reused for authentication later on.

This sample uses NextAuth for integrating authentication in a Next.js application. The signature and public key are passed to the SignIn function provided by NextAuth.

signIn('credentials',
{
  publicKey: signedMessage.publicKey,
  signature: signedMessage.signature,
  callbackUrl: `${window.location.origin}/`
})

Verifying the signature on the server side.

The server receives the signature and public key and verifies whether the former is valid. The user is authenticated once this validation passes successfully.

const nonce = req.cookies["auth-nonce"];

const message = `Sign this message for authenticating with your wallet. Nonce: ${nonce}`;

const messageBytes = new TextEncoder().encode(message);

const publicKeyBytes = bs58.decode(credentials.publicKey);
const signatureBytes = bs58.decode(credentials.signature);

const result = nacl.sign.detached.verify(messageBytes, signatureBytes, publicKeyBytes);

if (!result) {
  console.log(`authentication failed`);
  throw new Error("user can not be authenticated");
}

const user = { name: credentials.publicKey }

return user;

This code retrieves the generated nonce from a session cookie, recreates the text message, and validates the user's signature with the public key passed by the client side.
Once the signature is validated, the public key is set as the username for the user.

The complete sample is available to download from my Github repository solana-login

Como implementar NFTs con Solidity

Cibrax — Thu, 28 Oct 2021 14:28:05 +0000

NFT o Token No Fugible (Non-Fungile-Token) es un concepto relativamente nuevo y capaz dificil de entender para muchos.

Un token en el contexto de Blockchain representa una prueba de pertenencia en el mundo digital. Significa que se puede utilizar como evidencia para demostrar que uno es dueño de algo. Hay una diferencia muy sutil entre ser dueño y probar que uno es dueño. Vos podes ser dueño de un automovil, pero para probar que realmente te pertenece, quizas necesites una factura o titulo que lo demuestre. Un token sirve para demostrar esto ultimo. Ademas, podes demostrar que el token te pertenece utilizando el sistema de critografia con clave publica y privada. El token esta asociado a una direccion que solo se puede calcular con la clave privada que uno posee.

Los tokens se crearon para representar valor en la moneda nativa de un Blockchain o su equivalente en moneda fiat como ser los dolares americanos. Si tenes un token, lo podes cambiar por otro sin hacer ninguna diferencia o perder valor.

En cambio, los NFTs fueron creados para representar cosas unicas cuyo valor no esta atado a una moneda. Como cada NFT es unico, tambien tiene un valor intrinsico diferente. No se puede cambiar simplemente por otro NFT como ocurriria con un token tradicional. Se pueden utilizar para representar posesion sobre bienes digitales como ser imagenes, subscripciones, tickets o recompensas en un juego, etc.

NFTs en Ethrereum

Los NFTs se implementan en Ethereum a traves de Smart Contracts. Estos ultimos no son los NFT en si, pero proveen el mecanismo para generarlos. Los contratos en este escenario controlan como se generan y asignan los NFTs en el Blockchain. La imagen siguiente muestra como los NFTs se agrupan y viven bajo el contrato que los genero.

En ese sentido, uno no puede simplemente acceder o localizarlos directamente por una direccion en el Blockchain. Son solamente una representation logica dentro del ambito de un contrato. El acceso a los mismos esta exclusivamente controlada por dicho contrato.

Como no representan un elemento nativo de un Blockchain, un desarrollador podria implementar el contrato para manejarlos en la forma que mas le convenga. Para evitar que esto pase, la comunidad de Ethereum definio una interface con metodos que cualquier implementador deberia seguir para considerar que el contrato permite controlar NFTs. Esta interface se convirtio en un estandard con el nombre de ERC-721.

pragma solidity ^0.4.20;

/// @title ERC-721 Non-Fungible Token Standard
/// @dev See https://eips.ethereum.org/EIPS/eip-721
///  Note: the ERC-165 identifier for this interface is 0x80ac58cd.
interface ERC721 /* is ERC165 */ {
    /// @dev This emits when ownership of any NFT changes by any mechanism.
    ///  This event emits when NFTs are created (`from` == 0) and destroyed
    ///  (`to` == 0). Exception: during contract creation, any number of NFTs
    ///  may be created and assigned without emitting Transfer. At the time of
    ///  any transfer, the approved address for that NFT (if any) is reset to none.
    event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);

    /// @dev This emits when the approved address for an NFT is changed or
    ///  reaffirmed. The zero address indicates there is no approved address.
    ///  When a Transfer event emits, this also indicates that the approved
    ///  address for that NFT (if any) is reset to none.
    event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);

    /// @dev This emits when an operator is enabled or disabled for an owner.
    ///  The operator can manage all NFTs of the owner.
    event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);

    /// @notice Count all NFTs assigned to an owner
    /// @dev NFTs assigned to the zero address are considered invalid, and this
    ///  function throws for queries about the zero address.
    /// @param _owner An address for whom to query the balance
    /// @return The number of NFTs owned by `_owner`, possibly zero
    function balanceOf(address _owner) external view returns (uint256);

    /// @notice Find the owner of an NFT
    /// @dev NFTs assigned to zero address are considered invalid, and queries
    ///  about them do throw.
    /// @param _tokenId The identifier for an NFT
    /// @return The address of the owner of the NFT
    function ownerOf(uint256 _tokenId) external view returns (address);

    /// @notice Transfers the ownership of an NFT from one address to another address
    /// @dev Throws unless `msg.sender` is the current owner, an authorized
    ///  operator, or the approved address for this NFT. Throws if `_from` is
    ///  not the current owner. Throws if `_to` is the zero address. Throws if
    ///  `_tokenId` is not a valid NFT. When transfer is complete, this function
    ///  checks if `_to` is a smart contract (code size > 0). If so, it calls
    ///  `onERC721Received` on `_to` and throws if the return value is not
    ///  `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`.
    /// @param _from The current owner of the NFT
    /// @param _to The new owner
    /// @param _tokenId The NFT to transfer
    /// @param data Additional data with no specified format, sent in call to `_to`
    function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;

    /// @notice Transfers the ownership of an NFT from one address to another address
    /// @dev This works identically to the other function with an extra data parameter,
    ///  except this function just sets data to "".
    /// @param _from The current owner of the NFT
    /// @param _to The new owner
    /// @param _tokenId The NFT to transfer
    function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;

    /// @notice Transfer ownership of an NFT -- THE CALLER IS RESPONSIBLE
    ///  TO CONFIRM THAT `_to` IS CAPABLE OF RECEIVING NFTS OR ELSE
    ///  THEY MAY BE PERMANENTLY LOST
    /// @dev Throws unless `msg.sender` is the current owner, an authorized
    ///  operator, or the approved address for this NFT. Throws if `_from` is
    ///  not the current owner. Throws if `_to` is the zero address. Throws if
    ///  `_tokenId` is not a valid NFT.
    /// @param _from The current owner of the NFT
    /// @param _to The new owner
    /// @param _tokenId The NFT to transfer
    function transferFrom(address _from, address _to, uint256 _tokenId) external payable;

    /// @notice Change or reaffirm the approved address for an NFT
    /// @dev The zero address indicates there is no approved address.
    ///  Throws unless `msg.sender` is the current NFT owner, or an authorized
    ///  operator of the current owner.
    /// @param _approved The new approved NFT controller
    /// @param _tokenId The NFT to approve
    function approve(address _approved, uint256 _tokenId) external payable;

    /// @notice Enable or disable approval for a third party ("operator") to manage
    ///  all of `msg.sender`'s assets
    /// @dev Emits the ApprovalForAll event. The contract MUST allow
    ///  multiple operators per owner.
    /// @param _operator Address to add to the set of authorized operators
    /// @param _approved True if the operator is approved, false to revoke approval
    function setApprovalForAll(address _operator, bool _approved) external;

    /// @notice Get the approved address for a single NFT
    /// @dev Throws if `_tokenId` is not a valid NFT.
    /// @param _tokenId The NFT to find the approved address for
    /// @return The approved address for this NFT, or the zero address if there is none
    function getApproved(uint256 _tokenId) external view returns (address);

    /// @notice Query if an address is an authorized operator for another address
    /// @param _owner The address that owns the NFTs
    /// @param _operator The address that acts on behalf of the owner
    /// @return True if `_operator` is an approved operator for `_owner`, false otherwise
    function isApprovedForAll(address _owner, address _operator) external view returns (bool);
}

El concepto de interface tampoco existe en la maquina virtual de Ethereum (EVM). Solidity los soporta, pero una vez que el contrato se compila y transforma en byte code, no hay forma de determinar que implementa dicha interface salvo mirando los metodos que provee.

Como los contratos son la fuente de NFTs, tambien cobra sentido el echo de utilizarlos para agrupar colecciones como images or arte.

Un NFT no es otra cosa mas que un ID unico que esta asociado a la direccion de su dueño en el espacio de almacenamiento del Smart Contract que lo genero.

El espacio de almacenamiento en el Blockchain es caro. Mientras guardes datos basicos de tus NFTs, no pasa nada. Pero si quieres guardar cosas mas grandes como imagenes de varios KBs, ya estamos hablando de otra cosa. El Blockchain no esta optimizado para ese escenario y tambien el precio a pagar seria muy alto. Por esa razon, lo que se hace en estos casos es utilizar un archivo de metadatos. Es un archivo en formato JSON que describe a tu NFT mas en detalle, y guarda entre otras cosas, URLs a otras ubicaciones en donde estan las imagenes asociadas al NFT u otros documentos grandes. Este archivo de metadatos se podria guardar en cualquier lado, pero la mayoria prefiere hacerlo en forma decentralizada utilizando IPFS. El contrato termina manteniendo una referencia a la ubicacion de este archivo.

El problema del huevo y la gallina. El Blockchain asegura integridad de datos para mi NFTs. Una vez que se almacena ahi, nadie puede cambiarlo. Sin embargo, no podemos asegurar lo mismo para este archivo de metadatos que vive afuera del Blockchain. Hay varias soluciones a este problema. Una es guardar estos metadatos como texto en el contrato, y todas las referencias del mismo fuera del Blockchain. Otra es guardar un checksum generado a partir de los datos en el mismo.

Implementando un contrato ERC-721 con OpenZeppelin

OpenZeppelin ya provee un contrato que podemos utilizar de base para cualquier implementacion que se adhiera al estandard ERC-721.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.2;

import "@openzeppelin/contracts/utils/Counters.sol";
import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract TikenToken is ERC721, Ownable {
    using Counters for Counters.Counter; 

    Counters.Counter private _tokenIds;

    event TokenEmitted(string indexed symbol, address _sender, uint256 _id);

    constructor() ERC721("My NFT", "MYNFT") {
    }

    function createToken(string memory _tokenURI, address to) public onlyOwner returns (uint) {
        _tokenIds.increment();
        uint256 newItemId = _tokenIds.current();

        _mint(to, newItemId);

        emit TokenEmitted(symbol(), to, newItemId);

        return newItemId;
    }
}

El codigo de arriba muestra una implementacion muy basica. Genera un nuevo identificador para un token NFT y llama al metodo interno _mint para asociar este nuevo token con la direccion que se paso como argumento. Este contrato guarda internamente la relacion entre ambos en una estructura de datos del tipo mapping.
Esta implementacion no ofrece metadatos para los NFTs. Si queres guardar una URL que apunte al archivo de metadatos, tambien tenes que implementar la interface ERC721URIStorage.

function tokenURI(uint256 tokenId)
        public
        view
        override(ERC721, ERC721URIStorage)
        returns (string memory)
    {
        return super.tokenURI(tokenId);
    }

    function createToken(string memory _tokenURI) public onlyOwner returns (uint) {
        _tokenIds.increment();
        uint256 newItemId = _tokenIds.current();

        _mint(msg.sender, newItemId);
        _setTokenURI(newItemId, _tokenURI);

        emit TokenEmitted(symbol(), msg.sender, newItemId);

        return newItemId;
    }

Con estos cambios, hay un metodo nuevo tokenURI que devuelve la URL asociada al token y modificamos el metodo createToken para guardar esa URL en el contrato.

Por ultimo, si tambien quieran soportar destruir o quemar los token NFTs generados por su contrato, lo pueden hacer implementando la interface ERC721Burnable

function _burn(uint256 tokenId) internal override(ERC721, ERC721URIStorage) {
        super._burn(tokenId);
}

Este metodo lo que hace es asignar el token a una direccion a la cual nadie puede acceder, y por lo tanto se considera que el token fue destruido o quemado.

NFTs in Ethereum explained

Cibrax — Mon, 25 Oct 2021 13:09:51 +0000

NFTs in Ethereum explained

NFT or Non-Fungible-Token is a relatively new concept that is hard to grasp for many.
A token in the scope of a Blockchain represents proof of ownership in a digital world, which means you can use it as evidence to prove you own something. There is a subtle difference between ownership and proof of ownership. You could own a car, but you might need an invoice or title to prove it is yours. A token represents the latter. You demonstrate a token is yours by using public and private key cryptography. The token is associated with an address that can only be computed with a private key you own.
A token was initially used to represent value in the native currency of a Blockchain or an equivalent fiat currency such as US Dollars. All the issue tokens were worth the same value. If you have one token, you could change with another token without making any difference or losing value.

NFTs were introduced to represent things with a unique value other than currency. As each NFT is unique, they have different intrinsic values as well. You can not simply change an NFT for another NFT anymore. They could represent ownership on digital assets such as images, subscriptions, game rewards, etc.

NFTs in Ethrereum

NFTs are implemented in Ethrereum with Smart Contracts. It is worth mentioning that a Smart Contract is not an NFT but a source or factory for them.

The contracts in this scenario control how the NFTs are issued and assigned in the Blockchain. The following image shows how NFTs are grouped and stored in the Blockchain under their parent contract.

In that sense, they can not directly be accessed or located by an address in the Blockchain. The access is always controlled by a contract. NFTs are not a built-in construct in the Blockchain either, so anyone could implement the Smart Contract to manage them in any way. To prevent the latter from happening, different community members in Ethereum defined a primary interface with a few methods that any Smart Contract should adhere to be considered an NFT factory. That interface became the facto standard known as ERC-721.

pragma solidity ^0.4.20;

/// @title ERC-721 Non-Fungible Token Standard
/// @dev See https://eips.ethereum.org/EIPS/eip-721
///  Note: the ERC-165 identifier for this interface is 0x80ac58cd.
interface ERC721 /* is ERC165 */ {
    /// @dev This emits when ownership of any NFT changes by any mechanism.
    ///  This event emits when NFTs are created (`from` == 0) and destroyed
    ///  (`to` == 0). Exception: during contract creation, any number of NFTs
    ///  may be created and assigned without emitting Transfer. At the time of
    ///  any transfer, the approved address for that NFT (if any) is reset to none.
    event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);

    /// @dev This emits when the approved address for an NFT is changed or
    ///  reaffirmed. The zero address indicates there is no approved address.
    ///  When a Transfer event emits, this also indicates that the approved
    ///  address for that NFT (if any) is reset to none.
    event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);

    /// @dev This emits when an operator is enabled or disabled for an owner.
    ///  The operator can manage all NFTs of the owner.
    event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);

    /// @notice Count all NFTs assigned to an owner
    /// @dev NFTs assigned to the zero address are considered invalid, and this
    ///  function throws for queries about the zero address.
    /// @param _owner An address for whom to query the balance
    /// @return The number of NFTs owned by `_owner`, possibly zero
    function balanceOf(address _owner) external view returns (uint256);

    /// @notice Find the owner of an NFT
    /// @dev NFTs assigned to zero address are considered invalid, and queries
    ///  about them do throw.
    /// @param _tokenId The identifier for an NFT
    /// @return The address of the owner of the NFT
    function ownerOf(uint256 _tokenId) external view returns (address);

    /// @notice Transfers the ownership of an NFT from one address to another address
    /// @dev Throws unless `msg.sender` is the current owner, an authorized
    ///  operator, or the approved address for this NFT. Throws if `_from` is
    ///  not the current owner. Throws if `_to` is the zero address. Throws if
    ///  `_tokenId` is not a valid NFT. When transfer is complete, this function
    ///  checks if `_to` is a smart contract (code size > 0). If so, it calls
    ///  `onERC721Received` on `_to` and throws if the return value is not
    ///  `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`.
    /// @param _from The current owner of the NFT
    /// @param _to The new owner
    /// @param _tokenId The NFT to transfer
    /// @param data Additional data with no specified format, sent in call to `_to`
    function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;

    /// @notice Transfers the ownership of an NFT from one address to another address
    /// @dev This works identically to the other function with an extra data parameter,
    ///  except this function just sets data to "".
    /// @param _from The current owner of the NFT
    /// @param _to The new owner
    /// @param _tokenId The NFT to transfer
    function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;

    /// @notice Transfer ownership of an NFT -- THE CALLER IS RESPONSIBLE
    ///  TO CONFIRM THAT `_to` IS CAPABLE OF RECEIVING NFTS OR ELSE
    ///  THEY MAY BE PERMANENTLY LOST
    /// @dev Throws unless `msg.sender` is the current owner, an authorized
    ///  operator, or the approved address for this NFT. Throws if `_from` is
    ///  not the current owner. Throws if `_to` is the zero address. Throws if
    ///  `_tokenId` is not a valid NFT.
    /// @param _from The current owner of the NFT
    /// @param _to The new owner
    /// @param _tokenId The NFT to transfer
    function transferFrom(address _from, address _to, uint256 _tokenId) external payable;

    /// @notice Change or reaffirm the approved address for an NFT
    /// @dev The zero address indicates there is no approved address.
    ///  Throws unless `msg.sender` is the current NFT owner, or an authorized
    ///  operator of the current owner.
    /// @param _approved The new approved NFT controller
    /// @param _tokenId The NFT to approve
    function approve(address _approved, uint256 _tokenId) external payable;

    /// @notice Enable or disable approval for a third party ("operator") to manage
    ///  all of `msg.sender`'s assets
    /// @dev Emits the ApprovalForAll event. The contract MUST allow
    ///  multiple operators per owner.
    /// @param _operator Address to add to the set of authorized operators
    /// @param _approved True if the operator is approved, false to revoke approval
    function setApprovalForAll(address _operator, bool _approved) external;

    /// @notice Get the approved address for a single NFT
    /// @dev Throws if `_tokenId` is not a valid NFT.
    /// @param _tokenId The NFT to find the approved address for
    /// @return The approved address for this NFT, or the zero address if there is none
    function getApproved(uint256 _tokenId) external view returns (address);

    /// @notice Query if an address is an authorized operator for another address
    /// @param _owner The address that owns the NFTs
    /// @param _operator The address that acts on behalf of the owner
    /// @return True if `_operator` is an approved operator for `_owner`, false otherwise
    function isApprovedForAll(address _owner, address _operator) external view returns (bool);
}

Interfaces don't exist as a primary construct in the Ethereum Virtual Machine (EVM). They are supported in Solidity, but they don't correlate to anything once they are deployed. You can assume a Smart Contract follows a convention for the methods it provides.

Since a Smart Contract becomes the source for NFTs, it also makes a lot of sense for grouping collections like image collectibles.

NFTs are unique IDs mapped to an address (the owner) and stored in a Smart Contract.

Storage space in the Blockchain is expensive. As long as you store basic data about your NFTs in the storage, you should be good. How about images? That is a different story. Although it would make sense to store the whole blob of bytes for an image in the Blockchain, that would be extremely expensive and hard to manage in the long run. For that reason, the community found a different way to address that scenario. It is called NFT metadata. It is a JSON file that describes additional data about your NFT that you wouldn't store in the Blockchain. That metadata file contains, for example, an URL to the location of the image blob. This metadata file could be stored anywhere, but many prefer it in decentralized storage like IPFS. The Smart Contract ends up holding a reference to the location of this metadata in the Blockchain.

The chicken and egg dilemma. My NFT in the Blockchain assures data integrity. Once it is saved in the Blockchain, it can be changed. However, the same thing can not be ensured for the metadata file is pointing to. There are solutions to this problem. Store the metadata as text in the same storage as the Smart Contract, or store a checksum created from the data in the metadata file.

Implementing an ERC-721 contract

OpenZeppelin already provides a base contract that can be used as a starting point for any implementation that sticks to the ERC-721 standard.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.2;

import "@openzeppelin/contracts/utils/Counters.sol";
import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract TikenToken is ERC721, Ownable {
    using Counters for Counters.Counter; 

    Counters.Counter private _tokenIds;

    event TokenEmitted(string indexed symbol, address _sender, uint256 _id);

    constructor() ERC721("My NFT", "MYNFT") {
    }

    function createToken(string memory _tokenURI, address to) public onlyOwner returns (uint) {
        _tokenIds.increment();
        uint256 newItemId = _tokenIds.current();

        _mint(to, newItemId);

        emit TokenEmitted(symbol(), to, newItemId);

        return newItemId;
    }
}

The code above shows a straightforward implementation of an ERC721 contract.
It generates a new identifier for the NFT and calls the internal _mint method for associating the sender address with this new token (internally stored in a mapping).
This implementation does not offer any metadata for the NFTs. If you also want to store the URL for the metadata associated with the generated NFT, you must implement the ERC721URIStorage interface.

function tokenURI(uint256 tokenId)
        public
        view
        override(ERC721, ERC721URIStorage)
        returns (string memory)
    {
        return super.tokenURI(tokenId);
    }

    function createToken(string memory _tokenURI) public onlyOwner returns (uint) {
        _tokenIds.increment();
        uint256 newItemId = _tokenIds.current();

        _mint(msg.sender, newItemId);
        _setTokenURI(newItemId, _tokenURI);

        emit TokenEmitted(symbol(), msg.sender, newItemId);

        return newItemId;
    }

These changes include a new method, tokenURI that returns the metadata URL associated with the token and a new line _setTokenURI in the createToken method for persisting the URL in the contract storage.

Finally, if you also want to support the ability to destroy or burn issued NTFs, you can also implement the interface ERC721Burnable

function _burn(uint256 tokenId) internal override(ERC721, ERC721URIStorage) {
        super._burn(tokenId);
}

The method assigns the token to an address that is no longer accessible.

Implementing a basic ETH Pool - Exactly challenge explained

Cibrax — Thu, 26 Aug 2021 18:32:03 +0000

Implementing a basic ETH Pool - Exactly Finance's challenge explained

I am still in the process of learning Solidity and Smart contract development, and there is no better way to learn than building new stuff on it. Yesterday, I came across a code challenge from Exactly to build a basic pool in Ethereum. I thought it was going to be a great exercise to put some ideas into practice, so I decide to ahead and do it. What I am going to show here is a summary of all the design decisions and how I ended up implementing that solution.

The Challenge

You can find the full description of the challenge here. In short, it requires implementing a pool where one or more participants can deposit funds. There is also a team that owns the pool and can contribute to it with rewards. Those rewards are distributed across all the participants in the pool according to their % of the stake. For example, if Participant A deposits 100 tokens and B 300 tokens, A owns 25% and B 75%. When A or B withdraws the funds from the pool, they should get their funds and also the corresponding % of the rewards sent to the pool until that point in time. Once a participant has left the pool, it won't be able to claim rewards in that pool anymore. Time is not mentioned anywhere in the description, so we won't consider it as a variable for the implementation.

The implementation

The first thing is to define the Smart Contract structure. For this implementation, we will require at least three methods,

Deposit: for making deposits in the pool
Withdraw: for withdraw funds from the pool
Deposit Rewards: for teams members to distribute rewards through the members in the pool.

contract ETHPool {
  receive() external payable {}
  function depositRewards() public payable {}
  function withdraw() public {}
}

We could implement deposits in two ways, a traditional method or a receive method (previously known as the fallback method). I decided to use the latter to receive funds directly with a regular transaction without a data payload. Some wallets or exchanges don't support data payload.

The Receive method

uint256 public total;

address[] public users;

struct DepositValue {
  uint256 value;
  bool hasValue;
}

mapping(address => DepositValue) public deposits;

receive() external payable {

   if(!deposits[msg.sender].hasValue) // only pushes new users
      users.push(msg.sender);

    deposits[msg.sender].value += msg.value;
    deposits[msg.sender].hasValue = true;

    total += msg.value;
}

The deposit implementation uses two data structures, a mapping for storing the funds associated with a user (deposits), and a list for tracking all the users in the pool (users).
In the way the EVM works, there is no way to determine if an entry exists in a mapping, so we can not rely on the mapping to determine if the user is part of the list of users. I did not want to go through all the elements in the list either; that could be expensive for a long list. I decided to use a known workaround with a struct that contains a flag to determine if the entry was defined or not.
Once a user makes a deposit, I store the funds in the mapping and add the user to the list if it was not added previously.
Finally, I increase the total value in the pool. I decided to use a variable to store the contract's total and not use the balance. The latter is prone to attacks

The DepositRewards method

function depositRewards() public payable  {
  require(total > 0); // No rewards to distribute if the pool is empty.

  for (uint i = 0; i < users.length; i++){
    address user = users[i];

    uint rewards = ((deposits[user].value * msg.value) / total);

    deposits[user].value += rewards;
   }
}

The challenge description does not mention time anywhere as a variable. It only describes the rewards are paid weekly. That implies that anyone with funds in the pool can receive rewards. It does not matter how long the funds were there.
My implementation goes through all the users in the list and distributes the received rewards according to the % of the stake on the pool.
I had to consider two things when implementing this method.

If the pool is empty, so the total equals 0, there is no need to distribute any rewards. We want to rollback the transaction if that happens. Otherwise, the funds for the rewards will be lost.
The EVM does not support decimals or float numbers, so you have to be careful when doing divisions. The initial formula I used was this one (user deposits / total) * rewards. However, that produced a result equal to 0 most of the time, as the user deposits were less than the total.

The Withdraw method

function withdraw() public {
  uint256 deposit = deposits[msg.sender].value;

  require(deposit > 0, "You don't have anything left to withdraw");

  deposits[msg.sender].value = 0;

  (bool success, ) = msg.sender.call{value:deposit}("");

  require(success, "Transfer failed");
}

It checks the user's funds in the pool and transfers those. If the user does not have anything in the pool, the transaction is reverted. It also sets the deposits in the pool to zero before making the transfer to avoid reentrancy attacks. Once the transfer is made, it checks for the results and reverts the transaction if the call failed (our change in the deposits mapping is reverted as well).

There is no need to use a reentrancy guard, as setting the deposit to 0 is making the same effect.

Managing the Team Members

The challenge description is clear about who can deposit rewards in the pool. That's the team members. We need to add support in our contract for adding members. A simple way is to pass a list of addresses in the constructor, but that's not flexible. Once the contract is deployed, the list of members can not be changed anymore. I decided to use the OpenZeppelin Access Control contract, which provides support for roles.

import "@openzeppelin/contracts/access/AccessControl.sol";

contract ETHPool is AccessControl {
  constructor() {
    _setupRole(DEFAULT_ADMIN_ROLE, msg.sender);
    _setupRole(TEAM_MEMBER_ROLE, msg.sender);
  }
}

function addTeamMember(address account) public {
  grantRole(TEAM_MEMBER_ROLE, account);
}

function removeTeamMember(address account) public {
  revokeRole(TEAM_MEMBER_ROLE, account);
}

We assign the admin role and team member role to the Smart Contract's owner as a part of the constructor execution. The admin is the one that can assign users to the other roles. I also added two methods to grant or revoke the team member role to/from a user.

Finally, the depositRewards method was modified to check for that role.

function depositRewards() public payable onlyRole(TEAM_MEMBER_ROLE) {

Adding events

Events are nice to have features in Smart Contracts. They allow reporting information in the Blockchain transaction log that can not be inferred directly from a transaction. They can also be indexed and used by Dapps.

event Deposit(address indexed _address, uint256 _value);
event Withdraw(address indexed _address, uint256 _value);

I added two events for reporting when a deposit or a withdraw was made.
Those are called in the respective methods.

receive() external payable {
   ....
   emit Deposit(msg.sender, msg.value);
}

function withdraw() public {
  ...
  emit Withdraw(msg.sender, deposit);
}

The complete implementation

You can find the complete source code in my Github repository.

Chainlink Keepers - An alarm clock for your Smart Contracts

Cibrax — Fri, 06 Aug 2021 19:48:50 +0000

Smart Contracts work in reactive mode. Once deployed in the Blockchain, they go to a hibernation state until some work needs to be done. When the work is completed, they go to bed again. They basically react to transactions by executing code.

On the contrary, Smart Contracts in proactive mode, which don't really exist in reality but can be emulated, watch for different conditions to wake up themselves and do their job without intervention. For example, a contract that runs automatically when it detects a price fluctuation or when a given date or time is reached.

These contracts require the intervention of an external agent or worker that is constantly pinging the contract to verify whether one of the conditions to run was met. Those conditions should be checked in one or more view methods to avoid paying gas to the network. That means they can be resolved locally without submitting transactions.

Running an agent or worker now means you require additional off-chain infrastructure, which is centralized.

What if you can also leverage some of the existing decentralized network of oracles (DONs) from Chainlink to run those agents. Enter in the scene the Chainlink Keepers.

Chainlink Keepers

Keepers is a feature recently added in Chainlink for hosting jobs that allow running Smart Contracts proactively. It uses DONs to run the jobs in a decentralized manner.
Jobs are called Upkeeps, and the Smart Contracts must implement an interface with the following methods.

function checkUpkeep(
    bytes calldata checkData
  )
    external
    returns (
        bool upkeepNeeded,
        bytes memory performData
);

function performUpkeep(
    bytes calldata performData
) external;

checkUpKeep is the method called periodically by the jobs to check if some works need to be done. It's the alarm clock for your contract. It receives a parameter checkData, which could be helpful to check for the conditions in the method implementation. That data is a fixed value that you configure as part of the job. It must be implemented as a view to avoiding paying gas on each call.
It returns two values, upKeepNeeded, which specifies if an action must be performed, and data to be passed to execute that action.

performUpKeep is the method where the Smart Contract does the work. It's called if upKeepNeeded returned a value equal to true.

Chainlink also offers an application where you can configure the jobs. As part of the configuration of the job, you must provide the following data.

An email address
Name of the job (unkeep)
Address of the deployed contract
Admin Address. This is the address of an owner that can withdraw funds associated to the contract.
Gas Limit. This gas limit is for executing the performUnKeep method.
Check Data, which is passed to the checkUpkeep method. This is an array of bytes (hex), which could result from using abi.encode.

This feature is still in beta and the registration must be done manually in the Keepers app. Not support for automation APIs for the moment

Anatomy of a Keeper contract

Let's say that you want to implement a Betting contract for a game with two participants. You would like to select a winner and distribute the gains after the game finishes.

//SPDX-License-Identifier: Unlicense
pragma solidity ^0.8.0;

interface KeeperCompatibleInterface {
    function checkUpkeep(bytes calldata checkData) external returns (bool upkeepNeeded, bytes memory performData);
    function performUpkeep(bytes calldata performData) external;
}

contract Betting is KeeperCompatibleInterface{

   uint public matchTimestamp;

    constructor(uint _matchTimestamp) {
      matchTimestamp = _matchTimestamp;
    }

    function checkUpkeep(bytes calldata checkData)  external view override returns (bool upkeepNeeded, bytes memory performData) {
         upkeepNeeded = (block.timestamp > matchTimestamp);
    }

    function performUpkeep(bytes calldata performData) external override {
        //calls an oracle to retrieve the result of the match

    }
}

The contract is set with a time lock through a timestamp received in the constructor. We can assume this represents the date and time after the game finishes, and we know who the winner is.

 uint public matchTimestamp;

    constructor(uint _matchTimestamp) {
      matchTimestamp = _matchTimestamp;
    }

The checkUpkeep method compares the current block timestamp with the timestamp assigned to the contract and returns a value indicating if the condition is satisfied or not.

function checkUpkeep(bytes calldata checkData)  external view override returns (bool upkeepNeeded, bytes memory performData) {
         upkeepNeeded = (block.timestamp > matchTimestamp);
    }

Finally, the performUpkeep emulates a call to an Oracle in Chainlink that might hit an API to return the game's result.

function performUpkeep(bytes calldata performData) external override {
        //calls an oracle to retrieve the result of the match

}

The Web3 ecosystem for Ethereum

Cibrax — Mon, 02 Aug 2021 14:51:27 +0000

Web3 is an umbrella term for a new wave of applications that rely on decentralized technologies and the Blockchain.
Since the inception of Ethereum, which brought the idea of executing code in the Blockchain, many new projects have emerged in this space to help developers implement decentralized applications.
The image above shows some of the most notable projects that you can start using today.

Let's give a short overview of the purpose for each one.

IPFS

"Interplanetary file system" (or IPFS) is a protocol and peer-to-peer network for storing and sharing files. As with any peer-to-peer network, there is no central server, and different nodes in the network replicate copies of the files.
It would be equivalent to Bittorrent but with a different feature set, and it's what most developers in the Web3 space use today for hosting DApps, written as Single Page Applications, or store and share files.
IPFS is also used to store assets related to the NFTs.
Once you publish content in one of the IPFS nodes, it gets associated with an identifier that could use to locate it.

Another critical aspect of IPFS if you are planning to host your DApp on it is content pinning. To ensure your files are retained in the network, you need to rely on a pinning service. Infura, for example, offers a free plan for a limited space.

The Graph

The Graph project implements a protocol for indexing and querying data available in the Eth Transaction Log and IPFS.
It supports the idea of subgraphs, which allow developers to tailor the data to be indexed based on their needs.
Those subgraphs are published through nodes in the network, and they can be queried from DApps.

If your DApp has immediate needs to query data available in the transaction log (e.g., transactions or events), or data pushed in IPFS, you should start by looking into this project first.

Chainlink

Chainlink is a project whose aim is to provide all the infrastructure and plumbing for running a network of Oracles (DONs) that integrate with existing Blockchain networks (Ethereum and others). It's not a Blockchain, but it offers the infrastructure to run heterogeneous networks with oracle nodes that act as intermediaries between Smart Contracts and applications running outside.
The value proposition or business value in Chainlink is to offer a mechanism to sell data to apps running in the Blockchain. If you have an API that provides data that might be useful in the Blockchain, you can publish it through a Chainlink's adapter in one or more nodes and get paid for every request made to it. The unit of payments is a LINK token, which is a standard ERC-677 token.
You can run one or more nodes or ask any existing node operators (service providers that run nodes in their infrastructure) to run the adapter for you.
In that sense, Chainlink represents a collection of decentralized oracle networks (DONs) with nodes hosting different adapters or connections with external applications.
One of the critical aspects of implementing autonomous apps that run in a Blockchain is that they can not rely on a single data source to make decisions. If the data source becomes unavailable or starts providing inaccurate information, it suddenly becomes a big mess.
Chainlink tries to address that issue by aggregating data from multiple sources and making it available through various nodes (horizontal scaling). If one node becomes unresponsive, the other nodes can take that work. The same thing with the data sources is that if one starts providing invalid data, they can still correct it by using other sources.

If you are building Smart Contracts that require interaction with the external world, this is the project to look into.

Ceramic and IDX

Ceramic and IDX are two relatively new projects from the same company, which address different scenarios.

Ceramic provides a mechanism for supporting data streams on top of IPFS. This project might be a good fit if you need to support scenarios like messaging in your DApp.

On the other hand, IDX is about user identity and authentication. It tries to provide an identity layer that any DApp could use to uniquely identify users in a decentralized manner. If you want your DApp users to be authenticated with ETH private keys and have a decentralized profile for them, this is the project.

Polkadot

Polkadot is a project that provides interoperability between ETH and other Blockchains. The idea behind Polkadot is that many of the different available Blockchain today have different purposes, there is any Blockchain that could do everything, and they need to interoperate somehow. The connection between those Blockchain networks is made through bridges, which this project is going to provide.

A bridge is an intermediary for moving assets or data from one Blockchain to another. As the Blockchains use different protocols, rules, and governance models, the bridge provides various interoperable mechanisms on both sides.

Polygon

Polygon is a layer 2 project for Ethereum. It's well known that Ethereum suffers from scalability issues. It can only process 17 transactions per second, and the gas fees can be very high sometimes.
Polygon runs on top of the Ethereum network and provides better transaction throughput and lower gas fees. It works as a secondary network with a bridge that allows moving assets (tokens) from one network and another. You could leverage Polygon to move load from the main Ethereum network into this L2 Blockchain and provide better response times and cheap gas fees to your users.

Using Merkle Trees for Bulk transfers in Ethereum

Cibrax — Tue, 27 Jul 2021 19:53:03 +0000

Using Merkle Trees for Bulk transfers in Ethereum

Merkle Trees have become more popular than ever in the last decade for their heavy use in the crypto world. Most Blockchain implementations rely on this data structure for validating transactions as part of the consensus protocols.

What is a Merkle tree exactly? It's a data structure usually represented by a binary tree where each parent node contains a combination of hashes from their children.

The top of the tree is called root hash or Merkle root, and it is obtained from the process of re-hashing the concatenation of the child nodes starting from the last layer up to the top.

If the hash in one of the nodes is changed, the resulting tree and Merkle Root are also changed. This is an essential factor for one of the scenarios we will discuss in this article, bulk transfers.

The use of Merkle Trees for Bulk Transfers

We all know that executing an operation like a transfer in a Smart Contract cost money (or Ether in technical terms), which is paid as gas to the validation nodes in the network. Now imagine that you have to make thousands of transfers; that's a lot of money giving the high prices of the gas in the ETH mainnet.

This kind of scenario is fairly common for NFT airdrops, or in the betting industry. Merkle trees become handy for inverting roles in these particular scenarios. What if we make all the possible recipients claim their tokens instead of making a transfer to them. In that way, our solution would scale better as they will be responsible for paying the gas to claim the tokens.

Let's now describe in detail how this solution works in practical terms.
If we know all the addresses in advance, we can use a Merkle tree and compute a unique Merkle root. We can later distribute a proof representing one of the tree's nodes to each of these addresses.

They can use the proof to claim the tokens. The Merkle root in our possession can validate the proof and make sure it belongs to the same tree. If the validation succeeds, we can assume the presented proof was ok, and we can issue the tokens.

This article will show you how to implement this with Solidity for a Betting scenario.

Anatomy of the Betting Smart Contract

The implementation of our Smart Contract uses the OpenZeppelin Contract Library and MerkleProof utility. It's a contract for betting on a match with two teams, team one and team two.

This is how the contract looks like

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "hardhat/console.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import {MerkleProof} from "@openzeppelin/contracts/utils/cryptography/MerkleProof.sol";

contract Betting is Ownable {
  event GainsClaimed(address indexed _address, uint256 _value);

  using MerkleProof for bytes32[];

  uint256 public totalBetOne;
  uint256 public totalBetTwo;

  uint256 public minimumBet;

  address[] public playersBetOne;
  address[] public playersBetTwo;

  mapping(address => uint256) public players;
  mapping(address => uint256) public claimed;

  bytes32 merkleRoot;
  uint8 winner;

  constructor() Ownable() {
    // minimum bet is 1 gwei
    minimumBet = 1000000000;
  }

  function setMerkleRoot(bytes32 root, uint8 team) onlyOwner public 
  {
    merkleRoot = root;
    winner = team;
  }

  function checkPlayer(address player) public view returns(bool){
    return !(players[player] == 0);
  }

  function getTotalBetOne() public view returns(uint256){
    return totalBetOne;
   }

  function getTotalBetTwo() public view returns(uint256){
    return totalBetTwo;
  }

  function getPlayersBetOne() public view returns(address[] memory) {
    return playersBetOne;
  }

  function getPlayersBetTwo() public view returns(address[] memory) {
    return playersBetTwo;
  }

  function bet(uint8 team) public payable {
    require(team == 1 || team == 2, "Invalid team");

    require(!checkPlayer(msg.sender), "You bet on a game already");

    require(msg.value >= minimumBet, "Minimum bet is 1 gwei");

    require(merkleRoot == 0, "Bets are closed");

    if(team == 1) {
      playersBetOne.push(msg.sender);
      totalBetOne += msg.value;
    } else {
      playersBetTwo.push(msg.sender);
      totalBetTwo += msg.value;
    }

    players[msg.sender] = msg.value;
  }

  function claim(bytes32[] memory proof) public {
    require(merkleRoot != 0, "No winner yet for this bet");

    require(proof.verify(merkleRoot, keccak256(abi.encodePacked(msg.sender))), "You are not in the list");

    uint256 senderBet = players[msg.sender];

    uint256 totalWinners = totalBetOne;
    uint256 totalLosers = totalBetTwo;

    if(winner == 2) {
      totalWinners = totalBetTwo;
      totalLosers = totalBetOne;
    }

    uint256 total = senderBet + ((senderBet / totalWinners) * totalLosers);

    (bool success, ) = msg.sender.call{value:total}("");

    require(success, "Transfer failed.");

    emit GainsClaimed(msg.sender, total);
  }
}

Let's discuss different sections of it in detail.

import "@openzeppelin/contracts/access/Ownable.sol";
import {MerkleProof} from "@openzeppelin/contracts/utils/cryptography/MerkleProof.sol";

This imports the OpenZeppelin Ownable contract and the MerkleProof utility. You must previously install those dependencies by running NPM install "@openzeppelin/contracts" --save-dev.
Our contract references the Ownable contract as we will use the onlyOwner condition in some methods.

contract Betting is Ownable {
  event GainsClaimed(address indexed _address, uint256 _value);

The contract will emit an event GainsClaimed when someone with valid proof claims the gains.

function setMerkleRoot(bytes32 root, uint8 team) onlyOwner public 
  {
    merkleRoot = root;
    winner = team;
  }

This is the method that we will call when the match finishes. We will pass the Merkle root computed from a tree with all the addresses that bet on the winner. We also pass the winner team. Also, note that this method is marked with the onlyOwner condition, so only the contract owner can set the root.

function getPlayersBetOne() public view returns(address[] memory) {
    return playersBetOne;
  }

  function getPlayersBetTwo() public view returns(address[] memory) {
    return playersBetTwo;
  }

These two methods return a list of the addresses that bet on each team. We will use these lists to compute the Merkle Tree. As these are views, they don't cost anything; they are simply resolved in our local ETH node.

function bet(uint8 team) public payable {
    require(team == 1 || team == 2, "Invalid team");

    require(!checkPlayer(msg.sender), "You bet on a game already");

    require(msg.value >= minimumBet, "Minimum bet is 1 gwei");

    require(merkleRoot == 0, "Bets are closed");

    if(team == 1) {
      playersBetOne.push(msg.sender);
      totalBetOne += msg.value;
    } else {
      playersBetTwo.push(msg.sender);
      totalBetTwo += msg.value;
    }

    players[msg.sender] = msg.value;
  }

The method for betting on a team accepts the team as an argument and does two things,

Push the address on the correct list (Team A or Team B)
Increases the total amount for the bet associated with the contract

function claim(bytes32[] memory proof) public {
    require(merkleRoot != 0, "No winner yet for this bet");

    require(proof.verify(merkleRoot, keccak256(abi.encodePacked(msg.sender))), "You are not in the list");

    uint256 senderBet = players[msg.sender];

    uint256 totalWinners = totalBetOne;
    uint256 totalLosers = totalBetTwo;

    if(winner == 2) {
      totalWinners = totalBetTwo;
      totalLosers = totalBetOne;
    }

    uint256 total = senderBet + ((senderBet / totalWinners) * totalLosers);

    (bool success, ) = msg.sender.call{value:total}("");

    require(success, "Transfer failed.");

    emit GainsClaimed(msg.sender, total);
  }
}

Finally, the method for claiming the gains on the game. This method requires proof, which was previously computed from a Merkle tree containing all the addresses in the winner's list. If someone passes an invalid proof, or a proof calculated from some other tree, the method will validate that and reject the call.

require(proof.verify(merkleRoot, keccak256(abi.encodePacked(msg.sender))), "You are not in the list");

This method uses the following formula to distribute the gains.

uint256 total = senderBet + ((senderBet / totalWinners) * totalLosers);

Generating the Merkle Tree

We will be using the merkletreejs and keccak256 from node.js with a Hardhat test suite to test our contract.

const { expect } = require("chai");
const { MerkleTree } = require('merkletreejs');
const keccak256 = require('keccak256');

describe("Betting", function () {
  let owner, addr1, addr2, addr3, addr4, addr5;
  let Betting, betting;

  beforeEach(async function() {
      [owner, addr1, addr2, addr3, addr4, addr5] = await ethers.getSigners();

      Betting = await ethers.getContractFactory("Betting");
      betting = await Betting.deploy();

      await betting.deployed();
  });

The code above deploys the contract and stores a few addresses provided by Hardhat in local variables so we can reference them later on in the tests.

it("Should allow claiming gains", async function () {
    await betting.bet(1, { value : 1e9 });

    await betting.connect(addr1).bet(1, { value : 1e9 })

    await betting.connect(addr2).bet(2, { value : 1e9 })

    const list = await betting.getPlayersBetTwo();

    const merkleTree = new MerkleTree(list, keccak256, { hashLeaves: true, sortPairs: true });

    const root = merkleTree.getHexRoot();

    await betting.setMerkleRoot(root, 2);

    const proof = merkleTree.getHexProof(keccak256(addr2.address));

    await expect(betting.connect(addr2).claim(proof))
      .to.emit(betting, 'GainsClaimed')
      .withArgs(addr2.address, 3e9);;
  });

The test above calls the "bet" method from three different addresses, giving a total of 3 gwei as the total balance. We also compute a Merkle tree from the list of addresses for team two (that's a single address, the address 2).
It also generates proof for address 2, and calls the "claim" method with that proof to claim the gains. Note that it's crucial to impersonate the calls with the correct address using the connect method, as many of the methods in our contract use the msg.sender variable.

The complete code is available in my github repository "merkletrees-smartcontracts"

Authorization Code Flow with PKCE in Azure AD with React

Cibrax — Thu, 22 Jul 2021 12:27:14 +0000

Authorization Code Flow with PKCE

The implicit authorization code flow was initially released for native/dumb and javascript applications running in a context of a browser that did not have a dedicated backend to negotiate an access token from an authorization server (due to a limitation in browsers that prevented JavaScript from making cross-domain calls) .

In this flow, access tokens were returned directly to the browser without requiring any client secret. These aspects made it naturally less secure, so additional practices were used to mitigate any potential vulnerability (e.g short lived tokens, pre-registered redirection URIs or a set of a unique nonce and state parameters in the URL)

Nowadays, most browsers support Cross-Origin Resource Sharing (CORS) so that cross-domain call limitation is not longer an issue. PCKE or Proof of Code Key Exchange leverages CORS in the browser to negotiate an access token in two steps.

A code is negotiated in the first step with the following request,

HTTP GET https://AzureADURL/authorize 
&response_type=code 
&redirect_uri=https://localhost:3000/login 
&scope=openid profile
&client_id=..... 
&code_challenge=......
&code_challenge_method=S256

And a second step is executed to get the actual access token,

HTTP POST https://AzureADURL/token
&code=.....
&client_id=.... 
&grant_type=authorization_code
&code_verifier=....
&redirect_uri=https://localhost:3000/login

The code returned in the first call is the result of a cryptographic algorithm computation (hash) from the code challenge and code challenge method arguments passed in the first call. The code is later validated in the second call takes the code with the code verifier argument.

Authorization Code Flow with PKCE in Azure AD

This authorization code flow was recently enabled in Microsoft Azure AD.

Microsoft also released an update of the Microsoft Authentication Library (MSAL) for javascript to support this flow, which is now called msal-browser.

As this library is still in beta, documentation and samples are hard to find. I used one of the Vainila JS starter samples to implement the reusable content provider for React that is shared as part of this article.

The application must be registered as any other regular app in Azure AD under App Registrations, but the the reply url must be set with the type "spa" as it is shown below,

"replyUrlsWithType": [
        {
            "url": "http://localhost:3000/",
            "type": "Spa"
        }
    ],

http://localhost:3000 is where the React application is running.

Context Provider Hook in React

In a typical React application, data/state is passed from top/parent to down/children components using properties, but this might not be ideal for cross-cutting corners that apply to all components or state that is shared between all of them. Security is one of those concerns, so it is a good candidate to be implemented as a context provider.

A context provider allows sharing state between components without explicitly passing it as properties through every level of the three. It would be equivalent to a global state that can be accessed on demand by the components.

React provides a hook "useContext" to inject a context with shared state in any component.

Context Provider for Azure AD authentication
The context provider I wrote for this article provides different accessors for state representing the current security context in the applications and functions for user authentication.

<MsalContext.Provider
            value={{
                isAuthenticated,
                user,
                token,
                loading,
                popupOpen,
                loginError,
                login,
                logout,
                getToken
            }}
        >
        {children}
</MsalContext.Provider>

There is a semantic difference between login/getToken and user/token. While login performs user authentication with Open ID/Connect for getting an ID token (the user information), getToken returns an access token for consuming a backend API.

The configuration passed to these two functions (login and getToken) is slightly different. One uses the "openid profile" scopes, and the other uses one scope defined by the specific api to be consumed.

// ID token request
export const loginRequest = {
    scopes: ["openid", "profile", "User.Read"],
    forceRefresh: false // Set this to "true" to skip a cached token and go to the server to get a new token
};

// Access token request.
export const apiRequest = {
    scopes: ["api://{API ID}/ReadWrite"],
    forceRefresh: false 
}
};

The entry point for using the new msal browser library is the PublicClientApplication object, which receives the configuration for connecting to Azure AD as part of the constructor.

export const config = {
    auth: {
        clientId: "{CLIENT ID}",
        authority: 'https://login.microsoftonline.com/{TENANT ID}',
        redirectUri: 'http://localhost:3000/',
    },
    cache: {
        cacheLocation: "localStorage", // This configures where your cache will be stored
        storeAuthStateInCookie: false, // Set this to "true" if you are having issues on IE11 or Edge


};
}

const pc = new msal.PublicClientApplication(config);

The following component shows how the context provider is imported and used to log in/out the user with two different buttons.

const Welcome = () => {
  const { user, logout, getToken, token, loginError } = useMsal();


  return (
    <div>
      <h1>Welcome {user.userName}</h1>
      {token && (<span>Your token is {token}</span>)}
      <br></br>
      <button onClick={() => getToken(apiRequest, "loginPopup")}>Get Token</button>
      <br></br>
      <button onClick={() => logout()}>Log out</button>
      <br></br>
      {loginError && (<span>Error: {loginError.message}</span>)}
    </div>
  );
};


export default Welcome;

Full source code for this sample

The full source code for this context provider and sample is available in Github.

Role Based Authentication for .NET Core APIs with Auth0

Cibrax — Thu, 22 Jul 2021 12:25:07 +0000

Auth0 offers two alternatives for implementing authorization in an API, scopes and roles.

Scopes represent access levels that an API exposes and users can grant to client applications on his/her behalf. For example, "read emails" or "write calendar", which gives a client application permissions to read the user's emails o write the calendar.

On other hand, roles represent the old school for doing authorization. Users are assigned to roles that represent one or more permissions. Those permissions are passed to the API when the user invokes it through a client application. In Auth0, roles are configured through a feature called Role Based Access Control or RBAC in short.

It is worth mentioning that only scopes are mentioned as part of the OAuth 2.0 specification, and roles are usually implemented in proprietary ways by different vendors. As Auth0 uses JWT for representing access tokens, it relies on extension attributes for injecting the permissions for a role into the tokens. We will cover this more in detail later in this post.

For the API, we will use the one included as template with Visual Studio for .NET Core that returns the weather forecast.

Creating an API in Auth0

First step before jumping into any API implementation is to configure the API in the Auth0 dashboard.

Go the APIs and click on Create API

Under the settings tab, configure the following fields.

Name, a friendly name or description for the API. Enter *Weather Forecast API for this sample.
Identifier or Audience, which is a identifier that client application uses to request access tokens for the API. Enter https://weatherforecast.
Under RBAC settings, enable RBAC and Add Permissions in the Access Tokens**. This will be used by Auth0 to inject the user's permissions into the access tokens.

Under the permissions tab, add a new permission read-weather with a description It allows getting the weather forecast. This is the permission that Auth0 will inject in the JWT token if the user is member of any of the roles that are allowed to execute that operation.

Finally, click on the Save button to save the changes. At this point, our API is ready to be used from .NET Core.

Adding a new role in Auth0

Under User & Roles, click on Create Role to define a new Role for our API.

On the *Settings tab, enter *meteorologist as role name and description.

On the Permissions tab, click on Add Permissions, select our Weather Forecast API* from the dropdown, and **read-weather as permission. Click on *Add Permissions

Assign the role to existing users

As final step for the API configuration in Auth0, we need to assign the meteorologist role to any of the users you will be using for testing the API. If you do not have one yet, you will have to create it and assign it to this role.
Roles are assigned by clicking on the ellipsis button ... available on each user in the list, and selecting Assign Roles option from the displayed menu.

Anatomy of the JWT access token

If everything is configured correctly, any access token issued by Auth0 for our API should look like the one below,

{
  "iss": "https://....us.auth0.com/",
  "sub": "auth0|...",
  "aud": "https://weatherforecast",
  "iat": 1621346933,
  "exp": 1621354133,
  "azp": "nW5WUNks1eQgHZB0oyc9183NNILpsWMe",
  "scope": "",
  "permissions": [
    "read:weather"
  ]
}

Scopes are not required when requesting an access token for an API configured with RBAC. Only the audience must be passed to Auth0, which is https://weatherforecast in our sample.

Create the ASP.NET Core API in Visual Studio

Visual Studio ships with a single template for .NET Core APIs. That is ASP.NET Core Web API as it is shown in the image below.

The structure of the project

Projects created with that template from Visual Studio will have the following structure.

Controllers, this folder contains the controllers for the API implementation.
Startups.cs, this is the main class where the ASP.NET Core Middleware classes are configured as well as the dependency injection container.

Configuring the project

Our application will only use a middleware for supporting authentication with JWT as bearer tokens.

Open the Package Manager Console for Nuget in Visual Studio and run the following command.

Install-Package Microsoft.AspNetCore.Authentication.JwtBearer

Once the Nuget packages are installed in our project, we can go ahead and configure them in the Startup.cs class.

Modify the ConfigureServices method in that class to include the following code.

public void ConfigureServices(IServiceCollection services)
{
  var authentication = services
    .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer("Bearer", c =>
    {
       c.Authority = $"https://{Configuration["Auth0:Domain"]}";
       c.TokenValidationParameters = new TokenValidationParameters
       {
         ValidateAudience = true,
         ValidAudiences = Configuration["Auth0:Audience"].Split(";"),
         ValidateIssuer = true,
         ValidIssuer = $"https://{Configuration["Auth0:Domain"]}";
       };
  });

  services.AddControllers();

   services.AddSwaggerGen(c =>
   {
     c.SwaggerDoc("v1", new OpenApiInfo { Title = "Api", Version = "v1" });
   });

   services.AddAuthorization(o =>
   {
     o.AddPolicy("read-weather", policy => 
       policy.RequireClaim("permissions", "read:weather"));
    });
}

This code performs two things. It configures the JWT middleware to accept access tokens issued by Auth0, and an authorization policy for checking the permissions set on the token.
The policy checks for a claim or attribute called permissions with a value read:weather, which is the permission we previously configured for our API in the Auth0 dashboard.
The middleware configuration relies on some settings that we will configure later in the appSettings.json file associated to the application.

Next step is to modify the Configure method to tell ASP.NET Core that we want to use the Authentication And Authorization Middleware.

Insert the following code as it shown below.

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
...
  app.UseRouting();

  app.UseAuthentication();

  app.UseAuthorization();

...
  app.UseEndpoints(endpoints =>
  {
    endpoints.MapControllers();
  });
}

Create a new appSettings.json file and include the settings we got from the Auth0 dashboard before. Those are Domain, and API's Audience.

{
  "Logging": {
      "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
      }
    },
  "AllowedHosts": "*",
  "Auth0": {
    "Domain": "<domain>",
    "Audience": "https://weatherforecast"
  }
}

Require authentication in other controllers

The WeatherForecast controller included in the template allows anonymous calls. We will convert it to require authenticated calls. Fortunately, that is as simple as adding a top level [Authorize] attribute in the class definition. That attribute will also reference the policy we previously defined in the Startup.cs file.

[ApiController]
[Route("[controller]")]
public class WeatherForecastController : ControllerBase
{
  [HttpGet]
  [Authorize("read-weather")]
  public IEnumerable<WeatherForecast> Get()
  {

This attribute will do two things,

It will activate the Authorization Middleware that will check if the call was authenticated and there is one user identity set in the current execution context.
It will run the read-weather policy to make sure the user identity contains the required permissions.

Once we ran this project in Visual Studio, the API will only accept authenticated calls with JWT tokens coming from Auth0.

Summary

We discussed two of the authorization alternatives available for you in Auth0 when implementing an API in .NET core, and selected RBAC for our sample. We also showed how to configure the ASP.NET Core Middleware for Authentication and Authorization, and how to use Authorization Policies for checking permissions on the JWT bearer tokens.
In a next post, we will see how to implement a client application that negotiates access tokens from Auth0 to consume this API.

Developing a Dapp in Ethreum with Social Authentication using Next.js and Next-Auth-js

Cibrax — Thu, 22 Jul 2021 12:21:40 +0000

Developing a Dapp in Ethreum with Social Authentication using Next.js and Next-Auth-js

My last article 101 Smart Contracts and Decentralized Apps in Ethereum discussed all the introductory concepts for developing Smart Contracts and Decentralized Applications in Ethreum.

This article is focused on implementing a concrete sample that includes Smart Contracts and a Decentralized Application (DApp) written with Next.js.

The smart contracts in this article include a custom ERC-20 token and a Faucet. Don't worry if you don't know what those are. I am planning to give a short overview first.

ERC-20

The acronym ERC stands for Ethereum Request for Comments. Those are Application-Level standards and conventions for Smart Contract development in Ethereum. They are available here.

Any new standard related to Smart Contract development (e.g., new tokens, wallet formats) is proposed through an ERC draft and eventually approved and released on that site.

ERC-20 is the standard for fungible tokens. Fungibility is the ability of an asset to be interchanged for another of the same type. If you have a token of the type "FOO", you can change it for another of the same type without losing any value.

If you look into the specification, it is no other thing than an interface for a smart contract that represents a fungible token.

function name() public view returns (string)
function symbol() public view returns (string)
function decimals() public view returns (uint8)
function totalSupply() public view returns (uint256)
function balanceOf(address _owner) public view returns (uint256 balance)
function transfer(address _to, uint256 _value) public returns (bool success)
function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
function approve(address _spender, uint256 _value) public returns (bool success)
function allowance(address _owner, address _spender) public view returns (uint256 remaining)

event Transfer(address indexed _from, address indexed _to, uint256 _value)
event Approval(address indexed _owner, address indexed _spender, uint256 _value)

Suppose you take a Smart Contract and implement those methods using Solidity or any other language compatible with the Ethereum VM. In that case, your contract will adhere to the ERC-20 standard and can be considered a token.

Let's discuss those methods more in detail.

function name() public view returns (string)
function symbol() public view returns (string)

name and symbol are the name and symbol associated with the token. For example, a token "My Foo Token" with the symbol "FOO".

function decimals() public view returns (uint8)

Ethereum does not support decimals for amounts. Decimals is a workaround to express how many decimal positions a token supports. For example, 18 would mean a single token uses 18 zeros (1000000000000000000)

function totalSupply() public view returns (uint256)

It returns the total number/supply of available tokens.

function balanceOf(address _owner) public view returns (uint256 balance)

It returns the balance for a given address.

function transfer(address _to, uint256 _value) public returns (bool success)
function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)

These two allow transferring tokens from one address to another.

function approve(address _spender, uint256 _value) public returns (bool success)
function allowance(address _owner, address _spender) public view returns (uint256 remaining)

Approve allows allocating/lending some tokens to a third party (a different address, the spender). The owner of those tokens is taken from the sender address when the smart contract is invoked. This method is what we will use for our Faucet contract.
The other method, allowance returns the number of tokens allocated/lent to a given address by the owner.

As you can see, a fungible token never leaves this contract. The available supply and owners are all reflected and stored on it.

Minting vs. Mining

Minting and Mining are two terms often mention when talking about token issuance.
ERC-20 are not native tokens in the ETH Blockchain; smart contracts represent them, so you can not obtain those as part of the mining process. You can only mine Ether.
On the other hand, minting is about issuing ERC-20 tokens, and it's usually part of the internal implementation of the smart contract. The initial supply can probably be minted in the Smart Contract constructor and updated later by other methods.

A sample token

As part of this article, I decided to implement a fictitious token called "Cibrax". Here is the code.

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.4;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract CibraxToken is ERC20 {
    constructor(uint256 initialSupply) ERC20("Cibrax", "CIBRAX") {
        _mint(msg.sender, initialSupply);
    }
}

There isn't much to show here. I borrowed the ERC20 contract implementation from OpenZepellin and used that one as the base class for my contract. OpenZepellin distributes the contracts as a library via NPM.

You provide the token name and symbol as part of the constructor and call the base method _mint to specify the initial supply. My implementation takes the initial supply from the constructor when you run the initial deployment. Also, the default value for decimals is 18, but you can optionally override that one too.

Faucet

You might need tokens for paying gas or for any other operation in smart contracts. When you are in a production Blockchain, you can buy those or get them as rewards/fees from mining blocks. However, it does not make much sense to do the same in a testing network. Those networks provide Faucets, which are smart contracts for borrowing tokens. There is no standard for the implementation of a Faucet.
Here is a Faucet I implemented for the sample included with this article.

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.4;

import "@openzeppelin/contracts/access/Ownable.sol";

interface ERC20 {
    function transfer(address to, uint256 value) external returns (bool);
    function name() view external returns (string memory);
    event Transfer(address indexed from, address indexed to, uint256 value);
}

contract Faucet is Ownable {
    uint256 constant public waitTime = 30 minutes;

    ERC20 public tokenInstance;

    mapping(address => uint256) lastAccessTime;

    constructor(address _tokenInstance) Ownable() {
        require(_tokenInstance != address(0));

        tokenInstance = ERC20(_tokenInstance);
    }

    function requestTokens(address _receiver, uint256 tokenAmount) onlyOwner public {
        require(allowedToWithdraw(_receiver, tokenAmount));
        tokenInstance.transfer(_receiver, tokenAmount);
        lastAccessTime[_receiver] = block.timestamp + waitTime;
    }

    function allowedToWithdraw(address _address, uint256 tokenAmount) public view returns (bool) {
        if(tokenAmount > 3) {
            return false;
        }

        if(lastAccessTime[_address] == 0) {
            return true;
        } else if(block.timestamp >= lastAccessTime[_address]) {
            return true;
        }

        return false;
    }

    function tokenName() public view returns (string memory) {
        return tokenInstance.name();
    }
}

This contract works like a private Faucet, as only the owner can transfer tokens to other addresses. I did this on purpose, so we can assign our Dapp as owner of the Faucet and only allow transferring tokens from it. If someone wants to bypass the Dapp and send a transaction to this Smart Contract, it will be rejected.

contract Faucet is Ownable {

The contract inherits from the Ownable Smart Contract implementation from OpenZeppelin. This contract gives you access to a "onlyOwner" condition for methods, which means only the assigned owner can be invoke them. In our scenario, the Dapp will be the assigned owner.

constructor(address _tokenInstance) Ownable() {
        require(_tokenInstance != address(0));

        tokenInstance = ERC20(_tokenInstance);
    }

The constructor ties the Faucet to any Smart Contract implementation that provides a ERC20 interface. In our example, we will assign our Cibrax token. You provide the address of the ERC20 contract, which can not be the empty address (address(0)) for deploying new contracts.

 function allowedToWithdraw(address _address, uint256 tokenAmount) public view returns (bool) {
        if(tokenAmount > 3) {
            return false;
        }

        if(lastAccessTime[_address] == 0) {
            return true;
        } else if(block.timestamp >= lastAccessTime[_address]) {
            return true;
        }

        return false;
    }

It checks for different conditions before any token is giving away. You can not ask for more than three tokens or do multiple calls within 30 minutes. These are vague conditions, but it shows a purpose. They prevent someone from exhausting all your available tokens.

Testing our Smart Contracts

I decided to use the HardHat tools to compile, test the contracts, and deploy them in an emulator.

Hardhat uses ethers.js as the client library for connecting to a local ETH node, and Waffle as the testing framework.

describe("CibraxToken", function () {

    let owner, addr1, addr2, addr3, addr4, addr5;
    let CibraxToken, cibraxToken;
    let Faucet, faucet;

    before(async function() {
        [owner, addr1, addr2, addr3, addr4, addr5] = await ethers.getSigners();

        CibraxToken = await ethers.getContractFactory("CibraxToken");
        cibraxToken = await CibraxToken.deploy(1000);

        await cibraxToken.deployed();

        Faucet = await ethers.getContractFactory("Faucet");
        faucet = await Faucet.deploy(cibraxToken.address);

        await faucet.deployed();

        await cibraxToken.transfer(faucet.address, 500);
    });

    it("Deployment should assign a name", async function () {
        const name = await cibraxToken.name();
        expect(name).to.equal("Cibrax");
    });

    it("Deployment should assign a symbol", async function () {
        const name = await cibraxToken.symbol();
        expect(name).to.equal("CIBRAX");
    });

    it("Owner can transfer tokens", async function () {
        const amount = 100;

        const tx = await cibraxToken.transfer(addr1.address, amount)        ;

        const receipt = await tx.wait();

        const otherBalance = await cibraxToken.balanceOf(addr1.address);

        expect(amount).to.equal(otherBalance);
        expect(receipt.events?.filter((x) => {return x.event == "Transfer"})).to.not.be.null;
    });

    it("Faucet can transfer assigned tokens", async function () {
        const amount = 1;

        await faucet.requestTokens(addr3.address, amount);

        const balance = await cibraxToken.balanceOf(addr3.address);

        expect(amount).to.equal(balance);
    });

    it("Faucet returns token name", async function () {

        const name = await faucet.tokenName();
        expect(name).to.equal("Cibrax");

    });

    it("Faucet can not transfer more than assigned tokens", async function () {

        await expect(faucet.requestTokens(addr4.address, 5)).to.be.reverted;

    });

    it("Faucet can not transfer on consecutive calls", async function () {
        const amount = 1;

        await faucet.requestTokens(addr4.address, amount);

        await expect(faucet.requestTokens(addr4.address, amount)).to.be.reverted;

    });

    it("Faucet can transfer allowed tokens", async function () {

        const allowedAmount = 5;
        const amount = 1;

        await cibraxToken.approve(faucet.address, allowedAmount);

        await faucet.requestTokens(addr5.address, amount);

        const balance = await cibraxToken.balanceOf(addr5.address);

        expect(amount).to.equal(balance);
    });

});

The "before" method is used for test initialization. It deploys the ERC-20 and Faucet contracts, and obtains their address. The other methods describe the tests.

 it("Faucet can transfer allowed tokens", async function () {

        const allowedAmount = 5;
        const amount = 1;

        await cibraxToken.approve(faucet.address, allowedAmount);

        await faucet.requestTokens(addr5.address, amount);

        const balance = await cibraxToken.balanceOf(addr5.address);

        expect(amount).to.equal(balance);
    });

For example, the test above uses the "approve" method in our custom token to pre-assign or authorize some tokens to the Faucet (five tokens in total). To be clear, the tokens are not directly assigned to the Faucet, but it allows the Faucet to use them.
The Faucet later transfers one of those tokens to a ETH address (addr5), and the balance on that address is verified.

For compiling the contracts and running the tests, you can run these commands in a console.

npx hardhat compile
npx hardhat test

Dapp

The Decentralized App or DApp, in short, it's the visible layer for our Faucet.

It's implemented in Next.js and leverages Next-Auth.js for authentication with social providers.

The .env file is used to assign the address of the Faucet and private key to our application.

ETH_NODE_URL=http://127.0.0.1:8545/
ETH_FAUCET_ADDRESS=<address>
ETH_PRIVATE_KEY=<private key>

If you want to deploy the contracts in the local Hardhat emulator, you can run the script "cibraxtoken-deploy.js" under contracts/scripts. That script will return the address of the contracts. Also, Hardhat always uses the first address from the available accounts in the emulator for deploying the contracts, so you can take the private key from that account and configure it in the Next.js app.

User authentication

The main page in our application uses the Next-Auth.js react hooks for coordinating the sign-on process.

import Head from 'next/head'
import { TokenForm } from './components/TokenForm';
import { signIn, signOut, useSession } from 'next-auth/client'

export default function Home() {

  const [ session ] = useSession()

  return (
    <div className="flex flex-col items-center justify-center min-h-screen py-2">
      <Head>
        <title>Faucet with Social Auth</title>
        <link rel="icon" href="/favicon.ico" />
      </Head>

      <main className="flex flex-col items-center justify-center w-full flex-1 px-20 text-center">
      <p className="mt-3 text-2xl">

        You can use this Faucet to request Cibrax tokens
      </p>

      {session && <TokenForm session={session}/>}

      <p className="mt-3 text-2xl">
        {(session) ? 
          <button onClick={() => signOut()} className="shadow bg-blue-500 hover:bg-blue-400 focus:shadow-outline focus:outline-none text-white font-bold py-2 px-4 rounded">Logout</button> : 
          <button onClick={() => signIn()} className="shadow bg-blue-500 hover:bg-blue-400 focus:shadow-outline focus:outline-none text-white font-bold py-2 px-4 rounded">Login</button>
        }

    </p>  
      </main>
    </div>
  )
}

The useSession hook returns the existing user session if there is one. If no session is available, we can display the Login button and assign the signIn hook to it. This method will do the sign-on handshake with the social providers.

Smart Contract Calls

The integration with the Smart Contract is done server-side through an API.

import type { TransactionResponse } from '../types'
import type { NextApiRequest, NextApiResponse } from 'next'
import { getSession } from "next-auth/client"
import { ethers } from 'ethers';

import artifact from '../../contracts/Faucet.json';

const url = process.env.ETH_NODE_URL;
const privateKey = process.env.ETH_PRIVATE_KEY || "";
const faucetAddress = process.env.ETH_FAUCET_ADDRESS || "";

const provider = new ethers.providers.JsonRpcProvider(); 

const wallet = new ethers.Wallet(privateKey, provider);
const faucet = new ethers.Contract(faucetAddress, artifact.abi, wallet);

export default async function handler(
  req: NextApiRequest,
  res: NextApiResponse<TransactionResponse>
) {

  const session = await getSession({ req })

  if(!session) {
    res.status(401);
    return;
  }

  if(!req.body.address) {
    res.status(400);
    return;
  }

  await faucet.requestTokens(req.body.address, 1, {
    gasPrice: 25e9
  });

  res.status(200).json({ successful: true })
};

This API does two things,
It connects the Faucet contract using ether.js. The settings for connecting to the node are retrieved from the .env file.
It checks the user session from Next-Auth.js. If the user is not authenticated, it returns 401. Otherwise, it makes a call to the Faucet to transfer tokens.

Get and Run the code

The complete sample is available to download from this Github repository - social-faucet