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