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/20130806/3056f817/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy