Buenos días
Me podéis pasar las IPs y los nombre de dominio de los portales, tanto en la parte del testbed como del lab (para OIL y campus party)?. Además comentarme si necesitáis algún nombre de dominio nuevo y me encargué de meterlo en el DNS.
Muchas gracias,
Saludos,
Henar
De: fiware-portals-bounces at lists.fi-ware.eu [mailto:fiware-portals-bounces at lists.fi-ware.eu] En nombre de Francisco de la Vega
Enviado el: miércoles, 07 de agosto de 2013 9:14
Para: Antonio Tapiador del Dujo
CC: fiware-portals at lists.fi-ware.eu
Asunto: Re: [Fiware-portals] API de notificaciones
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
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-portals/attachments/20130807/db3e9d5f/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy