Hi > The server would also need to "save" the clients' state somehow, like > saving the handler instance, to be able to recreate the previous > connections' state. Again this can be avoided with persistent connections.
Yeah, the good ol' state ... we all love 'em. In that case you have to take care on the client side, that's right. I just assumed the state lives primarily on the server end, where this would not be that much of an issue, but that doesn't habve to be the case. At the end, a stateless server is a nice thing to have. > Again if you store a cookie, the server needs knowledge about it. The server is free to completely ignore cookie contents. > That implies a parallel system serverside, more code, more maintenance. When it comes to security, there should absolutely be some checks on the server end. One should never rely on the fact that whatever comes in via HTTP is trustworthy data. I can send your server a handcrafted HTTP request without even having a browser open, let alone your app loaded. Client-side checks are good for performance, but in most cases not worth their salt security-wise. > I think I just made [...] of myself and really shows my lack of knowledge > regarding javascript. Don't be so negative. We all have to learn some basics every now and then. :-) > Since the iframe can access the parents objects, as long as the parent > initiates the connection and "owns" the connected client, the iframe can > get that client through window.parent, completely obliterating the > suggestion > I gave :) Ahwell, at least I got some more knowledge about javascript :) Not only that. There is a commonly ignored possibility for XSS via the "opener" attribute. https://mathiasbynens.github.io/rel-noopener/ https://gitlab.com/gitlab-org/gitlab-ce/issues/15331 https://bugs.launchpad.net/mahara/+bug/1558361 Have fun, JensG -----Ursprüngliche Nachricht----- From: Martin Hejnfelt Sent: Thursday, January 5, 2017 12:46 AM To: dev@thrift.apache.org Subject: Re: Inter-webpage persistent javascript transport Hi Jens, Thank you for taking time for this. Den 5. jan. 2017 00.05 skrev "Jens Geyer" <jensge...@hotmail.com>: Martin Hejnfelt wrote: > however then comes the > issue, that each webpage, when "browsing" through the app, will have no > knowledge about the previous connection, and as far as I know, there is no > way of "saving" a connection object like this in the browser for > persistance. Not the object, but you can save some identifier (e.g. a SessionID) into a cookie and/or pass it back and forth through each page reload, whatever makes more sense. That ID is then used to reinitialize the next page. Yes, this is what I've usually done when making similar projects from scratch, storing a session ID, which then acts as the token used, and authorized by the server. The "problem" with that approach is that the server must then have specific knowledge about this, thus it needs new code, some that works for this approach when dealing with a JS client, and another when dealing with a Java client (or any other raw socket client). The server would also need to "save" the clients' state somehow, like saving the handler instance, to be able to recreate the previous connections' state. Again this can be avoided with persistent connections. If the connection is persistent, the server/service handler doesn't need to differentiate between the different client types. Of course there would be two different servers one for raw sockets and one for websockets, but the handler codebase could be the same. > To keep a persistent thrift websocket connection on a javascript > based "webapp", where multiple pages should share the same > client instance, I propose to create a "TPageTransport" or something > like that, that utilizes javascripts features onmessage and postMessage, > so a persistent hidden top window/frame will have the "real" connected > client, while the pages (inside an 100% width/height iframe) initializes > clients" with the TPageTransport which then through these onmessage/ > postMessage methods gets data to and from the "real" client. So in other words we need the IFRAME only to preserve some information about the connection, right? And if you store that into e.g. a cookie, there is no need for the IFRAME anymore? In my head, the iframes content is what is actually seen by the user. It contains the webpages that contains the code which needs the thrift client to interact with the server. Again if you store a cookie, the server needs knowledge about it. That implies a parallel system serverside, more code, more maintenance. Second, you wrote plural “clients”. Does that read (a) “Only one IFRAME and one client at a time” or is it really (b) “more than one IFRAME / client in parallel”? Each page will, when loaded, create a client instance. Technically only one client will exist at a time, at least if only one iframe is present at all times, but the underlying websocket, in the top window, will be connected constantly. Have fun, JensG I tried actually doing some code and it seems to work just great. I made two new JavaScript transports, a TTopWindowTransport that will wrap the TWebSocketTransport in the top window and a TWindowTransport that is instantiated by each webpage loaded in an iframe. I can then keep a persistent connection, between pages, to a C++ server. In my head this mimicks how Thrift works when dealing with raw socket languages like C++, Java even PHP. In the past, we did not have these raw mechanics for web, and thus relied on XHR or the likes, but with the rise of websockets, we can now have webapps that work with (almost) the same mechanics as "traditional" applications. Best regards, Martin Hejnfelt
