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