3 ms·
Two weeks ago we evaluated a bunch of cross domain solutions. The Web Intents examples didn't even work. Porthole wasn't maintained. EasyXDM was good but didn't
by radagaisus 15y ago
Two weeks ago we evaluated a bunch of cross domain solutions. The Web Intents examples didn't even work. Porthole wasn't maintained. EasyXDM was good but didn't have the flow we wanted. We eventually decided to use socket.io
- jacobolus 15y agoYou wanted to send messages from one browser window to another within the same browser (or from one frame to another), so you used socket.io, which presumably requires a persistent server connection in both windows/frames? That seems rather silly, tying up not only your server resources but also your users’ CPU and bandwidth &c., entirely unnecessarily. (Or maybe I’m misunderstanding your use case..?)
- radagaisus 15y agoYou got the use case wrong :-) We wanted to continually send information from third party sites to our site, that's why we picked socket.io. But for our login flow socket.io felt like on overkill, so I tried to use EasyXDM.
- sciurus 15y agoCould you share the approaches you tried for login?
- radagaisus 15y agoSure. Basically the user is on site A and presses a link that opens a pop up from our site. The pop up logs him in, either through oAuth or a local login. Then site A should get the user details back. EasyXDM works with iframes, not with popups, so the only option we had (well, the one I thought about) was sending a request to the server every few ms to check if the user logged in. That's pretty horrible. We needed continuous updates from site A to our site so we decided to use socket.io. Sockets don't have sessions, so we listen to a random channel name, and pass that channel name to the popup, which sends the user details as a message to that channel. That's still complicated. I'm still not sure it's the right approach. And I'm not an expert. But it works for now.