Vuestra opinión sobre el API XML-RPC de una aplicación

[dec]

Hola,

Yo sigo aquí un poco a mi bola, lo reconozco. En esta ocasión me gustaría comentaros cómo pienso implementar el método "EnlacesUsuario", mejor dicho, cómo he pensado implementarlo, para que me podáis dar vuestra opinión si lo creéis conveniente. ¿Eh? Pues eso.

El método "EnlacesUsuario" trataría de retornar los enlaces de un determinado usuario de Loturak, de modo que pudieran listarse en una aplicación, por ejemplo. Mi idea es no retornar todos los enlaces al mismo tiempo, puesto que no existe límites para los enlaces que un usuario puede albergar, la consulta en cuestión podría costar más de la cuenta.

Así que me planteo utilizar la cláusula "LIMIT" de MySQL, de modo que el método "EnlacesUsuario" retorne los datos de los enlaces de un usuario poco a poco, de veinte en veinte, he pensado, de diez en diez, acaso, pero, claro, me atrapan algunas dudas, porque al cabo "más peticiones" pueden acaso ser tan costosas como una consulta "grande".

Esto último creo que no es del todo así. Me explico. No se trata de que en el primer caso pudiera darse una consulta "grande", es que podría darse una consulta "verdaderamente grande". Es decir, una consulta que retornara los miles de enlaces... pasaría de grande para considerarse algo desorbitado, desaconsejable al cien por cien.

Entonces, teniendo claro que el método "EnlacesUsuario" debe retornar los enlaces "poco a poco" hay que meter mano a este asunto y se me ocurre lo siguiente. El método recibiría un Array de datos como único parámetro, como en los métodos "InsertarEnlace" y "ActualizarEnlace". Los elementos de dicho Array numérico, por cierto, podrían quedar tal que así, por orden:

- string Login del usuario
- string Contraseña del usuario
- integer Límite inferior para la consulta de enlaces

Una vez el usuario sea autentificado contaremos con su correspondiente ID de usuario. Es decir, la idea sería terminar conformando una consulta SQL como la siguiente (utilizo el * por abreviar):

Código SQL [-]
SELECT * FROM enlaces 
WHERE (enlace_id_usuario = $idUsuario)
ORDER BY enlace_fecha DESC, enlace_titulo ASC
LIMIT $limiteInferior,20;

O sea, que el método "EnlacesUsuario" retornaría 20 enlaces del usuario a partir del límite inferior que se indique. La primera llamada al método, los primeros 20 enlaces, se conseguirían indicando como límite inferior "0", los 20 siguientes se obtendrían indicando como límite inferior "20", los siguientes 20 enlaces indicando como límite inferior "40" y así sucesivamente.

Ahora bien, ¿cómo véis vosotros todo esto? ¿Os parece la mejor forma de implementar el método "EnlacesUsuario"? ¿Tal vez tengáis alguna idea de cómo podría mejorarse el asunto? Cualquier cosa que se os ocurra será bienvenida y se agradece desde ya mismo. O sea. Sabed que cualquier otro comentario en relación a lo que tratamos en este Hilo sería igualmente bienvenido: añadir un método que consideréis puede dar juego, sugerencias, comentarios, críticas, lo que queráis.

En fin. Eso es todo por el momento. Gracias a todos otra vez. Que paséis un buen fin de semana.

PD. Seoane, si has llegado hasta aquí y esto lees, coméntame qué te parece del ejemplo que he añadido basándome (je, je, je) en el código que más arriba publicaste. Ya sabes que si quieres que añada cualquier referencia, que quite algo, que añada cualquier cosa, no tienes más que decirlo.

[[seoane]]

Empezado por dec

PD. Seoane, si has llegado hasta aquí y esto lees, coméntame qué te parece del ejemplo que he añadido basándome (je, je, je) en el código que más arriba publicaste. Ya sabes que si quieres que añada cualquier referencia, que quite algo, que añada cualquier cosa, no tienes más que decirlo.

Si llegue hasta aquí. Y estoy esperando ese nuevo método, ya estoy imaginando una aplicación, con un icono quizá en la bandeja del sistema, y por supuesto standalone, que se pueda llevar en un usb y ejecutándola en cualquier equipo nos permita ver una lista con nuestros enlaces ... aunque quizá tenga que planearla un poco mas.

En cuanto a lo de agregar el código a tus ejemplos, la verdad me siento abrumado, solo era una pequeña diversión y vas tu y lo colocas en tu web . Estoy encantado de que me menciones en tu pagina, por mi perfecto. Solo comentarte que con las prisas en la unidad Hash me olvide de borrar la función SHGetFolderPath que no uso para nada, pero con esto de cortar y pegar .... Y el ejemplo me parece bien, como no tengo el componente TSpinEdit tuve que colocar el puerto fijo, y me fije que tienes por defecto la dirección localhost y una Uri que me supongo es local y que usas para las pruebas. Por el resto, esta bien, todo lo bien que le permite mi chapuza de código

[dec]

Hola,

A ver. Gracias por vuestros comentarios. De veras que son muy útiles para continuar adelante. Vayamos por partes, pues, como dijo Jack el destripador.

Empezado por Mario

Date una vuelta por http://ma.gnolia.com/ que me parece tiene un buen API.

Lo haré Mario. Gracias.

Empezado por Mario

1- Podrias usar mejor un API-KEY que un clave y usuario.

Bueno. Efectivamente, he pensado en algo parecido a lo que dices. Es decir, restringir un poco el uso que pueda hacerse de la API. Esto no es lo único en Loturak que me preocupa por lo mismo. Me explico. Al exportar enlaces, por ejemplo, en del.icio.us se toman su tiempo, se ve que porque tienen mucho tráfico (muchos usuarios, cientos de miles, creo) y ese tipo de tareas no pueden hacerse ipsofacto o es mejor hacerlo "cuando se pueda", "poco a poco".

En en el caso de Loturak no se da límite a la hora de importar enlaces, ni tampoco al exportarlos, y esto me preocupa. No acuciantemente, porque Loturak no es demasiado utilizada y el usuario que más enlaces tiene cuenta con unos 600. Con estas cifras, la importación y exportación de enlaces es plausible hasta el momento, a lo menos con las pruebas que he ido realizando en este sentido.

Lo que se me ha ocurrido últimamente sobre esto es no limitar el número de enlaces que puede tener un usuario, pero sí los que puede importar y exportar "de un golpe"; pienso en una cifra razonable, digamos de 500 a 1.000 enlaces. En fin. Es algo que todavía está verde y para lo que también acepto vuestras sugerencias, si véis otra forma de burlar este problema, si no lo véis un problema, etc.

Respecto del API ocurriría algo parecido. Habría que limitarla o controlarla de algún modo, no ahora, porque no tendrá mucho uso (de hecho las pruebas las realizo casi todas "en local", y mi deseo sería que quien probase la API o se planteara realizar una aplicación hiciera lo mismo: instalara Loturak (¡ajá!) en su sistema e hiciera las pruebas allí mismo. Al fin y al cabo Loturak se comportará igual "en local" que en el Sevidor, y así las pruebas "en local" serán perfectamente "válidas", pueden servir perfectamente.

Empezado por Mario

Es lo que mas se usa en este tipo de servicios, y entre otros una razon es que las comunicaciones no estan protegidas (no creo que lo tengas por SSL) y estaria comunicandose un dato PERSONAL y PRIVADO plano por Internet.

Pues, efectivamente, la conexión no es "segura" en el sentido que mencionas. No se hace uso de SSL (Secure Socket Layer). Empero, aunque efectivamente los datos del enlace viajan "en limpio", no así la contraseña del usuario. De esta tiene que entregarse al Servidor su "doble MD5". Este es el modo en que guardamos las contraseñas en Loturak: guardamos su "hash" MD5 por duplicado. De todos modos, es cierto que se envían en claro los datos del enlace y si me apuras el "login" del usuario.

Empezado por Mario

Ya por esto, no me suena usar tu API.... y eso que estaba esperando a ver si lo liberabas pa' pensar como interlazo www.paradondevamos.com (que ya lo tengo listo para auto-ingresar en magnolia y enlaces manuales a digg y otros)

Bueno. Loturak (...) es una aplicación (me encanta verlo así) que sirve a los usuarios registrados para almacenar y gestionar los enlaces (URLs) que consideren oportunos. El hecho de que estos enlaces se puedan compartir siempre lo he visto como algo secundario. Es decir, no hace falta ser usuario de Loturak para usar la aplicación, de algún modo, puesto que puedes visitar la página Web y descubrir qué enlaces comparten los "loturakitas".

En todo caso la API está muy, muy verde aún. Seoane dice que se atreve a hacer algo con ella... es posible que a mí también se me ocurriera algo, pero, reconozco que aún le queda mucho a ese API para que pueda ser considerado algo más o menos digno de llamarse así. Para eso estoy aquí, entre otras cosas, para ver qué pensáis vosotros, como programadores, que podría añadirse a dicho API para que diera cierto juego y pudieraservir de algo a alguien.

Quiero decir que te sientas libre, Mario, de indicarme qué le falta, según tú, al API en ciernes, porque, seguramente serán cosas interesantes que acaso convenga tener en cuenta. Ahora, el que para usar determinados métodos del API sea preciso usar un usuario y una contraseña... es necesario, por las características de la aplicación. Piensa en un cliente de correo electrónico, que ha de solicitar al usuario su dirección de correo y su contraseña, pues, ¿cómo sino iba a llevar a cabo su trabajo de gestionar el correo? Guardando todas las distancias, claro.

Empezado por Mario

2- No le veo el sentido a poner Hola Mundo.

Digamos que es un método más o menos económico de realizar una prueba de disponibilidad al Servidor de Loturak. Así lo veo yo, vamos.

Empezado por Mario

3- No veo reglas de spam!!!

No especificas que tantas comunicaciones por cliente permite tu servicio, y por ende, no creo que le hayas puesto un limite.

Todos los demas API tienen algun limite (como solo 1000 hits por dia o algo asi) por una razon de sano juicio: Estas implementando un backdoor que puede ser facilmente abusado por un spammer.

Te falto que politicas gobiernan tu servicio...

Bueno. Supongo que sobre esto he comentado arriba algo, empero, no te quito la razón. Habría que mirar por proteger de algún modo a la aplicación. ¿Se te ocurre algo?

Empezado por Mario

4- Donde esta el borrar enlaces?

Estará,... estará, si es menester...

Empezado por Mario

5- Seria bueno una consulta de "relacionados". Seria interesante para hacer mashups con otros sitio donde la informacion se puede agregar, ej: Si escribo un comentario en un sitio externo, seria bueno poner enlaces sobre las palabras clave de este (por ejemplo, si sale Delphi)

Como no se como tienes implementado el sistema de Tags, no se que tan dificil pueda serlo...

O sea realizar una petición de que retorne enlaces previamente filtrados por determinadas "palabras clave", etiquetas, etc. Sí. Desde luego es algo estaría bien que estuviese. Y digo lo mismo de arriba... estará... si es menester estará. Tomo nota. Por cierto que el tema de las búsquedas de enlaces en Loturak son un poquito pobres... no nos engañemos... en ese sentido a Loturak le falta un hervor o dos.

Empezado por Mario

6- Bueno el limite inferior, Malo no tiene superior. Si estas preocupado por un descarga descomunal que impide que igual se manden 1'000.000 de enlaces en un solo tiro? No veo que estes protegiendo estos casos...

No, no. Precisamente no hay límite superior porque este estaría establecido por defecto. Es decir, se indicaría un límite inferior para la consulta SQL, pero, el límite superior sería siempre 10, 20, 30, según se vea... pero, ya digo, no habría modo de retornar 1.000 enlaces, porque el límite superior lo estableceríamos en la aplicación "por defecto". Vamos, que lo mismo se me escapa algo en este sentido y no me doy ni cuenta...

Bueno. Gracias por tus comentarios Mario. Resultarán muy útiles.

Empezado por Seoane

(...) ya estoy imaginando una aplicación, con un icono quizá en la bandeja del sistema, y por supuesto standalone, que se pueda llevar en un usb y ejecutándola en cualquier equipo nos permita ver una lista con nuestros enlaces ... aunque quizá tenga que planearla un poco mas.

Estupendo Seoane. Aunque, tal como lo planteas y dado el nivel que tienes con el componente "TXMLDocument" creo que ni necesitarías un "parser RSS" para dar cuenta de los enlaces del archivo RSS conque ya cuenta Loturak... por cierto que permite varias triquiñuelas, conviene a saber, por ejemplo:

http://www.loturak.es/rss2?e=Delphi

La anterior URL retornaría en formato RSS los últimos 20 enlaces publicados en Loturak con la etiqueta Delphi. Y, por otro lado:

http://www.loturak.es/rss2?u=seoane

Que retornará los últimos 20 enlaces añadidos por el usuario Seoane en Loturak, no sé si te suena. ¿Qué te parece? ¡Tato pensao!

Empezado por Seoane

En cuanto a lo de agregar el código a tus ejemplos, la verdad me siento abrumado, solo era una pequeña diversión y vas tu y lo colocas en tu web. Estoy encantado de que me menciones en tu pagina, por mi perfecto.

Hombre, creo que el ejemplo en cuestión puede ser de utilidad, y no sólo para usar Loturak... olvidándonos de eso, alguien llega, topa con el código fuente y dice, leches, mira tú qué curioso. A lo mejor es soñar demasiado, pero, dado el caso, ¿vas a decir que estaría mal? Pues eso. Es lo menos que podía hacer, además.

[quote=Seoane]
Solo comentarte que con las prisas en la unidad Hash me olvide de borrar la función SHGetFolderPath que no uso para nada, pero con esto de cortar y pegar ....
[quote]

¿Lo dices por mí, verdad? Je, je, je... yo sí que he copiado y he pegado esta vez... Bueno. Procuraré corregir eso luego luego.

Empezado por Seoane

Y el ejemplo me parece bien, como no tengo el componente TSpinEdit tuve que colocar el puerto fijo, y me fije que tienes por defecto la dirección localhost y una Uri que me supongo es local y que usas para las pruebas. Por el resto, esta bien, todo lo bien que le permite mi chapuza de código

¿Que no tienes el componente "TSpinEdit"? Hay que jorobarse, ¿y duermes por las noches? ¿No te da cosa? Je, je, je... En serio. Ahora que lo dices voy a cambiar eso también, sustituiré los "TSpinEdit" por simples y efectivos "TEdit" para evitar el inconveniente en el futuro.

En cuanto al "Host" de los ejemplos, efectivamente, se trata del Servidor local que utilizo para las pruebas. Y de la chapuza de tu código... eso que lo dices tú. Estoy seguro de que a más gente, además de a un servidor, le parece todo lo contrario. Te lo agradezco otra vez Domingo.

Y termino ya... ¡que menudo rollo he soltado! Reconozco que si alguien considera todo esto "demasiado" está en su perfecto derecho. Nada que objetar... gracias otra vez a todos. Nos leemos.

PD. Al enviar este mensaje me encuentro con el límite de caritas... así que las he quitado todas... pero para vengarme ahora, aquí:

[dec]

Hola,

A ver. Gracias por vuestros comentarios. De veras que son muy útiles para continuar adelante. Vayamos por partes, pues, como dijo Jack el destripador.

Empezado por Mario

Date una vuelta por http://ma.gnolia.com/ que me parece tiene un buen API.

Lo haré Mario. Gracias.

Empezado por Mario

1- Podrias usar mejor un API-KEY que un clave y usuario.

Bueno. Efectivamente, he pensado en algo parecido a lo que dices. Es decir, restringir un poco el uso que pueda hacerse de la API. Esto no es lo único en Loturak que me preocupa por lo mismo. Me explico. Al exportar enlaces, por ejemplo, en del.icio.us se toman su tiempo, se ve que porque tienen mucho tráfico (muchos usuarios, cientos de miles, creo) y ese tipo de tareas no pueden hacerse ipsofacto o es mejor hacerlo "cuando se pueda", "poco a poco".

En en el caso de Loturak no se da límite a la hora de importar enlaces, ni tampoco al exportarlos, y esto me preocupa. No acuciantemente, porque Loturak no es demasiado utilizada y el usuario que más enlaces tiene cuenta con unos 600. Con estas cifras, la importación y exportación de enlaces es plausible hasta el momento, a lo menos con las pruebas que he ido realizando en este sentido.

Lo que se me ha ocurrido últimamente sobre esto es no limitar el número de enlaces que puede tener un usuario, pero sí los que puede importar y exportar "de un golpe"; pienso en una cifra razonable, digamos de 500 a 1.000 enlaces. En fin. Es algo que todavía está verde y para lo que también acepto vuestras sugerencias, si véis otra forma de burlar este problema, si no lo véis un problema, etc.

Respecto del API ocurriría algo parecido. Habría que limitarla o controlarla de algún modo, no ahora, porque no tendrá mucho uso (de hecho las pruebas las realizo casi todas "en local", y mi deseo sería que quien probase la API o se planteara realizar una aplicación hiciera lo mismo: instalara Loturak (¡ajá!) en su sistema e hiciera las pruebas allí mismo. Al fin y al cabo Loturak se comportará igual "en local" que en el Sevidor, y así las pruebas "en local" serán perfectamente "válidas", pueden servir perfectamente.

Empezado por Mario

Es lo que mas se usa en este tipo de servicios, y entre otros una razon es que las comunicaciones no estan protegidas (no creo que lo tengas por SSL) y estaria comunicandose un dato PERSONAL y PRIVADO plano por Internet.

Pues, efectivamente, la conexión no es "segura" en el sentido que mencionas. No se hace uso de SSL (Secure Socket Layer). Empero, aunque efectivamente los datos del enlace viajan "en limpio", no así la contraseña del usuario. De esta tiene que entregarse al Servidor su "doble MD5". Este es el modo en que guardamos las contraseñas en Loturak: guardamos su "hash" MD5 por duplicado. De todos modos, es cierto que se envían en claro los datos del enlace y si me apuras el "login" del usuario.

Empezado por Mario

Ya por esto, no me suena usar tu API.... y eso que estaba esperando a ver si lo liberabas pa' pensar como interlazo www.paradondevamos.com (que ya lo tengo listo para auto-ingresar en magnolia y enlaces manuales a digg y otros)

Bueno. Loturak (...) es una aplicación (me encanta verlo así) que sirve a los usuarios registrados para almacenar y gestionar los enlaces (URLs) que consideren oportunos. El hecho de que estos enlaces se puedan compartir siempre lo he visto como algo secundario. Es decir, no hace falta ser usuario de Loturak para usar la aplicación, de algún modo, puesto que puedes visitar la página Web y descubrir qué enlaces comparten los "loturakitas".

En todo caso la API está muy, muy verde aún. Seoane dice que se atreve a hacer algo con ella... es posible que a mí también se me ocurriera algo, pero, reconozco que aún le queda mucho a ese API para que pueda ser considerado algo más o menos digno de llamarse así. Para eso estoy aquí, entre otras cosas, para ver qué pensáis vosotros, como programadores, que podría añadirse a dicho API para que diera cierto juego y pudieraservir de algo a alguien.

Quiero decir que te sientas libre, Mario, de indicarme qué le falta, según tú, al API en ciernes, porque, seguramente serán cosas interesantes que acaso convenga tener en cuenta. Ahora, el que para usar determinados métodos del API sea preciso usar un usuario y una contraseña... es necesario, por las características de la aplicación. Piensa en un cliente de correo electrónico, que ha de solicitar al usuario su dirección de correo y su contraseña, pues, ¿cómo sino iba a llevar a cabo su trabajo de gestionar el correo? Guardando todas las distancias, claro.

Empezado por Mario

2- No le veo el sentido a poner Hola Mundo.

Digamos que es un método más o menos económico de realizar una prueba de disponibilidad al Servidor de Loturak. Así lo veo yo, vamos.

Empezado por Mario

3- No veo reglas de spam!!!

No especificas que tantas comunicaciones por cliente permite tu servicio, y por ende, no creo que le hayas puesto un limite.

Todos los demas API tienen algun limite (como solo 1000 hits por dia o algo asi) por una razon de sano juicio: Estas implementando un backdoor que puede ser facilmente abusado por un spammer.

Te falto que politicas gobiernan tu servicio...

Bueno. Supongo que sobre esto he comentado arriba algo, empero, no te quito la razón. Habría que mirar por proteger de algún modo a la aplicación. ¿Se te ocurre algo?

Empezado por Mario

4- Donde esta el borrar enlaces?

Estará,... estará, si es menester...

Empezado por Mario

5- Seria bueno una consulta de "relacionados". Seria interesante para hacer mashups con otros sitio donde la informacion se puede agregar, ej: Si escribo un comentario en un sitio externo, seria bueno poner enlaces sobre las palabras clave de este (por ejemplo, si sale Delphi)

Como no se como tienes implementado el sistema de Tags, no se que tan dificil pueda serlo...

O sea realizar una petición de que retorne enlaces previamente filtrados por determinadas "palabras clave", etiquetas, etc. Sí. Desde luego es algo estaría bien que estuviese. Y digo lo mismo de arriba... estará... si es menester estará. Tomo nota. Por cierto que el tema de las búsquedas de enlaces en Loturak son un poquito pobres... no nos engañemos... en ese sentido a Loturak le falta un hervor o dos.

Empezado por Mario

6- Bueno el limite inferior, Malo no tiene superior. Si estas preocupado por un descarga descomunal que impide que igual se manden 1'000.000 de enlaces en un solo tiro? No veo que estes protegiendo estos casos...

No, no. Precisamente no hay límite superior porque este estaría establecido por defecto. Es decir, se indicaría un límite inferior para la consulta SQL, pero, el límite superior sería siempre 10, 20, 30, según se vea... pero, ya digo, no habría modo de retornar 1.000 enlaces, porque el límite superior lo estableceríamos en la aplicación "por defecto". Ahora, que también puede ser que se me esté escapando algo en este sentido...

Bueno. Gracias por tus comentarios Mario. Resultarán muy útiles.

Empezado por Seoane

(...) ya estoy imaginando una aplicación, con un icono quizá en la bandeja del sistema, y por supuesto standalone, que se pueda llevar en un usb y ejecutándola en cualquier equipo nos permita ver una lista con nuestros enlaces ... aunque quizá tenga que planearla un poco mas.

Estupendo Seoane. Aunque, tal como lo planteas y dado el nivel que tienes con el componente "TXMLDocument" creo que ni necesitarías un "parser RSS" para dar cuenta de los enlaces del archivo RSS conque ya cuenta Loturak... por cierto que permite varias triquiñuelas, conviene a saber, por ejemplo:

http://www.loturak.es/rss2?e=Delphi

La anterior URL retornaría en formato RSS los últimos 20 enlaces publicados en Loturak con la etiqueta Delphi. Y, por otro lado:

http://www.loturak.es/rss2?u=seoane

Que retornará los últimos 20 enlaces añadidos por el usuario Seoane en Loturak, no sé si te suena. ¿Qué te parece? ¡Tato pensao!

Empezado por Seoane

En cuanto a lo de agregar el código a tus ejemplos, la verdad me siento abrumado, solo era una pequeña diversión y vas tu y lo colocas en tu web. Estoy encantado de que me menciones en tu pagina, por mi perfecto.

Hombre, creo que el ejemplo en cuestión puede ser de utilidad, y no sólo para usar Loturak... olvidándonos de eso, alguien llega, topa con el código fuente y dice, leches, mira tú qué curioso. A lo mejor es soñar demasiado, pero, dado el caso, ¿vas a decir que estaría mal? Pues eso. Es lo menos que podía hacer, además.

[quote=Seoane]
Solo comentarte que con las prisas en la unidad Hash me olvide de borrar la función SHGetFolderPath que no uso para nada, pero con esto de cortar y pegar ....
[quote]

¿Lo dices por mí, verdad? Je, je, je... yo sí que he copiado y he pegado esta vez... Bueno. Procuraré corregir eso luego luego.

Empezado por Seoane

Y el ejemplo me parece bien, como no tengo el componente TSpinEdit tuve que colocar el puerto fijo, y me fije que tienes por defecto la dirección localhost y una Uri que me supongo es local y que usas para las pruebas. Por el resto, esta bien, todo lo bien que le permite mi chapuza de código

¿Que no tienes el componente "TSpinEdit"? Hay que jorobarse, ¿y duermes por las noches? ¿No te da cosa? Je, je, je... En serio. Ahora que lo dices voy a cambiar eso también, sustituiré los "TSpinEdit" por simples y efectivos "TEdit" para evitar el inconveniente en el futuro.

En cuanto al "Host" de los ejemplos, efectivamente, se trata del Servidor local que utilizo para las pruebas. Y de la chapuza de tu código... eso que lo dices tú. Estoy seguro de que a más gente, además de a un servidor, le parece todo lo contrario. Te lo agradezco otra vez Domingo.

Y termino ya... ¡que menudo rollo he soltado! Reconozco que si alguien considera todo esto "demasiado" está en su perfecto derecho. Nada que objetar... gracias otra vez a todos. Nos leemos.

PD. Al enviar este mensaje me encuentro con el límite de caritas... así que las he quitado todas... para vengarme aquí:

Actualización: Ya he arreglado el asunto de la unidad "Hashes.pas" Seoane.

[dec]

Hola,

Pues nada, que no se me ocurre cómo. Le estoy dando vueltas al tema de hacer necesario contar con cierta "clave" para poder utilizar la API de que venimos hablando. No se me ocurre cómo. Llevo tiempo dándole vueltas y cuantas más le doy más perdido me encuentro.

No sé si es que estoy un poco cansado y no quiero ponerme con lo que se me ocurre, si inconscientemente lo que se me ocurre no me parece bien, si es que no quiero precipitarme...

Qué sé yo. El caso es que supongamos que es precisa cierta clave para utilizar la API de que hablamos. ¿En qué puede consistir esta clave? Vale. Supongamos que es el "hash" de una determinada cadena, pero, ¿de qué cadena? ¿Con qué formamos la cadena?

Está también el tema de que habría que pasar a los métodos que lo requirieran un nuevo parámetro, es decir, un nuevo elemento del "Array numérico" que se pasa como parámetro de los métodos... un nuevo elemento que evidentemente contendría la clave de marras...

¿Cómo se validaría el asunto? Es decir, alguien pretende usar la API, se comprueba la clave... ¿que estaría guardada en la base de datos? En una nueva tabla, ¿pero qué y cómo comprobamos exactamente que la clave es válida? Creo que no me estoy explicando.

Alguien utiliza un método y proporciona una determinada clave, hasta ahí llego, ahora bien, comprobamos que la clave existe en la base de datos, ya se va entendiendo, pero, ¿qué ocurre si alguien, sencillamente, copia la clave de encuentre por ahí y la utiliza? ¿Cómo saber quién es quién o quien dice ser?

No sé. A mí no se me ocurre sino utilizar el "Agente de usuario" que se presente, que realize la petición al Servidor, pero, eso sería obligar a especificar dicho Agente de usuario, además de la clave... y me temo que con esta última no habría problema, pero, el Agente de usuario podría causarlos, por ejemplo, porque no pudiera "editarse" por quien realiza la petición al Servidor.

Así que esas tenemos. Luego me surgen también otras dudas respecto a esto mismo, pero, no quiero ser pesado y siempre acabo soltando unos tochos que no hay quien los lea... así que me callo ya que ya está bien. Como dice por ahí un compañero, buenos días, buenas tardes, buenas noches a todos.

[roman]

Hola, voy a hablar desde la ignorancia pero bueno..

No entiendo la preocupación de mandar el usuario y contraseña. O mejor dicho, sí la entiendo pero no como un problema inherente a lo que estás haciendo. Es decir, actualmente manejas en loturak, via http, una autentificación y tal y es lo mismo de insegura que en el caso que te ocupa ahora. Si vía http no te quita el sueño, ¿por qué te lo quita ahora?

Por otro lado, no entiendo eso de mandar la contraseña cifrada. Hasta donde entiendo, en el caso de la autenticación de loturak, la contraseña cifrada te sirve para poder mantener al usuario en sesión (no digo logueado porque suena horrible) sin necesidad de guardar la contraseña real en una cookie, pero en algún momento debe hacerse la autenticación. ¿Cómo se llevaría esto a cabo con la LAPI?

Otra cosa, ¿me podría alguien explicar qué es una API-KEY?

// Saludos

[dec]

Hola,

Empezado por Román

(...) actualmente manejas en loturak, via http, una autentificación y tal y es lo mismo de insegura que en el caso que te ocupa ahora. Si vía http no te quita el sueño, ¿por qué te lo quita ahora?

Bueno. Efectivamente, porque se me ocurrió así desde un principio. Es decir, desde el momento en que era necesaria la autentificación del usuario pensé que podría enviarse el MD5 de la contraseña. Es cierto que Mario a puesto en evidencia que los datos del enlace siguen enviándose en claro, y, esto en los enlaces públicos importa menos, pero, en los privados... en fin.

No sé. Supongo que he ido a salvar la contraseña por todos los medios posibles mientras que el resto de datos he dado por supuesto que viajarían en claro... sin más. Lo que significa le hecho de que lo decidiera así es que ahora pienso que podría hacer lo mismo con la contraseña en la autentificación en Loturak, no en el API... sino en la propia página Web. Se me ocurre que podría codificar la contraseña igualmente con MD5 valiéndome de JavaScript.

La seguridad es algo que habría que tener en cuenta... a lo menos hasta donde pudiera llegar uno. Mismamente al liarme con todo esto del API he solucionado (hasta donde llego) un par de problemas de seguridad en sendas partes de Loturak: era posible hasta anteayer para un usuario registrado editar así como borrar enlaces de otros usuarios. No sencillamente, es decir, requería comerse un poco la cabeza, pero, no demasiado. Y sin embargo, pensando en todo esto... los datos siguen viajando en claro...

Empezado por Román

Por otro lado, no entiendo eso de mandar la contraseña cifrada.

Bueno. Ya digo que es una idea mía... así que puede ser perfectamente inútil o innecesaria... de hecho en WordPress, sin ir más lejos, no se cifra la contraseña del usuario cuando esta se utiliza el API XML-RPC conque cuenta este gestor de contenidos. A lo menos eso he creído entender luego de revisar el código fuente relacionado. Ya digo. Lo pensé así Román... centrándome (acaso un tanto irracionalmente, puesto que dejo los datos del enlace en claro), digo, queriendo proteger la contraseña del usuario.

Empezado por Román

Hasta donde entiendo, en el caso de la autenticación de loturak, la contraseña cifrada te sirve para poder mantener al usuario en sesión (no digo logueado porque suena horrible) sin necesidad de guardar la contraseña real en una cookie, pero en algún momento debe hacerse la autenticación. ¿Cómo se llevaría esto a cabo con la API?

Efectivamente, usando un par de Cookies conseguimos que la autentificación del usuario "persista" en el tiempo. Lo que se guarda en la Cookie... no te lo vas a creer... es el MD5 (no recuerdo ahora mismo si doble) del MD5 (este seguro doble) de las contraseñas de los usuarios. Me parece que añado algo más en la clave que guardo en la Cookie...

Ahora bien, en todo caso, no sé si te aclarará el asunto un poco si te digo que las contraseñas de los usuarios no se guardan en claro en la base de datos, sino que se guarda el "doble MD5" de las contraseñas. Los métodos del API que lo necesiten ya recogen el doble MD5 de una contraseña de usuario, así que la autentificación se lleva a cabo con el login de usuario y con la contraseña tal cual llega, pues es justo lo que se necesita.

Empezado por Román

Otra cosa, ¿me podría alguien explicar qué es una API-KEY?

Pues debe ser algo como una "llave" que permita a determinado programador/desarrollador acceder a un determinado API. No tienes la "llave"; no puedes acceder al API. Google hace uso de esto en sus APIs... generalmente, al menos, asigna al que lo solicita una clave (creo que única). En el caso de Google además, al menos para ciertas APIs, asigna a cada clave un número limitado de "consultas a la API"... que es algo que no sé muy bien cómo va exactamente, pero, en definitiva, no puedes "buscar en Google" desde tu aplicación más de 1.000 veces al día o algo así... ciertamente yo también estoy verdísimo en todo esto, como en casi todo, cada vez que lo pienso más.

[dec]

Hola,

Ya contamos con un método "EnlacesUsuario" y con otro "NumeroEnlaces" (del usuario). Se han preparado "ejemplos" de uso de estos métodos tanto en PHP como en Delphi. También he quitado los "SpinEdits" de todos los ejempos de Delphi que los usaban. He repasado, en general, todos los ejemplos. Y creo que eso es todo. Ya me diréis si os place y tenéis tiempo lo que os parece.

¡Que paséis un buen domingo!

[mamcx]

Ok, algunas cosas:

- Es cierto que al trabajar una pagina web por http es igual de inseguro y se estan enviando los datos de claves en plano.

Diantre, no habia caido en eso. Es por eso que es muy comun que la pagina de login y perfil de usuario sea por https y el resto por http. Un punto que debo analizar ahora para mi propia portal!

Por otro lado, desde un punto de vista estricto, es lo mismo pasar una sola clave o un conjunto de parametros de autenticacion o lo que sea. Una vez se lee, se usa la misma clave y ya.

El punto es que clave/id no es un atributo de SEGURIDAD. Es un atributo de AUTENTICACION. Para que sea algo *realmente* seguro debe haber un mecanismo de comunicacion seguro y un mecanismo de autenticacion verificable.

Porque API-key VS Usuario-Contraseña?

- Porque es indespensable que el usuario AUTORIZE el uso del mecanismo automatizado. Por ejemplo, magnolia o yahoo demandan la solicitud del API key, lo que equivale a firmar un documento autorizando el uso de mecanismos robotizados para manipular los comandos.

- Por Usuario/Clave = 1 Sola cadena para efectos practicos. De hecho, una cadena muy larga puede ser mas segura que 2 muy cortas.

Ademas, aunque la clave pase con MD5 igual la *mitad* de la clave ya se sabe, y esta se puede interelacionar con otras cosas. Al igual que muchos, yo siempre uso mamcx en mis registros asi que tengo un sistema 1/2 de seguro que lo que podria ser...

- Otro beneficio algo dudoso es que es mala idea guardar claves y nombres de usuario en texto plano en el codigo fuente, sobre todo en lenguajes como PHP que demandan el despliegue de codigo.

Bueno, como dije, quizas me estoy pasando de neurotico.

- Porque si todos los demas usan API-Key, porque no estar a la moda

Me preocupa eso si lo de MD5 doble. Estas haciendole MD5 asi:

"holamundo".MD5().MD5() ????

Porque si eso es verdad, has minado la seguridad de tu clave y haz reducido la efectividad de la misma. Contrario a lo que uno intuitivamente cree, aplicar multiples encriptaciones a un dato disminuye y no aumenta su seguridad.

Como generar el API-Key? Simplemente un dato autogenerado que sea un poco largo y que carezca de sentido, busca como generar info aleatoria (o puedes reusar por ejemplo la generacion de GUID)

[dec]

Hola,

Empezado por Mario

El punto es que clave/id no es un atributo de SEGURIDAD. Es un atributo de AUTENTICACION. Para que sea algo *realmente* seguro debe haber un mecanismo de comunicacion seguro y un mecanismo de autenticacion verificable.

Ahí le has dado. Eso es así.

Empezado por Mario

Me preocupa eso si lo de MD5 doble.

Bueno. Olvídate de todo lo que se ha hablado de MD5 en este Hilo. En realidad el "doble MD5" viene de cómo se guardan las contraseñas de los usuarios en la base de datos de la aplicación. Es decir, en los correspondientes campos no se guarda la contraseña en claro, sino su "doble MD5".

De este modo ni siquiera nosotros conocemos las contraseñas de los usuarios. El usuario entrega su contraseña a la aplicación, y esta comprueba su "doble MD5" con que el hay guardado en la base de datos. Entendí que era mejor un "doble MD5", aunque, puesto que Loturak es una aplicación de código abierto... esta información es perfectamente conocible.

Sólo sé que no sé nada