@@ -33,11 +33,9 @@ Este link es usado para subir los datos a enviar, pero obligatoriamente debe est
- Crear una llave simétrica AES
- Encriptar los archivos con la llave simétrica
- Encriptar la llave simétrica con la llave pública dada por el servidor
- Enviar los archivos encriptados con cualquier nombre y la llave encriptada en formato de archivo con el nombre 'key' (somename=@data.file, key=@key.file)
- Enviar los archivos encriptados con cualquier nombre y la llave encriptada en formato de archivo con el nombre 'key' (nombre=@data.file, key=@key.file)
Si no se envía una llave se presume que el archivo no está encriptado.
/data devuelve un id que corresponde al mensaje, se usa en el siguiente paso.
donde "nombre" será el nombre utilizado para el archivo. Si no se envía una llave se presume que el archivo no está encriptado. /data devuelve un id que corresponde al mensaje, se usa en el siguiente paso.
Aclaración: el Content-Type debe ser multipart/form-data
...
...
@@ -46,9 +44,10 @@ Aclaración: el Content-Type debe ser multipart/form-data
Llamando a este link se envían los parámetros de envío del mensaje pasado en data, y se procede a poner en la cola el mensaje. (POST)
- Bajo 'id' se envía el id devuelto en el paso anterior
- Bajo 'serv' se envía el servicio a usar, por ahora solo hay 'wpp1' correspondiente a WhatsApp
- Bajo 'dest' se envía el número de destino, el formato puede variar dependiendo del servicio y dicho formato será documentado, el de 'wpp1' es el formato internacional sin el '+' y sin espacios ni guiones
- Bajo 'type' se envía un json { archivo : tipo }, donde a cada archivo se le asigna un tipo
- Bajo 'serv' se envía el servicio a usar
- Bajo 'dest' se envía la dirección de destino, el formato puede variar dependiendo del servicio y dicho formato será documentado
- Bajo 'type' se envía un json { archivo : tipo }, donde a cada archivo (a través del nombre del paso anterior) se le asigna un tipo válido para el servicio
- Bajo 'info' se envía un json { parámetro : valor }, donde se asignan parámetros específicos del servicio
En caso de que no exista el servicio o este no admita el tipo, o que el id no exista, se devolverá un mensaje de error con esa información. Caso contrario, se devolverá el string 'queued' desmotrando que todo salió bien y que el mensaje está en cola.
...
...
@@ -86,10 +85,11 @@ En el método
```
data es un dictionario que contiene los datos del pedido guardados en la base de datos
- En 'id' está el id del pedido, que coincide con el nombre del archivo a mandar
- En 'id' está el id del pedido en la base de datos, este debería ser irrelevante a la operación
- En 'path' está el nombre del directorio bajo el cual se encuentran los archivos a enviar
- En 'dest' se encuentra el destinatario
- En 'type' se encuentra el formato de lo que queremos mandar
- En 'info' se encuentran los parámetros específicos del servicio, su obligatoriedad depende del servicio
- En 'state' se encuentra el estado del mensaje, que siempre será 'queued' y es completamente irrelevante a la operación
La función retorna un booleano del resultado.
...
...
@@ -97,11 +97,20 @@ La función retorna un booleano del resultado.
El método
```
@abstractmethod
def validate(self,datatype):
def validatetype(self,type):
pass
```
toma un string correspondiente al formato de los datos y retorna un booleano correspondiente a si el servicio soporta o no el tipo de dato. Es una buena práctica usar `Datatypes.validate()` para chequear que el formato existe.
toma un string correspondiente al formato de los datos y retorna un booleano correspondiente a si el servicio soporta o no el tipo de dato.
El método
```
@abstractmethod
def validateinfo(self,info):
pass
```
toma un JSON con los parámetros del servicio y retorna un booleano correspondiente a si son válidos
## Archivos
...
...
@@ -134,16 +143,5 @@ Para testear se debe tener una carpeta llamada 'testfolder' donde poder tirar lo
## Mejoras no implementadas
1. Añadir mas información a los mensajes de mail.
2. Test de mensajes de error.
3. Añadir estado "partially delivered" para mensajes enviados a medias.
4. Cambiar id de /data a string (posiblemente el nombre de la carpeta)*.
5. Posibilidad de usar un emisor de mensajes diferente.
*Esto, si bien es un golpe duro en performance, porque la búsqueda O(LogN) en base de datos se vuelve O(N), es un incremento sustancial en seguridad, puesto que nadie accidentalmente puede enviar parámetros a mensajes que no son suyos o consultar el estado de un mensaje enviado ajeno y borrarlo, volviéndolo inconsultable.
### Soluciones que pensé
1. Cambiar la tabla "type" a "info" (o simplemente agregar como tabla separada) y que el json acepte parámetros de todo tipo específicos de cada servicio.
4. Remover por completo la noción de id numérico y que el comparador para los updates se vuelva el path
5. Agregar una tbla "sender" y que tenga "default" o algún otro que se prefiera.
\ No newline at end of file
1. Añadir estado "partially delivered" para mensajes enviados a medias.
2. Posibilidad de usar un emisor de mensajes diferente. (hecho parcialmente)
