[Fiware-portals] API de notificaciones

[Francisco de la Vega]

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.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> 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/20130806/c50b13dd/attachment.html>