Make the encoding API more type-safe

Abierto
  • ¿Algo no está bien?
#403 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
rust
Área
authentication, security

Línea de trabajo

El issue identifica Header, EncodingKey y encode como la API afectada; empieza por localizar sus definiciones y el algoritmo actual en tiempo de ejecución y las comprobaciones de claves. Se considera terminado cuando las familias de algoritmos incompatibles se rechacen en tiempo de compilación, mientras la API genérica propuesta siga siendo utilizable para los flujos de encoding compatibles.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Hi!

The current API allows writing encoding code with a key that does not match the algorithm used, e.g.

let header = Header { alg: Algorithm::RS256, ..Default::default() };
let encoding_key = EncodingKey::from_secret("shared_secret".as_bytes());
let token = encode(&header, &claims, &encoding_key);

This results in an error because the key type does not match the algorithm family.
This kind of error could be caught at compile time.

My proposal is to change the crate's API to catch this kind of error at compile-time instead of runtime, by moving from an enum-based checking to a type-based system.
Here is an overview of the proposed changes:

  • Each algorithm family becomes a separated enum.
  • the Header struct is changed to Header<AF>, taking its algorithm family enum as type parameter, with an algorithm: AF data member.
  • similarly, the EncodingKey struct is changed to EncodingKey<AF>, with AF recorded in a PhantomData member.
  • the encode function's signature is changed to something like
pub fn encode<T: Serialize, AF>(header: &Header<AF>, claims: &T, key: &EncodingKey<AF>) -> Result<String>

With this approach, code using a key for the wrong algorithm family will no longer compile, and we can get rid of some runtime checks.
On the other hand, you can no longer implement FromStr for all algorithms families at once. But since one needs to call a different function to generate the key depending on the algorithm family, I don't think this is a huge problem.

Would you be interested in a PR implementing this proposal?

Lenguaje dominante
Rust
Estrellas
2.1k
Forks
375
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Keats/jsonwebtoken

Todos los issues de Keats/jsonwebtoken

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.