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

Hola,

Sí; no se me escapa que el lugar de este Hilo y el título del mismo pueden dejar que desear... pero es que no sabía exactamente dónde ponerlo ni cómo titularlo. En mi descargo diré que lo situé en Internet porque tiene que ver con Delphi e Internet, y que no lo titulé "Ayuda please", como hacen otros. :eek:

Intentaré no enrollarme demasiado. Lo malo es que voy a tener que nombrar lo que prometí no nombrar hace tiempo... y la única excusa que puedo poner es que al fin y al cabo trasgredí dicha promesa tantas veces ya que, bueno, qué le vamos a hacer, podría decirse. Bicho, lo siento. Sé indulgente, please.

Llevaba tiempo planteándome la implementación de un API (Application Programming Interface) para Loturak (¡ajá!) y bueno, luego de darle unas cuentas vueltas por mi cuenta al final el tema ha resultado ser menos complicado de lo que yo lo veía, sin duda por desconocimiento.

Al final he optado por utilizar el protocolo XML-RPC (XML Remote Procedure Call), puesto que me constaba que proyectos como WordPress hacían uso de la librería Incutio XML-RPC Library para PHP, que ha resultado ser una estupenda forma de implementar el Servidor XML-RPC que necesitaba para Loturak.

La librería consta de un sólo archivo (en su página Web hay buena documentación sobre la misma) que a su vez contiene las clases necesarias para manejarse desde PHP con el protocolo de marras; cuenta con clases para implementar Servidores (de diversos tipos) y clientes (también de diversos tipos) muy sencillamente.

Planteado el Servidor XML-RPC de Loturak (¡ajá!) quedaba la implementación de los posibles clientes que hicieran uso de los métodos que el primero exponga. Tras salvar algunos obstáculos como pueda ser la autentificación del usuario (al final he seguido casi a pies juntillas el procedimiento empleado por WordPress) he preparado ejemplos escritos en PHP para utilizar el Servidor XML-RPC.

Para ello he utilizado la propia librería Incutio XML-RPC, como digo, hasta el momento, con excelentes resultados. Empero, que pueda interactuarse con Loturak desde PHP está bien, seguramente, mas mi objetivo era hacerlo desde otros lenguajes... como por ejemplo el propio Delphi. En PHP hay distintas implementaciones del protocolo XML-RPC, para otros lenguajes existen también posibilidades, y, para Delphi en concreto, encontré la librería Delphi XML-RPC, cuya versión 2.0 (del año 2003) he utilizado con buenos resultados para lo que nos ocupa.

Como el código fuente de Loturak (¡ajá!) está disponible para su descarga podéis, si os place, echar un vistazo a todo esto de que vengo hablando. En la carpeta "scripts" del código fuente encontraréis ejemplos de uso del todavía proyecto de Servidor XML-RPC escritos tanto en PHP como en Delphi. El propio Servidor... para los que tengáis ganas de echar un vistazo lo encontraréis en la carpeta "www/api/xmlrpc.php".

Vale. El caso es que ahora mismo contamos en el Servidor XML-RPC de Loturak (¡ajá, ajá!) con tres métodos, tres, que es posible utilizar "remotamente" por aplicaciones de terceros. Estos tres métodos, tres, pueden verse documentados en el nuevo apartado que hemos añadido a la Web: Interfaz de Loturak para programadores. Dos de los métodos son, podría decirse, para probar... se trata de los métodos "HolaMundo" y "HoraServidor".

El tercer método ya se mete un poco más en harina y permite insertar un enlace en Loturak (dentro de la cuenta de un determinado usuario, cuyo login y contraseña habrá que especificar convenientemente) con su título, url, etiquetas, descripción, etc. Pues bien, el objetivo de este Hilo es que me déis vuestras opiniones... quiero decir, aquello de ¿qué le falta? ¿qué le sobra?

Me gustaría que vosotros, aprovechando la confianza que tengo aquí, desde el punto de vista de programadores, expusiérais aquí los métodos que para vosotros tendría que contar el API de Loturak para que se conviertiera en algo realmente útil. Creo que podemos además sacar algunas conclusiones relacionadas con todo esto, puesto que a mí, desde luego, esto de que las aplicaciones Web se dejen "tocar" desde fuera es una idea que me parece estupenda.

Así que podemos tratar de todo esto, siempre que os apetezca. Si tenéis cualquier pregunta que creáis que puedo responder; si albergáis cualquier duda acerca de lo que he comentado aquí huelga decir que estaré encantado de recibirla y responder, si es el caso, lo mejor que sepa y pueda. Y no voy a decir mucho más, porque luego todo se sabe. Cualquier aclaración, como digo, ya podéis añadirla a este Hilo.

Eso es todo. Que paséis un buen fin de semana y que os portéis bien. Ah, y gracias por todo de antemano. Sois los mejores. :cool:

Actualización: Solicito vuestra ayuda y opiniones porque, sin ir más lejos, ayer se me ocurrió un método que nombré "UltimoEnlace", que terminé implementando en el Servidor, y para el que escribí un ejemplo en Delphi que funcionaba bien y todo, pero, al cabo he pensado que qué significa ese método ahí... qué utilidad real tenía... al cabo lo desestimé hasta encontrar algo verdaderamente útil, como me lo ha parecido el método "InsertarEnlace", pero, claro,... este sólo parece muy solo, ¿no?

Segunda actualización: Ya añadí un nuevo método "ActualizarEnlace", que puede usarse para actualizar enlaces conociendo el ID de estos.

Hola David:

Impresionante el trabajo que estas haciendo en loturak ( yo lo puedo decir, estoy libre de toda sospecha de spam). Ya comente por aquí alguna vez que de php no se nada, así que no podía jugar con tu proyecto, loturak (¡ajá!), pero ahora que ya nos metemos en Delphi es momento de que meta un poco el dedo y espero no romper nada.

Así que poco después de publicar tu mensaje, me puse manos a la obra. Me leí por encima la ayuda sobre IXMLDocument, y me dispuse a reinventar la rueda. No lo puedo evitar, podía usar la librería que recomiendas (Delphi XML-RPC) pero así ya no es tan divertido.

Bueno, dejen sitio que estoy reinventando la rueda :D

Código Delphi [-]
// Primero necesitamos poder hacer post
// y por supuesto lo haremos con WinInet, Indy es para nenas
function SendRequest(Server, Uri: String; Port: Word;
  Request: String; var Response: String): Boolean;
var
  hNet: HINTERNET;
  hCon: HINTERNET;
  hReq: HINTERNET;
  Context: DWORD;
  BytesRead: DWORD;
  Success: Boolean;
  Buffer: array[0..1024] of Char;
begin
  Context:= 0;
  Result := FALSE;
  hNet := InternetOpen('Agente', INTERNET_OPEN_TYPE_PRECONFIG, nil, nil, 0);
  if (hNet <> nil) then
  begin
    hCon:= InternetConnect(hNet,PChar(Server),Port,nil,nil,
      INTERNET_SERVICE_HTTP,0,Context);
    if (hCon <> nil) then
    begin
      hReq:= HttpOpenRequest(hCon,'POST',PChar(Uri),nil,nil,nil,
          INTERNET_FLAG_RELOAD,Context);
      if (hReq <> nil) then
      begin
        Success:= HttpSendRequest(hReq,
          'Content-Type: text/xml',Cardinal(-1),
          PChar(Request),Length(Request));
        if Success then
        begin
          FillChar(Buffer, Sizeof(Buffer), #0);
          while (InternetReadFile(hReq,@Buffer,Sizeof(Buffer)-1,BytesRead)) do
          begin
            if (BytesRead = 0) then
            begin
              Result := TRUE;
              break;
            end;
            Response:= Response + String(PChar(@Buffer));
            FillChar(Buffer, Sizeof(Buffer), #0);
          end;      
        end;
        InternetCloseHandle(hReq);
      end;
      InternetCloseHandle(hCon);
    end;
    InternetCloseHandle(hNet);
  end;
end;  

// Ahora necesitamos convertir los datos en una petición XML-RPC
function InsertarEnlace(Username, Password, Url, Titulo, Etiquetas,
  Descripcion: String; Privado: Boolean): String;
var
  XMLDoc: IXMLDocument;
  Nodo: IXMLNode;
begin
  Result:= EmptyStr;
  XMLDoc:= TXMLDocument.Create(nil);
  with XMLDoc do
  try
    Active:= TRUE;
    Version:= '1.0';
    Options:= [doNodeAutoIndent];
    Nodo:= AddChild('methodCall');
    Nodo.AddChild('methodName').Text:= 'loturak.InsertarEnlace';
    Nodo:= Nodo.AddChild('params');
    Nodo:= Nodo.AddChild('param');
    Nodo:= Nodo.AddChild('array');
    Nodo:= Nodo.AddChild('data');
    Nodo.AddChild('string').Text:= Username;
    Nodo.AddChild('string').Text:=
      LowerCase(StrCheckSum(LowerCase(StrCheckSum(Password))));
    Nodo.AddChild('string').Text:= Url;
    Nodo.AddChild('string').Text:= Titulo;
    Nodo.AddChild('string').Text:= Etiquetas;
    Nodo.AddChild('string').Text:= Descripcion;
    if Privado then
      Nodo.AddChild('i4').Text:= '1'
    else
      Nodo.AddChild('i4').Text:= '0';
    Result:= XML.Text;
  finally
    Active:= FALSE;
    XMLDoc:= nil;
  end;
end;

// Ahora la mandamos y si falla, obtenemos la descripcion del error 
function SendRPCRequest(Server, Uri, Request: String; Port: Word;
  var Response: String; var FaultString: String): Boolean;
var
  XMLDoc: IXMLDocument;
  Nodo: IXMLNode;
  i: integer;
begin
  Result:= FALSE;
  Response:= EmptyStr;
  FaultString:= EmptyStr;
  XMLDoc:= TXMLDocument.Create(nil);
  with XMLDoc do
  try
    if not SendRequest(Server,Uri,80,Request,Response) then
      raise Exception.Create('No puedo enviar la peticion');
    XML.Text:= Response;
    Active:= TRUE;
    Nodo:= ChildNodes.FindNode('methodResponse');
    if Nodo <> nil then
    begin
      Result:= TRUE;
      Nodo:= Nodo.ChildNodes.FindNode('fault');
      if Nodo <> nil then
      begin
        Result:= FALSE;
        Nodo:= Nodo.ChildNodes.FindNode('value');
        if Nodo <> nil then
        begin
          Nodo:= Nodo.ChildNodes.FindNode('struct');
          if Nodo <> nil then
          begin
            for i:= 0 to Nodo.ChildNodes.Count - 1 do
            begin
              if AnsiSameText(Nodo.ChildNodes[i].NodeName,'member') then
              begin
                if Nodo.ChildNodes[i].ChildNodes.FindNode('name') <> nil then
                  if AnsiSameText(Nodo.ChildNodes[i].ChildNodes.FindNode('name').Text,'faultString') then
                    if Nodo.ChildNodes[i].ChildNodes.FindNode('value') <> nil then
                    begin
                      Nodo:= Nodo.ChildNodes[i].ChildNodes.FindNode('value');
                      if Nodo.ChildNodes.FindNode('string') <> nil then
                        FaultString:= Nodo.ChildNodes.FindNode('string').Text;
                      break;
                    end;
              end;
            end;
          end;
        end;
      end;
    end;
  finally
    Active:= FALSE;
    XMLDoc:= nil;
  end;
end;

// Y ahora ponemos todo en marcha y que no reviente
var
  Response, Request, FaultString: string;
begin
  Request:= InsertarEnlace( 'usuario','contraseña','www.google.com','Probando RPC',
    'Probando,RPC','Probando 1, 2, 3 ...', TRUE);
  if not SendRPCRequest('www.loturak.es','/api/xmlrpc',Request,80,Response,FaultString) then
    ShowMessage(FaultString);
end;

Bueno, ahí dejo esto. No es que aporte nada, pero tenia ganas de jugar un poco. Ayer poco después de colocar tu mensaje, deje de poder acceder a la pagina del club y la de loturak (¡ajá!), no se el motivo. Así que mientras esperaba probé a mandar peticiones a flickr, lo que hace el aburrimiento :D

Perdona que me metiera en el hilo para no aportar nada, pero como ya dije arriba el aburrimiento es muy malo. :D

PD: Para calcular el md5 use la siguiente unit, hecha por mi para mi mismo, así que si alguien la necesita la puede usar sin problemas.

Hola,

Es estupendo Domingo. Un código estupendo, como siempre. Todo funciona perfectamente, lo he podido comprobar. Te agradezco mucho el trabajo que te has tomado. Me he permitido hacer algunos cambios en los ejemplos para Delphi que se incluyen en el código fuente de Loturak (¡ajá!).

Básicamente he sustituido las unidades "MD5" y "UDobleMD5" por tu unidad "Hashes". He actualizado los ejemplos "InsertarEnlace" y "ActualizarEnlace", por tanto, para que ahora utilizen la unidad "Hashes". Por otro lado he adaptado la interfaz del ejemplo "InsertarEnlace" de modo que ahora utiliza el código que propones más arriba, como puedes comprobar.

Es decir, ahora mismo existen cinco ejemplos para Delphi:

- HolaMundo (con la librería Delphi XML-RPC)
- HoraServidor ("" "")
- InsertarEnlace ("" "")
- ActualizarEnlace ("" "")
- InsertarEnlace (con el código que has propuesto)

En fin. Que muchas gracias por todo. Realmente creo que la librería Delphi XML-RPC es bastante curiosa (echa un vistazo a los ejemplos que la utilizan, puesto que los he adecentado un poco esta misma tarde y a lo mejor tú no los has visto todavía como están ahora), y podría ser una buena forma de montar una aplicación en Delphi que interactuase con... ¡ajá!, pero, eso no quita ni un ápice de mérito a tu trabajo, que ya está incluído en el código fuente de Loturak, como he dicho.

Vale. Nos leemos. Gracias otra vez Domingo. Gracias a todos. ;)

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. :D

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. :)

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

No he visto el codigo porque a)PHP me gusta tanto como cebolla con arequipe, siendo el caso que la cebolla me gusta y tambien el arequipe y b) Para darte una persepctiva mas "independiente"


1- Podrias usar mejor un API-KEY que un clave y usuario. 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.

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)

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

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...

4- Donde esta el borrar enlaces?

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...

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...

:p 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 :eek: . 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 :p

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.

Lo haré Mario. Gracias.

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.

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.

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.

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.

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?

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

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.

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.

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!

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.

¿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í: :eek: :eek: :) :D :cool: :p :rolleyes:

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.

Lo haré Mario. Gracias.

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.

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.

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.

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.

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?

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

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.

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.

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!

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.

¿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í: :eek: :eek: :) :D :cool: :p :rolleyes:

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

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. :)

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

Hola,

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...

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.

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. ;)

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. :D

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! :D

Bueno, voy también a opinar yo, no se si para ayudar o para confundir mas :p Lo primero, si tienes preocupación por la seguridad por que no utilizas simplemente https en vez de http, todo los datos irán cifrados, se acabo el preocuparse de quien esta mirando. En cuanto a lo de mandar la contraseña cifrada o en claro, el cifrar la contraseña no nos proporciona ninguna seguridad extra, si alguien llega a tener acceso a los datos y puede leer el md5 eso es todo lo que necesita, porque siempre es el mismo, cuando quiera utilizar la api solo tiene que usar el mismo hash no tiene porque conocer la contraseña.

Creo recordar que sistemas como el messenger utilizan un sistema de identificación basado en md5 bastante seguro, cuando un cliente se conecta al servidor este le manda un numero aleatorio, entonces el cliente genera el md5 a partir de la contraseña y ese numero. Cuando el servidor recibe el md5, hace lo mismo, utiliza la contraseña original y el numero que genero y también calcula su md5, entonces compara ambos hash. Esto llevado a tu caso puede ser bastante complicado de implementar, y por lo menos implicaría el tener que usar 2 peticiones consecutiva, una para obtener el número aleatorio y otra para mandar la petición con la contraseña cifrada. Bueno, ahí te queda la idea ....

En cuanto a lo de la API-KEY puede ser buena idea, te comento que en flickr te la dan solo con estar registrado y decir que quieres hacer una aplicación. Tiene toda la pinta de ser el hash de algo, pero para el caso nos da igual, puede ser una cadena de texto aleatoria. Yo lo que creo es que simplemente almacenan las keys en una tabla de la base de datos y eso les sirve para validarlas o llevar la cuenta de las peticiones que realizan. Así que nos daría igual que fueran aleatorias. Yo el fallo mas grande que le veo a ese sistema, es que cualquiera puede "robarle" la contraseña a una aplicación y usarla en la suya, ya sea revisando el ejecutable o espiando la comunicación. Pero los de google o flickr tendrán sus razones y yo humilde diletante no les voy a decir como tienen que hacer las cosas :D

A ver, si yo me pongo a escuchar tu pc e intercepto el md5 que mandas al servidor, ¿qué me impide a mi mandarlo por mi cuenta? Cuando el servidor lo reciba, hará las operaciones que describes y claro que concordarán.

Pero de cualquier forma, no es tanto haber "puesto al descubierto" si el sistema era o no inseguro, eso creo que todos lo tienen más o menos claro. El sistema es tan seguro o inseguro como lo puede ser cualqiera de muchos que hay. Sin ir más lejos, como el del propio ClubDelphi, y ¿ustedes creen que Emlio duerme intranquilo por ello? Claro que no. Porque aunque la autenticación no viaje por un canal seguro, no estamos hablando de una tienda en línea o un banco o el Pentágono. No quiero decir con esto que la seguridad no sea importante para este tipo de proyectos, claro que la es y qué bueno que David haya encontrado y corregido las fallas que menciona, pero no creo que requiera mucho más nivel de seguridad.

Una cosa más: ¿cuál es su problema con los SpinEdit? ¿Qué no vienen incluidos con Delphi?

// Saludos

En el sistema que describo, si alguien intercepta la comunicación y se hace con el md5, este no le valdrá de nada. Pues si intenta conectarse por su cuenta el numero aleatorio sera diferente y por lo tanto el md5 también. El sistema es seguro para realizar una autenticación, pero los datos se siguen mandando sin cifrar.

Estoy de acuerdo, podemos hablar de métodos de seguridad de forma teórica, es un tema muy interesante, pero implementarlos en un proyecto que no va a manejar dinero me parece desproporcionado. Hablamos de "interceptar" comunicaciones como si fuera algo sencillo, y en realidad es bastante complicado, por que alguien habría de tomarse tantas molestias para cambiarnos los enlaces de loturak. En la autenticación aquí en el club delphi se manda la contraseña cifrada una sola vez con md5 por un canal no seguro y, como tu dices, a Emilio no le quita el sueño, ni a nadie le han "robado" la identidad :D

Pues al parecer en el turbo delphi no.

Hola,

Llevas razón Seoane. Es algo que tengo que mirar con más atención... sobre todo ahora...

Claro. Justo. Y a esto se refería Mario conque no entendía el MD5 de la contraseña, y lo mismo quería decir Román cuando se dijo que no entendía la preocupación en el API y no en la aplicación... y yo respondí poco menos que con cajas destempladas, y es que el que no sabe es como el que no ve. La virgen.

Bueno. Ahora mismo me dispongo a rectificar lo necesario para que todo quede tal cual en la aplicación: no hay necesidad de hacer que quien utilize el API de Loturak tenga que complicarse con MD5 y demás... así que voy a arreglar eso. Luego ya podremos hablar del "HTTPS" y cómo podríamos utilizarlo, si es que se ve menester...

He quedado como un tonto, imagino. :rolleyes:

Pero muchas gracias a todos. De verdad que gracias. :)

Perdón, pero sigo sin entender. El número aleatorio se genera cuando se hace la autenticación, es decir cuando se manda el usuario y contraseña. En los subsecuentes accesos es cuando se manda el md5 que se formó con el número aleatorio y la contraseña. Entonces, repito, ¿qué me impide mandar ese md5 desde mi pc?

// Saludos

No estamos desviando del tema. Pero todo sea para que no te quedes con la duda. En el sistema que describo primero se solicita el numero aleatorio, sin enviar todavía la contraseña, una vez que se tiene el numero es cuando se manda el usuario y la contraseña cifrada en md5.

Adaptándolo a este caso caso, me imagino un sistema parecido a este. Primero enviamos una petición de numero aleatorio indicando nuestro nombre de usuario. Del lado del servidor generamos un numero aleatorio que guardamos en alguna tabla asociándolo a ese nombre de usuario y dándole una vida útil de x peticiones. Una vez el cliente tiene el numero, en la siguientes peticiones mandara la contraseña cifrada con ese numero, el cliente sera el encargado de solicitar un numero nuevo cuando este deje de ser valido. Incluso podemos indicar que el numero solo sea valido para una petición, de esta manera antes de cada petición habría que solicitar un numero nuevo.

Esto ni pensarlo. Este tipo de discusiones nos sirven a todos. Me parece que sólo se trata de una confusión en cuanto al uso del md5 en la contraseña. No es para proteger el proceso de autenticación, sino para preservar la sesión mientras se navega por el sitio sin que la contraseña quede guardada tal cual en una cookie.

// Saludos

Hola,

Seoane, prometo leer con más calma tus últimos mensajes. Román... sí que he quedado como un tonto. Es algo que además es más habitual de lo que quisiera. Me pongo a hablar, a hablar... y no escucho a nadie... ¡y luego resulta que estoy equivocado, confundido, por lo menos! Pero yo a lo mío... a lo mío... muy tonto, sí.

Por el momento he dejado el asunto de manera que la contraseña del usuario nos llegue "en claro", tal y como lo hace en la propia Loturak, es decir, fuera del API de que hablamos. He corregido la "documentación", los métodos oportunos, y he actualizado los ejemplos en consecuencia. Podéis verlo si descargáis el código fuente (v1.0).

No sé. Ahora mismo estoy un poco aturdido. Será que me acabo de despertar, será que la primera ha sido en la frente... no sé porqué será. En todo caso muchas gracias a todos, no me canso de decirlo, porque a las pruebas me remito: si por mí hubiera sido el asunto iría muy mal...

Y lo diré una vez más: he hecho el tonto e incluso me he creído superior de algún modo... Por ejemplo, cuando arriba mencioné a WordPress y hablé de que ahí no se codificaba la contraseña del usuario, que nosotros usábamos MD5... como si estuviéramos inventando algo, siendo, como ha resultado ser, una tontería por nuestra parte...

Bueno. Vale. Voy a ver si me despejo un poco. Seguimos leyéndonos. Gracias otra vez a todos. :)

A ver, aquí estamos bajo el supuesto de que alguien se pone a escuhar la comunicación entre nuestra pc y el servidor, de lo contrario no hay de qué preocuparse.

Vamosa ver, tú le solicitas al servidor un número aleatorio y él te lo manda:

id = 2738582

Este número podria de todas formas verlo quien esté escuchando.

Tu mandas al servidor:

md5(2738582 + pepeloco)

donde pepeloco es tu contraseña. Muy bien, yo intercepto esto y lo mando por mi cuenta. El servidor lo recibe igual que recibiría el tuyo. No veo ventaja. Claro, eso sólo servirá el número de peticiones estipuladas. Bueno, cuando se regenere el número aleatorio, lo vuelvo a escuchar, vamos yo sigo escuchando ¿no?, y lo cambio y se lo mando al servidor. ¿Dónde está la ventaja?

// Saludos

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)

Hola,

Ahí le has dado. Eso es así.

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

No es lo mismo "escuchar" que interponerse entre el servidor y el cliente. Tu estas suponiendo que el posible atacante tiene control total sobre la comunicación y puede mandar tanto al cliente como al servidor lo que el quiera e impedir que lleguen los mensajes de uno a otro. En ese caso, la cosa esta difícil y este método no supone ninguna ventaja. Pero en el caso de que solo pueda "escuchar" como es el caso de un sniffer, la cosa cambia. Pongamos que el numero solo es valido para una petición, el cliente pide el numero, cifra la contraseña, y envía la segunda petición con la contraseña cifrada, en ese momento esa contraseña deja de ser valida. Si alguien estuviera curioseando, solo podría obtener la contraseña cifrada, una contraseña que ya no seria valida para usarla una segunda vez.

¿Por que? Si bien eso es muy cierto para algoritmos de encritptacion que utilizan clave, no creo que sea aplicable a algoritmos de hash. Aunque corrígeme si me equivoco.

En cuanto a lo de usar claves o apikeys, no dudo del beneficio de usar apikey. Pero el nombre de usuario y contraseña sigue siendo necesario para realizar tareas con los enlaces privados. Yo lo veo así, usar un apikey en todas las funciones, de esta manera se puede llevar un control, aunque no sea muy exacto, de quien y como utiliza nuestro servicio. Y cuando se necesite realizar alguna acción que necesite autenticación pedirle al usuario que ingrese su nombre y contraseña. Solo la apikey estaría insertada en el código fuente, la contraseña la tendría que insertar el usuario.

Hola,

API-KEY, API-KEY, sentadita me quedé... :D :D

Es correcto Domingo. Por cierto, ¿qué te pareció el ejemplo "EnlacesUsuario"? ¿Chulo a que sí? ¿eh? :eek: :eek: :D

Ahora la piedra queda en el tejado de implementar lo dicho. Cómo proporcionar (¿a quien lo solicite?) una clave para usar el API. Cómo conformar dicha clave (creo que esto sería lo de menos, pero, nada está libre de posibles problemas). Cómo implementar esto en Loturak... un nuevo formulario... un nuevo apartado... utilizar una nueva tabla en la base de datos... va a ver que coger el toro por los cuernos. :)

Maldita sea... hoy estoy bicho, bicho, bicho. :D

mmm... no tengo la razon especifica en este momento y fue algo que aprendi en un foro de Borland de uno de los 2 tipos que hacen herramientas de seguridad para Delphi... y como muchas cosas me gravo el "no es bueno hacer x" y se me borrar los 5 o 6 post donde se explica porque ;)

Algo tiene que ver con el proposito de un hash: Una funcion en un solo sentido que no sea reversable... y que la manera correcta que he leido es usar un "salt" para variar la cosa....

Creo que ya voy entendiendo seoane. Visto así parece bastante sólido. Me queda ahora la duda de entonces ¿para qué el https?

// Saludos

El https es necesario para que todo se comunique encriptado, si bien un método con el que comento nos "asegura" la autenticación, todos los demás datos se transmiten en claro. Volviendo al caso de messenger, cualquiera con un sniffer y el programa adecuado puede leer una conversación de messenger, dentro una red local se entiende, entonces ¿por que proteger tanto la contraseña?, porque mientras que te espíen una conversación puede ser grave, que suplanten tu identidad puede ser mucho peor.

En definitiva https es la mejor solución, la información viaja encriptada a través de la red, atravesando incluso los proxys. Aunque no se la dificultad que supondrá desde el lado del servidor implementar esto, desde el lado del cliente solo supone cambiar un par de parámetros.

Hola,

Nota del traductor: este Hilo no ha muerto, sólo está en hibernación, al cuidado de HAL, así que no hay problema. :D :D

Espero que no. Ya me parece que el hilo de Al sobre automatización web esta en cuidados intensivos :p , solo faltaba que se me muriera este también.

Por cierto, estaba trasteando con loturak y me devuelve el siguiente error:
¿Esta situación es temporal? o va a tardar un tiempo en volver a estar disponible.

Hola,

Efectivamente... es una situación "temporal", pero si tiempo fijo... es una huida hacia adelante. Es la forma de no decir "hasta que el tema de las API-KEYs famosas no esté resuelto el API de Loturak no será sino una quimera, una ilusión, de qué me suena a mí esto.

Efectivamente, puedes hacer pruebas "en local", es decir, si instalas Loturak en tu sistema podrías utilizar el API sin ese inconveniente, al menos. Este parón respecto al tema del API vino por el "Cross Site Scripting" que ya recordarás Domingo.

Desde entonces paramos en seco hasta poderlo soluccionar... creemos, en principio, lo que nos llevó un par de días. A continuación hemos estado solucionando errores y "bugs" de los que no puedes creerte, porque pasaste por allí unas cuantas veces sin verlos...

También en estos días hemos hecho algunas cosas más que solucionar errores. Por ejemplo ayer nos metimos a personalizar el reproductor MP3 que usamos en Loturak... recordarás el tango... lo que hemos podido hacer porque el original es gratuito y de código abierto.

Qué más cosas... qué más cosas... sí. Hemos hecho algunos cambios internos en la clase Usuario, que nos han ahorrado al menos dos consultas a la base de datos (Román, si lees esto, ahora mismo se hacen 8 consultas para construir las páginas que listan enlaces en Loturak. Además varias de ellas son consultas "de un dato", es decir, no demasiado pesadas, no sé cómo lo verás, pero, como ves, seguimos preocupándonos de esto.).

También construimos una clase "Enlace", que nos sirve también a modo de "plantilla", de modo que cuando antes utilizábamos métodos que requerían pasar como parámetro los datos de un enlace, digo, donde antes usábamos "Arrays asociativos" hoy usamos una clase, una plantilla, para todos los métodos. Con esto, además de dejar el asunto más claro (sabe uno a qué referirse cuando tiene que entregar los datos de un enlace), hemos conseguido reutilizar en varios sitios un sólo método: por ejemplo para insertar enlaces, actualizarlos, se utilizan sendos métodos de la clase BDatos... sea desde donde sea que lo hagamos.

Pero,... no quiero aburrir a nadie... ¡y bastante he hablado ya como para aburrir a cien mil! Conste que el tema del API está suspendido, por el momento, pero, que no hemos estado parados ni el día de nuestro cumpleaños. :D :D :D

:( Que pena, estaba empezando a dar forma a una idea para "aprovecharme" de loturak. Usar la descripción del enlace para almacenar contraseñas cifradas, el programa se encargaría de manejar la lista de contraseñas utilizando los procedimientos InsertarEnlace, ActualizarEnlace y EnlacesUsuario ...

Bueno, habrá que dejarlo por ahora. Por cierto, cual es el limite de enlaces y el tamaño máximo de la descripción. Porque podríamos hacer un "loturak Drive" al mas puro estilo "GMail Drive" ... :D Es broma, no te asustes.

Hola,

Es curioso que digas algo así, porque, últimamente lleva tiempo rondándome la cabeza una aplicación Web que sería una especie de "Gestor de contraseñas", a modo de los que existen para el "escritorio" pero en Web. :D

Pero es algo que no ha pasado de ser una obsesión... o ni ha llegado todavía a eso. :)

Uf, uf, uf... :D Na... te "banearía" el primer día. :eek: :D