Durante mi periodo de CEO en biblioeteca he tenido la necesidad de contratar personas que pudiesen ayudarnos con los proyectos que nuestros clientes nos proponían. En este mercado la rotación es muy alta y el talento (aunque cueste admitirlo) bastante escaso. Tampoco es que nosotros tengamos necesidades extraordinarias, y la mayor parte de nuestras contrataciones venían recomendadas de antes (eso siempre es lo mejor), pero cuando hay que cubrir puestos rápidamente es cuando nos encontramos en problemas.

Uno de los sitios a los que he acudido a ofrecer puestos de trabajo ha sido a LinkedIn, en concreto creo que conseguí un total de 4 personas (en un periodo largo), pero cada vez ha estado funcionando peor, os comento el ejemplo de la última campaña donde buscaba alguien con Java y Linux (y tampoco pedía años de experiencia). El anuncio en concreto está en este enlace:

https://www.linkedin.com/jobs/view/3517177902/

Para esta oferta recibí estos resultados:

Recibí un total de 7 cvs, de los que ninguno era adecuado del todo.

Pero hagamos unas pequeñas cuentas… 100 Euros de gasto, 96 visualizaciones, precio por visualización 1,04 Euros… ¡Por cada visualización! Esto, por si no os lo parece es carísimo. Calculemos que por cada 100 visualizaciones obtenemos 5cvs (1 de cada 20, esto es ser muy optimista), si de cada 10cvs obtenemos 1 al que entrevistar y que, de media, hay que entrevistar a 5 candidatos por puesto… Nos queda que necesitaríamos un mínimo de 5*10*20 = 1000 visualizaciones.

LinkedIn ¿me quieres decir que para contratar un programador (que tampoco busco un experto) tengo que gastarme 1.040 Euros?

A mi esto me ha parecido un error, y como tal se lo he preguntado a la amable gente de linkedin en twitter…

Qué majos! .. Vamos a ello…

Umm, no es ninguna de esas opciones, vamos a abrir incidencia

Vamos a ver que mi pregunta NO es sobre LinkedIn ADS, que de eso no tengo cuenta.. A ver si hay otra forma…

Pues no, no ayuda la verdad…

Y esto tampoco… ¿Cómo que las visitas disminuyen con el tiempo? Oye, que os habéis comido 100 pavos en dos días y solo me habéis dado 96 visualizaciones… Algo pasa

Y chin-pum ahí se acaba la interacción con la ayuda de linkedin… plasplasplas

Así que, si me preguntáis a mi, LinkedIn ha dejado de ser un sitio asequible para poner anuncios de trabajo…

O, mejor dicho, como probar tus APIs que usen JWT en postman.

Cuando estamos diseñando APIs es muy normal que, lo primero, las diseñemos sin pensar en el tema de la seguridad y, una vez que están funcionando, ya les añadimos los elementos de seguridad para que no puedan ser llamadas por cualquiera en producción.

Una forma, que yo he usado mucho, para fortificar las llamadas es hacerlo mediante un token que se ha obtenido con las credenciales de un usuario concreto, eso supone hacer una llamada previa al sistema del que se obtiene el token y, después, verificarlo en cada llamada. Esto, siendo un token arbitrario, supone sobrecargar el sistema de seguridad con llamadas de comprobación de token, además, tenemos que hacer caducar los tokens periódicamente ya que cualquier filtración del mismo da acceso a los recursos del usuario durante el tiempo que el token esté sin caducar.

Otra manera, ligeramente diferente, es utilizar JWT (JSON Web Tokens) que se diseñaron para poder transmitir credenciales y otra información entre sistemas de una manera más eficiente y segura. Lo único un poco «especial» es que tiene que haber un secreto compartido entre los sistemas que se comunican. Además, se usa ese secreto para firmar la comunicación, así que no es sencillo generar el token JWT de forma manual para las pruebas.

Si usas postman (que es lo que estoy usando yo últimamente) para hacer las pruebas, hay una manera de solventar el problema y que, básicamente, pasa por rellenar el campo pre-request script con este código:

// JWT generation script adapted from
// https://gist.github.com/corbanb/db03150abbe899285d6a86cc480f674d

var jwtSecret = pm.environment.get('jwt_secret') || ''

// Set headers for JWT
var header = {
	'typ': 'JWT',
	'alg': 'HS256'
};

// Prepare timestamp in seconds
var currentTimestamp = Math.floor(Date.now() / 1000)

var data = {
	'iss': pm.environment.get('jwt_iss') || '',
	'ist': pm.environment.get('jwt_ist') || '',
	'iat': currentTimestamp,
	'exp': currentTimestamp + 30, // expiry time is 30 seconds from time of creation
	'jti': 'jwt_nonce'
}


function base64url(source) {
    // Encode in classical base64
    encodedSource = CryptoJS.enc.Base64.stringify(source)
    
    // Remove padding equal characters
    encodedSource = encodedSource.replace(/=+$/, '')
    
    // Replace characters according to base64url specifications
    encodedSource = encodedSource.replace(/\+/g, '-')
    encodedSource = encodedSource.replace(/\//g, '_')
    
    return encodedSource
}

// encode header
var stringifiedHeader = CryptoJS.enc.Utf8.parse(JSON.stringify(header))
var encodedHeader = base64url(stringifiedHeader)

// encode data
var stringifiedData = CryptoJS.enc.Utf8.parse(JSON.stringify(data))
var encodedData = base64url(stringifiedData)

// build token
var token = `${encodedHeader}.${encodedData}`

// sign token
var signature = CryptoJS.HmacSHA256(token, jwtSecret)
signature = base64url(signature)
var signedToken = `${token}.${signature}`

pm.environment.set('jwt_signed', signedToken)
console.log('Signed and encoded JWT', signedToken)

En el mismo vemos que se usan estas variables que deberemos incluir en el entorno o en la petición:

• jwt_secret : secreto compartido con el otro sistema
• jwt_iss: issuer (como queramos identificar al emisor)

En cualquier caso también podríamos añadir el campo sub si es parte del payload que recibe nuestro API, o cualquier otro campo adicional que decidamos incluir, ya que el proceso de firma se realiza en ese momento y las fechas de expiración se actualizan justo antes de lanzar la petición al API por lo que no estarán expiradas en las pruebas.

Lo único que quedaría pendiente sería usar el token generado en la cabecera (o donde corresponda) ya que este código genera la variable {{jwt_signed}} esta la podemos usar donde queramos.

Sigo buscndo formas más sencillas para hacer las pruebas sin salir del Visual Studio Codel, si las encuentro las pondré por aquí.

Recientemente he tenido un proyecto de página web que funcionaba perfectamente cuando se hacía directamente en el navegador, pero cuando intentaba meter el contenido en un iframe para integrarlo con otra parte de la web no conseguía que se mantuviese la sesión. Esto, además de un malestar insidioso, me produjo curiosidad, ya que hacía mucho que no utilizaba iframes y, parece, que la forma en que tratan estos ha cambiado un poco con las últimas versiones de los navegadores.

Aunque podría deciros la solución ya mismo, vamos a darle un poco de dramatismo y os voy a explicar porqué un iframe no se comporta exactamente igual que la navegación en el browser y como eso hace que puedas perder la sesión.

¿Cual es la diferencia?

Un iframe no es más que un marco que se inserta dentro de una página web y cuyo contenido es cargado de una dirección distinta de internet, eso tiene la ventaja de que puedes enriquecer la página con contenido que no tienes que generar desde tu servidor, o que puedes reaprovechar cosas que ya tienes hechas en otros sistemas y el usuario podría no notar que esa parte del contenido proviene de otro sitio. Precisamente por este detalle (que los usuarios no son conscientes de donde viene ese contenido) se abren posibilidades de ataques Cross Site Request Forgery (CSRF), que significa que podrían recuperar una cookie de un dominio distinto desde una iframe, por ejemplo, y secuestrar la sesión original o cualquier credencial de usuario que viaje con las cookies.

Precisamente para evitar estos ataques en 2016 se estableció un atributo para las cookies (SameSite) que prevenía que se pudieran enviar cookies a dominios distintos de los que se estaba navegando (de lo que veíamos en la barra de navegación). Los posibles valores de estos atributos son:

• None: las cookies se mandan a todos los dominios.
• Strict: Las cookies solo se enviaran al dominio que coincide con el de la barra de direcciones
• Lax: Las cookies se enviarán al contexto principal y con las navegaciones de primer nivel.

Antes de tener este atributo todas las cookies eran tratadas como si fuese None y los iframes podían recibir las cookies (entre ellas las de sesión), pero a partir de que los navegadores adoptaron el atributo, la cosa cambió y ahora si la cookie no declaraba el SameSite se consideraba que este era del tipo Lax y esto hace que la navegación dentro de un iframe que está en otro dominio no pase las cookies.

¿Cómo arreglarlo?

Básicamente lo único que tienes que hacer (esto ya depende mucho del framework que tengas) es declarar las cookies con este encabezado:

Set-Cookie: session=your_session; SameSite=None; Secure

Con esto declaramos que las cookies podrán ser retransmitidas, pero además que solo se transmitirán a dominios seguros (con https). Esta pequeña modificación hace que se pueda navegar ya dentro del iframe, pero, ¡cuidado! te añade un potencial problema de seguridad CSRF.