omegaup / omegaup Goto Github PK

Según el día 4 de febrero van a migrar el sistema del LiveArchive a otro lado. Hay que volver a hacer el driver :'(

Alguien conoce a un buen logero?

Esta es la discusión hasta el momento:

• [Users] Qué opinan de guardar los passwords en BINARY(20) usando
  SHA-1 en lugar de CHAR(32) usando MD5?

Parece que si nos queremos poner paranoicos, bcrypt es la opción.. qué
opinan? http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

Aquí tengo que hacer una nota: hay que recordar que hay dos escenarios en
los que se va a usar la plataforma: en web normal y embebido. Si se puede
usar el BINARY, o su equivalente con H2 sin broncas, adelante :) y si no se
puede, pues total, usamos SHA-1 con CHAR(40), no hay problema :P

Según los docs de H2, dice que sí sabe tratar con BINARYs:
http://www.h2database.com/html/datatypes.html#binary_type

La idea de bajar a BINARY(20) es que gastas menos espacio (al menos a
la mitad) y comparas menos. Estoy de acuerdo con no optimizar
prematuramente, pero si eso no cuesta nada, creo que se puede hacer
desde ahorita.

El hashear lo hacemos en PHP. Había visto esta biblioteca:
http://www.openwall.com/phpass/ que dice saber bcrypt.

Implementar el backend necesario en PHP para /contests/ranking/:id

Implementar la parte de PHP de /contests

A alguien se le ocurre una forma sencilla de implementar badges? Tal que podamos ponerlo, en v1 con prioridad baja.

Lo más straightforward que se me ocurre es, por el momento, sólo hacer badges que se desbloqueen por resolver cierto subconjunto de problemas. Por ejemplo 'newbie', 'tree master', 'macs', etc... Así podemos tener una tabla de Badges, otra tabla de BadgesProbs y otra tabla de BadgesConcursante, y cada que un concursante resuelva un problema, buscamos si tiene algun badge asociado, revisamos que cumpla todos los requisitos del badge y se lo colgamos :).

Esta forma no incluye badges que se desbloqueen por resolver en tiempo récord un problema u estar hasta arriba en la tabla de los que resolvieron un problema por tiempo.. pero bueno, esos los podriiiamos hard-codear de ser necesario (no me gusta D: ).

Saludos!

Podemos avanzar sin esto.. don't worry... no hay tanta prisa, pero lo pongo en issues para que no se nos olvide :D

Necesitamos un CSR para el activar el certificado SSL. Parece que esta info se genera en el host que vayamos a ocupar, lhchavez se va a encargar de esto.
La info está aquí:
http://community.godaddy.com/help/article/5343 http://community.godaddy.com/help/5269

Implementar APi /logout en PHP

Sugerido por Pablo: No será mejor tener una tabla de jueces que se pueden
utilizar en lugar de que sea un enum (y si agregamos un juez, no hay
necesidad de modificar la estructura de la BD)?

Implementar en Scala la API /contests/:id/problem/:id

Implementar el frontend necesario en javascipr para mostrar /contests/:id/problem/new

Implementar el frontend de la API /contests/new

Copy-paste del mail original:

Que onda Alanboy, Zaiterska,
Ando montando omegaup beta en mi compu local. Me encontré con esta excepción al momento de loggearme. Mi BDD está vacía, así que si solo ocurre en esos casos que nunca van a pasar en el "live site" entonces ni se preocupen. Se las dejo por si creen que es relevante. Quieren que mejor la suba como issue al github? (sirve que lo organizo de una vez por todas :P ).

exception 'Exception' with message 'mysqlt error: [1048: Column 'email_id' cannot be null] in EXECUTE("INSERT INTO Emails ( email_id, email, user_id ) VALUES ( NULL, '[email protected]', '3');") ' in /Applications/XAMPP/xamppfiles/htdocs/omegaup/frontend/server/dao/base/Emails.dao.base.php:227 Stack trace: #0 /Applications/XAMPP/xamppfiles/htdocs/omegaup/frontend/server/dao/base/Emails.dao.base.php(51): EmailsDAOBase::create(Object(Emails)) #1 /Applications/XAMPP/xamppfiles/htdocs/omegaup/frontend/server/controllers/login.controller.php(62): EmailsDAOBase::save(Object(Emails)) #2 /Applications/XAMPP/xamppfiles/htdocs/omegaup/frontend/www/login.php(19): LoginController::login('joemmanuel@gmai...', 'https://www.goo...') #3 {main}

Alanboy:

Eso me huele a que en la base de datos no tiene email_id como autoincremento, dejame revisar.

La idea es relacionar usuarios directamente con permisos para poder asignar permisos directamente a un usuario.

Implementar la parte de Scala de /contests/ranking/:id

Implementar el frontend necesario en Javascript para enviar una solución a un problema /runs/new

Según mi análisis, es todo lo que falta en la BDD para soportar todos los features de la v1.
Pendiente instalarle Tiny ACL a la BDD.

Implementar en Scala lo necesario para enviar la solución a un problema /runs/new

Y de paso, cuando puedas (alanboy) dale una actualizada al server con el contenido de frontend/comingsoon, hay algunas actualiazciones, incluyendo la liga a blog.omegaup.com, el cual también tenemos que levantar :P

Implementar la parte de PHP de /contests/show/:id

Implementar el backend en PHP necesario para enviar una nueva solución a un problema /runs/new

Implementar la parte de Scala de /contests

Implementar /logout en Scala

Implementación del frontend de la API /login/ en javascript

Implementar el frontend necesario en Javascript para la API /contests/:id/problem/new

Creo que lo mejor será hacer una nueva tabla para guardar las redacciones, para de una vez tener soporte para las traducciones. Talvez podríamos ahí mismo guardar la(s) imagen(es) en un blob o guardar el link a un archivo.

Dijimos que un usuario puede tener multiples cuentas de correo, por eso de su correo principal y el de su escuela, etc. Pero ahorita no hay campos en la BD para manejar eso.

Implementación de /login en Scala para HappyMeal

Implementar el frontend necesario en Javascript para /runs/show/:id

Si el usuario tiene permiso, puede ver su solución y el estado de la misma (pending… grading… done… y la calificación).

Hay un FAQ en el frontend actual, pero no hay lugar en la BD para guardar su contenido!

Deben poderse editar:

• múltiples listas de correos
• correo principal (para que Gravatar muestre la foto)

Implementar la parte de Scala de /contests/new

Implementar la parte de Scala de /contests/show/:id

Implementar la parte de frontend en javascript de /contests/show/:id

Sugerido por Pablo.Aguilar
Source es la redacción del problema? Cómo se hace para
meter problemas que llevan imágenes en su redacción? O source es el

path de la redacción en el sistema de archivos?

Este campo está muy ambiguo. Revisé la documentación original https://github.com/omegaup/omegaup/wiki/Base-de-datos y parece que lo usaremos para que el autor escriba de donde sacó el problema.... jejeje.. qué nombre sugieren?

Implementar el frontend de /contests

Implementar la parte de frontend en Javascript de /contests/ranking/:id

Preparé una lista de los features priorizándolos, para su aprobación:
https://github.com/omegaup/omegaup/wiki/Features-list

En cuanto esto esté listo, prepárense a recibir (n+k)! mails de issues P0, cada uno correspondiente a un feature.

Primero averiguamos qué campos hay que poner.
Luego actualizamos la BD.

Implementación del frontend en Javascript del /logout de la arena.

Alanboy, tenemos pendiente esto :P para meterme a picarle a los controlers.
Salu2

Alan, nos acabamos de dar cuenta que cuando movimos los nameservers al alanboy's domain se murió gugul apps :P... Creemos que hay que aplicar los registros MX de tu lado, aquí está la info: http://www.google.com/support/a/bin/answer.py?hlrm=en&answer=33353

Salu2!

Debe soportar: usuarios propios, google auth, facebook auth

Implementar el frontend en Javascript de /contests/new

[Creo que esto es...]
Mostrar el banco de problemas, permitir que envíen y llevar estadísticas de cada usuario.

Implementar la parte de Scala de la API /contests/:id/problem/new

Implementar la parte del frontend en javascript de /contests/:id/problem/:id

Implementar el backend en PHP necesario de /contests/:id/problem/:id :

Si el usuario puede verlo, muestra el contenido del problema y referencias a las soluciones que ha enviado ese problema. Por el momento, propongo diferenciar los problemas que se esten usando en un concurso en vivo de los que son "estáticos" por la URI. Es decir, un problema en vivo siempre estará dentro de un concurso, es por eso que requiere su concurso/:id/... En cambio, un problema estático podrá ser accesado en un futuro solamente por /problems/:id,