Ability to pass data to game server via the web client's url

ID:1756831
 
Jan 6 2015, 10:21 pm
Applies to:Webclient
Status: Open
Issue hasn't been assigned a status value.
Simple request, some ability to pass data to the game server that is strongly tied to a web client connection. Ideally it would be a get field in the web client url, like &topic=itemone=blah;itemtwo=blah

Another option would be to pass url hash (things after a # in a url) data to the webclient iframe address so that it could be retrieved with a webclient custom control using javascript's window.location.hash and passed to the server that way. (since same origin security in javascript doesn't allow javascript in a iframe to read the url of the parent window if the domains don't match)

A plus would be a way to do this for DS byond:// links as well, but I wouldn't be shocked if this already exists.

As an aside: Another side project you could look at doing is a full blown two way communication gateway between the hosting site and the web client for embedded web clients. You already do this between the inner webframe (game server) and the outer webframe (byond server) so it would be easy to refactor that to work for this.
Jan 6 2015, 10:28 pm
To communicate between BYOND games, I'm pretty sure that world.Export() (and thus world.Topic()) would work on "webclient servers" just as well as it does for other server (since they're identical; they're both just Dream Daemon, and both have byond:// addresses).

Other than that, I don't know enough about it. Like, from where are you passing data, if that matters?
Jan 6 2015, 10:48 pm (Edited on Jan 6 2015, 10:56 pm)
In response to Kaiochao
Kaiochao wrote:
Like, from where are you passing data, if that matters?

What i mean, is i want to pass data to the web client on connection from the website that has the web client link.

So i could give users a link like: to play the game, click: http://www.byond.com/play/ someserver.com:1337?topic=usertoken=49ad8e121380ac23d97acb49 ;ref=playnow

and have that been passed to client/New(topicData)

You can use this for strongly linking client connections to site/forum accounts, (ridding the need of byond accounts).

You can use this for providing an oauth style authentication of someone by byond account without the server having to have the byond account's username/password to verify the user. (useful for linking a byond ckey to someones site account in a secure matter) <--- this is my intended use. So that admins automatically have admin status on the site, the forums, the admin tools, the wiki, etc, without having to add them as admins to each service and remember to demote them from each when they go rouge.

You can use this for specifying what part of a game to join for games that serve more then one base world or starting point thru use of z levels.

Its about being able to pass data to the server with the connection.

Jan 21 2015, 8:14 pm
Two weeks have passed.

Any update?
Jan 22 2015, 7:20 am
Sorry, somehow I missed this. (It probably didn't help that I was sick as a pig at the time it was first posted though.) I highly support the concept of passing data to the game from the outer frame, and it ties in with some other ideas I've had. However, the idea I had in mind was to pass data to the client, not the server. All of the concepts I have planned revolve around the inner frame and the outermost frame talking to each other, but that's all client-side.

One question that comes up is: Where would the server handle this information (e.g., in which proc) and when and how would it be sent? It's not typical for users connecting to a game to pass along auxiliary info, so this sounds like it'd be brand new functionality--not just for the webclient but for BYOND in general. How do you envision this working on the server end?
Jan 22 2015, 8:17 am
Actually I found a loophole that can do this, so it's already possible. It just isn't very easy to work with.

What you do is call a winset() command in JavaScript. This can be initiated from a server-side winset() .skin command, but in order to properly generate the needed properties object, I have only been successful by using eval(), since I can't seem to define new vars or functions otherwise.

Back on the server's side of things, you have to have a properly named verb to accept the command. This verb would most likely set a var or vars somewhere accessible to the proc that first called winset(). What makes this somewhat annoying is that the proc that initiated this would have to run a loop with a timeout, to check for when the values of the vars change, which means the data has been received, and you can do something with it.

I hope all of this makes sense. I would show an example, but the code is just too messy right now. Am I right in thinking that the only way to define new vars or functions through the .skin command is by wrapping the JavaScript in an eval() call? It would be nice if that wasn't the case.
Jan 22 2015, 9:15 am
In response to Multiverse7
Multiverse7 wrote:
Actually I found a loophole that can do this, so it's already possible. It just isn't very easy to work with.

What you do is call a winset() command in JavaScript. This can be initiated from a server-side winset() .skin command, but in order to properly generate the needed properties object, I have only been successful by using eval(), since I can't seem to define new vars or functions otherwise.

Back on the server's side of things, you have to have a properly named verb to accept the command. This verb would most likely set a var or vars somewhere accessible to the proc that first called winset(). What makes this somewhat annoying is that the proc that initiated this would have to run a loop with a timeout, to check for when the values of the vars change, which means the data has been received, and you can do something with it.

This sounds to me though like you're trying to send data to the client from the server, wait for it to do something, and then handle the result on the server. It's not actually what was brought up in this thread.

However, I believe you're entirely right about the sequence that would be involved for what you're trying to do. Or, instead of sleeping the calling proc, you could use a callback setup which is cleaner.

I hope all of this makes sense. I would show an example, but the code is just too messy right now. Am I right in thinking that the only way to define new vars or functions through the .skin command is by wrapping the JavaScript in an eval() call? It would be nice if that wasn't the case.

The .skin command really ought to be doing an eval() already, so this surprises me. But maybe it needs to be window.eval(), and isn't one. If that's the case then it might be executing in a local context, and that could trip it up. That's definitely not intended behavior so I suspect it's a bug.
Jan 22 2015, 11:37 am
In response to Lummox JR
Lummox JR wrote:
The .skin command really ought to be doing an eval() already, so this surprises me. But maybe it needs to be window.eval(), and isn't one. If that's the case then it might be executing in a local context, and that could trip it up. That's definitely not intended behavior so I suspect it's a bug.

I made a bug report with some more details.

Sorry. I wasn't sure that this topic was actually about sending data to another game entirely.
Jan 22 2015, 12:12 pm
Actually I think the main point of this topic is for passing data from the page that has the iframe, to the webclient itself.
Jan 22 2015, 2:38 pm
Huh. I was actually going to request this myself. Query string from page URL getting passed as topic data in client/New().
Jan 22 2015, 10:41 pm
In response to Super Saiyan X
Super Saiyan X wrote:
Huh. I was actually going to request this myself. Query string from page URL getting passed as topic data in client/New().

Awesome idea, great way to track traffic referrers too.
Jan 22 2015, 11:09 pm
Couldn't this just utilize world.params?
Feb 4 2015, 6:01 am
Honestly, if the web client would keep all url hash data (everything after the # in a url) synchronized between the two or so embeds/iframes this would be easy to do with javascript using window.location.hash.

Or at the least, passing the hash data from the outer url/embed to the inner iframe so it can be read by javascript skin controls running on the webclient to be topic'ed to the server.

How ever, my need for this has passed, i figured out a slightly different way to do what i wanted to do, it's just not as secure if i can't strongly tie data to the connection.