Hola Francisco,
El endpoint de compras es https://idm.lab.fi-ware.eu/purchases
Un saludo.
El 07/08/13 09:14, Francisco de la Vega escribió:
> 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 <mailto: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 <mailto: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 <mailto: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.name <http://organization.name> a
>>>> 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
>>>>> <mailto: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
>>>>>> <mailto: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
>>>>>>> <mailto: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 list
>>>> Fiware-portals at lists.fi-ware.eu <mailto:Fiware-portals at lists.fi-ware.eu>
>>>> https://lists.fi-ware.eu/listinfo/fiware-portals
>>>
>>>
>>> _______________________________________________
>>> Fiware-portals mailing list
>>> Fiware-portals at lists.fi-ware.eu
>>> <mailto: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/52dd60d2/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy