Antonio, No sé si nosotros ya la enviamos, pero por si acaso la URL de sign out del portal de Cloud es: http://cloud.lab.fi-ware.eu/#auth/logout Saludos, Javi. 2013/10/3 Javier Cerviño <jcague at gmail.com> > Hola Alvaro, > > CORS no sólo es para leer respuestas. Si un servidor no soporta CORS no le > llegará nunca la petición ya que el navegador no lo enviará, por lo que no > recibirá nunca la petición al endpoint del logout en vuestro servidor. > > Saludos, > Javi. > > > 2013/10/2 Alvaro Arranz <aarranz at conwet.com> > >> Hola, >> >> siento tardar en responder, el proporcionar un endpoint para que se haga >> el logout de nuestras aplicaciones no es ningún problema. Ahora, ¿el CORS >> te refieres para hacer peticiones al IdM? vamos en principio el problema >> con el CORS es para leer las respuestas, supongo que no es interesante la >> respuesta que pueda devolver este endpoint de logout, si funciona bien y si >> no ha funcionado seguramente sea porque no estaba el usuario loggeado, >> ¿no?. De todas formas, otra vez, nosotros no tenemos ningún problema en >> hacer que este endpoint devuelva las cabeceras necesarias para que funcione >> el CORS. >> >> Un saludo. >> >> >> 2013/9/18 Antonio Tapiador del Dujo <atapiador at dit.upm.es> >> >>> Hola Alvaro, efectivamente. Serían peticiones AJAX a cada una de las >>> aplicaciones. >>> >>> Nosotros proporcionaríamos el javascript integrado en la barra superior, >>> pero cada portal nos tendríais que proporcionar la llamada HTTP >>> correspondiente, además de gestionar el tema de CORS >>> >>> ¿Cómo lo véis? >>> >>> >>> El 18/09/13 15:05, Alvaro Arranz escribió: >>> >>> Hola Antonio, >>> >>> ok, entonces lo que propones es que hagamos una petición ajax a cada >>> una de las URL de las aplicaciones para el sign out, ¿no?, la lista de URLs >>> nos la tendrá que pasar el IDM, supongo. >>> >>> Un saludo. >>> >>> >>> 2013/9/16 Antonio Tapiador del Dujo <atapiador at dit.upm.es> >>> >>>> Hola, >>>> >>>> Otra opción que se barajó en la reunión sería implementarlo en la parte >>>> cliente con javascript, de manera que sea el navegador el que hacer las >>>> llamadas de sign out a las aplicaciones del portal. De esta manera >>>> resolveríamos el tema de las sesiones. ¿Qué os parece? >>>> >>>> Un saludo. >>>> >>>> El 11/09/13 11:38, Alvaro Arranz escribió: >>>> >>>> Hola Juanjo, >>>> >>>> realmente el problema es que no se dio una solución, se comentó que >>>> iba a haber ese problema y que habría que darle una solución. Esto paso en >>>> la primera reunión de agosto. Yo propuse en la segunda reunión de agosto >>>> que esto podría solucionarse si el IdM notificara a las aplicaciones >>>> implicadas de que el usuario ha cerrado la sesión, pero evidentemente era >>>> algo para estudiar, sobre todo entiendo que estudiar por el equipo del IdM >>>> dado que son los que conocen mejor que es lo que se puede hacer y que es lo >>>> que realmente puede encajar en la arquitectura. >>>> >>>> Personalmente he estado pensando y puede que tenga algunas lagunas, >>>> de tipo, si un usuario está loggeado en dos ordenadores, ¿tiene sentido que >>>> si te desconectas de uno se cierre la sesión del otro?. Son casos extremos, >>>> pero que por otra parte, por ejemplo Google, los cuidan muy bien, y yo no >>>> sé que posibilidades hay de que esto funcione igual si se implementa el >>>> single sign off usando la estrategia que propuse. El problema estaría en >>>> que el IdM da un token diferente a cada Applicación, por lo tanto, la única >>>> forma que veo ahora mismo para notificar que un usuario ha cerrado la >>>> sesión es indicando el identificador del usuario, y por lo tanto las >>>> aplicaciones no sabrían diferenciar que sesión tienen que cerrar. ¿Podría >>>> el idm guardar una lista con los tokens que ha dado usando la misma sesión >>>> interna del IdM?¿podría esta ser la solución? >>>> >>>> De todas formas, lo que yo si veo claro es que es el idm el que se >>>> tiene que encargar de proporcionar esta solución, dado que es la pieza >>>> central que conoce a que aplicaciones tiene acceso un usuario. >>>> >>>> Por otro lado, ya aviso, que nuestra idea es que los widgets de >>>> wirecloud accedan al resto de servicios (context broker, object storage, >>>> etc...) usando el token que le haya dado el IdM a wirecloud. El principal >>>> problema es que ese token sirve para pedir info al IdM en nombre de la >>>> aplicación a la que está asociada el token. Ejemplo: >>>> >>>> 1. Wirecloud le pasa el token que tiene a una instancia del object >>>> storage. >>>> 2. El object storage usaría el token para ver si el usuario tiene >>>> permisos para acceder, pero el token siempre le daría acceso dado que >>>> realmente está ligado a wirecloud y dado que el IdM ya se lo ha dado, >>>> siempre sería válido, *independientemente de si el usuario tiene >>>> acceso a esa instancia*. >>>> 3. Si el object storage usa ese token para pedir la información de >>>> roles y tal al IdM, este *recibiría la info correspondiente a los >>>> roles de Wirecloud*, no a los del object storage. >>>> >>>> Nosotros, para el store y para la campus party, la solución que hemos >>>> usado es que el store cuando recibe peticiones de wirecloud usando tokens >>>> del IdM, es la siguiente: el token se utiliza para obtener info del >>>> usuario, con esa información se busca el último token que el IdM le ha dado >>>> a la Store para ese usuario y este es el que se utiliza para pedir la >>>> información necesaria del IdM para la store (posiblemente el token ha >>>> caducado de alguna manera, y es el caso en el que el store refresca el >>>> token). >>>> >>>> Evidentemente con la Campus Party y tal, no ha habido tiempo para >>>> entra en más detalles, pero ya iré mandando más correos con problemas con >>>> esta parte de la integración. >>>> >>>> Un saludo. >>>> >>>> >>>> >>>> 2013/9/10 Juanjo Hierro <jhierro at tid.es> >>>> >>>>> Hola, >>>>> >>>>> Ahora que ha pasado la Campus, deberíamos ponernos manos a la obra >>>>> con el desarrollo de lo que hiciera falta para implementar el Single >>>>> Sign-out ... >>>>> >>>>> ¿ Quiere alguien romper el hielo en esta misma lista y recordarnos >>>>> que solución se había propuesto y acordado allá por finales de Julio o >>>>> principios de Agosto para confirmar que todos estamos de acuerdo con la >>>>> misma y pasar a implementarla ? >>>>> >>>>> Gracias, >>>>> >>>>> -- Juanjo >>>>> >>>>> ------------- >>>>> Product Development and Innovation (PDI) - Telefonica Digital >>>>> website: www.tid.es >>>>> email: jhierro at tid.es >>>>> twitter: twitter.com/JuanjoHierro >>>>> >>>>> FI-WARE (European Future Internet Core Platform) Coordinator >>>>> and Chief Architect >>>>> >>>>> FI-PPP Architecture Board chairman >>>>> >>>>> You can follow FI-WARE at: >>>>> website: http://www.fi-ware.eu >>>>> facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 >>>>> twitter: http://twitter.com/FIware >>>>> linkedIn: http://www.linkedin.com/groups/FIWARE-4239932 >>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> Fiware-portals mailing list >>>>> Fiware-portals at lists.fi-ware.eu >>>>> https://lists.fi-ware.eu/listinfo/fiware-portals >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>>> >>>> >>> >>> >> >> _______________________________________________ >> 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/20131003/e56dee99/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy