[Fiware-portals] API de notificaciones

[Francisco de la Vega]

Hola,

¿Cual es el endpoint donde tienen que llegar las notificaciones de compra
al idM?

Saludos,
Francisco


El 6 de agosto de 2013 17:17, Antonio Tapiador del Dujo <
atapiador at dit.upm.es> escribió:

>  Hecho!
>
> El 06/08/13 16:56, Francisco de la Vega escribió:
>
>   Hola,
>
>  Para el desarrollo estoy utilizando una applicación de testing con
> client_id 16 y necesitaría que pudiera acceder a estas APIs.
>
>  Saludos,
>  Francisco
>
>
> El 6 de agosto de 2013 16:04, Antonio Tapiador del Dujo <
> atapiador at dit.upm.es> escribió:
>
>>  Hola Francisco,
>>
>> ya tienes el API lista en producción. Respecto al token, debería valer
>> cualquier formato descrito en el RFC 6750
>>
>> Solo la aplicación con id 18 debería tener permiso para atacar este punto
>> del API. Si tienes otras aplicaciones o pruebas, dime y las registro.
>> Cualquier duda o error, no dudes en consultarme
>>
>> Un saludo.
>>
>>
>> El 05/08/13 18:16, Francisco de la Vega escribió:
>>
>>   Hola,
>>
>>  Las notificaciones quedarían como:
>>
>> {
>>        "offering": {
>>                 "organization": "owner_organization",
>>                 "name": "offering_name",
>>                 "version": "offering_version"
>>        },
>>         "reference": "referencia_de_compra",
>>         "customer": "actor_id",
>>         "applications": [{"id": 16,
>>                                 "name": "app"},
>>                                {"id":20,
>>                                 "name":"app2"}]
>>  }
>>
>>  El campo customer contendria el actor_id tanto de un usuario como de
>> una organización.
>>
>>  Por otra parte ¿como quieres el token?, ahora mismo lo paso en la
>> cabecera Authentication: Bearer .token.
>>
>>  Saludos,
>>  Francisco
>>
>>
>> El 5 de agosto de 2013 17:46, Antonio Tapiador del Dujo <
>> atapiador at dit.upm.es> escribió:
>>
>>>  Hola Fancisco, también tienes lista el API de aplicaciones:
>>>
>>> https://github.com/ging/fi-ware-idm/wiki/API#applications
>>>
>>> El endpoint de compras en el IdM puede ser /purchases, ¿cómo queda el
>>> JSON al final?
>>>
>>> Un saludo.
>>>
>>>
>>> El 02/08/13 14:34, Antonio Tapiador del Dujo escribió:
>>>
>>>  Estupendo, ya lo tienes tanto en el wiki como desplegado en producción
>>>
>>> https://github.com/ging/fi-ware-idm/wiki/Using-the-deployed-instance
>>>
>>> Por cierto, he aprovechado para cambiar el parámetro organization.namea organization.displayName siguiendo el esquema de grupos de SCIM que se ha
>>> acordado como API en el paquete de seguridad. Aún tengo la tarea pendiente
>>> de revisarlo en profundidad, por lo que es posible que haya algún que otro
>>> pequeño cambio. Os aviso.
>>>
>>> Un saludo.
>>>
>>> El 02/08/13 13:15, Francisco de la Vega escribió:
>>>
>>> OK, entonces creo que estaría bien pasar el actor_id como customer, de
>>> hecho me vendría bien para gestionar otras cosas de los usuarios y
>>> organizaciones en el Store.
>>>
>>>
>>> El 2 de agosto de 2013 13:10, Antonio Tapiador del Dujo <
>>> atapiador at dit.upm.es> escribió:
>>>
>>>>  Como veas, cambiar el API me supone escribir una línea más de código,
>>>> así que no es mucho problema. Lo que quede mejor.
>>>>
>>>>
>>>> El 02/08/13 13:09, Francisco de la Vega escribió:
>>>>
>>>> Creo que lo mas sencillo sería incluir un tipo (organización o usuario)
>>>> e incluir su id. Lo del actor_id estaría bien pero te forzaría a cambiar la
>>>> API para incluir ese valor en la respuesta.
>>>>
>>>>
>>>> El 2 de agosto de 2013 13:03, Antonio Tapiador del Dujo <
>>>> atapiador at dit.upm.es> escribió:
>>>>
>>>>>  En el IdM el nombre de la organización no es único. Existen nicknames
>>>>> tanto para organizaciones como usuarios que son únicos pero no inmutables,
>>>>> es decir, tanto usuarios como organizaciones los pueden cambiar, aunque
>>>>> deben poner uno que no esté cogido. Lo que es único e inmutable son los
>>>>> ids, tanto por usuario como organización.
>>>>>
>>>>> Los ids se pueden repetir entre distintos modelos. Es decir, hay
>>>>> organizacion 1 y usuario 1. Existe otro id en el idm, el id de actor, que
>>>>> sí es único para usuarios, organizaciones y aplicaciones. Es decir, si
>>>>> existe usuario con actor_id == 1 no puede existir organizacion con actor_id
>>>>> == 1.
>>>>>
>>>>> Usando nicknames ahora mismo podría existir condiciones de carrera, es
>>>>> decir, un usuario carga la página de una organización en la store, la
>>>>> organización cambia su nickname y posteriormente se realiza la compra.
>>>>>
>>>>> Yo me quedaría más tranquilo si incluís un id por cliente, tal como
>>>>> 'organization-1' usando los ids de organizacion, o directamente el id de
>>>>> actor. ¿Qué te parece?
>>>>>
>>>>>
>>>>> El 02/08/13 12:52, Francisco de la Vega escribió:
>>>>>
>>>>>  Creo que en el caso del idM lo mejor es tener una URL única a la que
>>>>> mandar las peticiones, por otra parte el customer ahora mismo contiene el
>>>>> nickname del usuario o el nombre de la organización dependiendo de como se
>>>>> haga la compra (En el Store el nombre de una organización es único), si el
>>>>> nombre de las organizaciones no es único en el idM podría incluir un campo
>>>>> más con el identificador de la organización (estoy suponiendo que se puede
>>>>> identificar un usuario por su nickname).
>>>>>
>>>>>  Saludos
>>>>>
>>>>>
>>>>> El 2 de agosto de 2013 12:40, Antonio Tapiador del Dujo <
>>>>> atapiador at dit.upm.es> escribió:
>>>>>
>>>>>> Estupendo Francisco, un par de dudas:
>>>>>>
>>>>>> * ¿Manejamos la misma URL en el IdM para cada oferta, o se necesita
>>>>>> registrar una nueva URL por oferta?
>>>>>> * ¿customer es el nombre de la organización o usuario cliente? Este
>>>>>> nombre puede no ser único o cambiar ¿Se podría pasar el id y/o tipo?
>>>>>>
>>>>>> El 02/08/13 10:41, Francisco de la Vega escribió:
>>>>>>
>>>>>>  Hola,
>>>>>>>
>>>>>>> Con respecto a la API de notificaciones, el Store manda una petición
>>>>>>> POST a la URL registrada al crear la oferta con un content type
>>>>>>> application/json y con el cuerpo:
>>>>>>>
>>>>>>> {
>>>>>>>        "offering": {
>>>>>>>                 "organization": "owner_organization",
>>>>>>>                 "name": "offering_name",
>>>>>>>                 "version": "offering_version"
>>>>>>>        },
>>>>>>>         "reference": "referencia_de_compra",
>>>>>>>         "customer": "usuario_u_organización_cliente"
>>>>>>> }
>>>>>>>
>>>>>>> Entiendo que para la integración con el idM lo único que haría falta
>>>>>>> seria incluir un un campo conteniendo las aplicaciones compradas, algo como:
>>>>>>>
>>>>>>> POST
>>>>>>> Content-Type: application/json
>>>>>>>
>>>>>>> {
>>>>>>>        "offering": {
>>>>>>>                 "organization": "owner_organization",
>>>>>>>                 "name": "offering_name",
>>>>>>>                 "version": "offering_version"
>>>>>>>        },
>>>>>>>         "reference": "referencia_de_compra",
>>>>>>>         "customer": "usuario_u_organización_cliente",
>>>>>>>         "applications": [{"id": 16,
>>>>>>>                                 "name": "app"},
>>>>>>>                                {"id":20,
>>>>>>>                                 "name":"app2"}]
>>>>>>> }
>>>>>>>
>>>>>>> Saludos,
>>>>>>> Francisco
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>  _______________________________________________
>>> Fiware-portals mailing listFiware-portals at lists.fi-ware.euhttps://lists.fi-ware.eu/listinfo/fiware-portals
>>>
>>>
>>>
>>> _______________________________________________
>>> Fiware-portals mailing list
>>> Fiware-portals at lists.fi-ware.eu
>>> https://lists.fi-ware.eu/listinfo/fiware-portals
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-portals/attachments/20130807/c64fd044/attachment.html>