[EoA] Store Sript info on Site instead of Computer

[Chuuuuck]

Allow scripts, approved by the administrators and mods, to store small amounts of info on the site instead of users personal computers.


Specifics/Details:

• The script mods could identify certain scripts that would benefit from some information stored on the site
• They could get approval from the administration
• They then update these scripts to allow for this small information share

How this will benefit the site and/or other comments:

• It would be of huge benefit to users who use multiple computers
• In today's society, most people are around numerous computers in a given day or week and this would make it where they can use each one interchangeably to play the game the way they choose
• Scrips such as chatglove and watch this game would update automatically wherever you log in (as long as they are on that computer) so when you switch computers you don't all of the sudden think you have no watched games or you have to check chat in every one of your games

I have talked to many people who this is a problem for. I have suggested it before but it was before the suggestions area was revamped and I don't think it was really given any real thought. There seems to be little to no downside unless I am wrong that this would bog down the site more than it seems it would. I know it is already coded to do stuff like this in a sense because when I log into different computers it can always remember which forums I have read or if I have looked at my inbox or not. I just want it to remember these exact same things for chatglove and watch this game.

[army of nobunaga]

actually this is a good idea.

[darth emperor]

Well that means that in both computers should be BoB and the scripts.....not just in one....

[MeDeFe]

This needs some elaboration, how exactly would you want this to work? Give us a detailed example, will you?

[Foxglove]

This needs some elaboration, how exactly would you want this to work? Give us a detailed example, will you?

Scrips such as chatglove and watch this game would update automatically wherever you log in (as long as they are on that computer) so when you switch computers you don't all of the sudden think you have no watched games or you have to check chat in every one of your games

The requested idea here is that variable data that is currently stored by the browser (BoB snapshots, chatglove game chat counts, Watch This Game game lists) would instead be stored by CC, so that when users access Conquer Club from different computers their script data is available and up to date.

So, for a a detailed example for BoB, as it is the most popular script:
1. A user takes a snapshot of a game from their home computer.
2. The snapshot is stored by Conquer Club.
3. The user checks the status of the game on Conquer Club from their work computer, and is able to access their snapshot from step 1.
4. PROFIT.

[Chuuuuck]

This needs some elaboration, how exactly would you want this to work? Give us a detailed example, will you?

Scrips such as chatglove and watch this game would update automatically wherever you log in (as long as they are on that computer) so when you switch computers you don't all of the sudden think you have no watched games or you have to check chat in every one of your games

The requested idea here is that variable data that is currently stored by the browser (BoB snapshots, chatglove game chat counts, Watch This Game game lists) would instead be stored by CC, so that when users access Conquer Club from different computers their script data is available and up to date.

So, for a a detailed example for BoB, as it is the most popular script:
1. A user takes a snapshot of a game from their home computer.
2. The snapshot is stored by Conquer Club.
3. The user checks the status of the game on Conquer Club from their work computer, and is able to access their snapshot from step 1.
4. PROFIT.

This is exactly right. I don't know much about writing scripts and such so I know I am probably not the best at explaining it. But Fox can probably do a much better job of explaining it as I have had this discussion with her in the past and she knows more about writing scripts!

This would be the most amazing update this site has ever had IMO, haha

[Chuuuuck]

I think most people are failing to comment on this after viewing because they see no better way to improve the suggestion. They think it is an awesome idea and we should go ahead and implement it. Wouldn't you say Dako?

[Ace Rimmer]

I say so Chuuuuck, although I speak for myself and not Dako

[army of nobunaga]

I would like to see BoB implimented into the server, not just the memory of settings. Would make a lot of slow computers faster

[drunkmonkey]

I just realized that, while having read this suggestion several times, I never actually gave any support. I would love this feature. I play about half my games on one computer and half on the other, so unless it's the weekend, snapshots are generally useless to me.

[iamkoolerthanu]

I think most people are failing to comment on this after viewing because they see no better way to improve the suggestion. They think it is an awesome idea and we should go ahead and implement it. Wouldn't you say iamkoolerthanu?

LOL I was reading this, didn't plan on commenting (since I had nothing to add), but this comment made me

I support this improvement!

[sherkaner]

I would like to see BoB implimented into the server, not just the memory of settings. Would make a lot of slow computers faster

That's not how this would work, it would actually make those computers slightly slower.

[Dako]

Yeah, such an options would be great. But it means they will not longer be scripts and will be parts of CC and maintainers should be able to access CC data and tables. This is a hard decision to make because this leads script maintainers to the CC developers level. And I guess that lack doesn't plan this for now.

But yeah, that would be totally awesome.

[Chuuuuck]

I will put my disclaimer out there again. I am not a code writer so I don't know.

But is there a way to some how allow this information to piggy back on the site in a secure way but not put them at the same level as developers? Maybe only allow 1 trusted script writer access to change this part. I don't know.... just thinking while typing.

[Foxglove]

I will put my disclaimer out there again. I am not a code writer so I don't know.

But is there a way to some how allow this information to piggy back on the site in a secure way but not put them at the same level as developers? Maybe only allow 1 trusted script writer access to change this part. I don't know.... just thinking while typing.

Yes, you know it is actually an interesting technical problem. I am going to try and think of some possible solutions to put here.

[Dako]

Well, I can think only of abstracted database controller that uses AJAX/JSON. So we have an access to the database in some secure manner with tokens. And since the script is stored on the client side... we need to compress our scripts so they are made unreadable by other people.

And this abstracted layer should give as create/view/edit rights on a certain database we need for our scripts. That is damn hard to implement I must say :-D. (Or we can use phpMyAdmin - it is already installed on the CC server and exposed to outer world). But still, we need some abstraction layer for ajax queries and we need tokens for secure connections.

Unless we are able to do it server-side and write it as a PHP code. No problems with security then.

[Foxglove]

Well, I can think only of abstracted database controller that uses AJAX/JSON. So we have an access to the database in some secure manner with tokens. And since the script is stored on the client side... we need to compress our scripts so they are made unreadable by other people.

Yes, I had thought of some token/authentication mechanism too. But still - even if we obfuscate the scripts they will be readable by people anyway (with a bit of effort) so that's not secure.

And this abstracted layer should give as create/view/edit rights on a certain database we need for our scripts. That is damn hard to implement I must say . (Or we can use phpMyAdmin - it is already installed on the CC server and exposed to outer world). But still, we need some abstraction layer for ajax queries and we need tokens for secure connections.

Yes - there are issues with this still though, as how do we restrict access to only certain scripts? Or are all scripts allowed to submit/read data? Still, the security problem remains unsolved, as we cannot secure a purely script-based solution. So that then requires some sort of additional CC layer, perhaps certain scripts are hosted/run by CC, so they can then can be generated on the fly with the appropriate previously suggested tokenization. But that requires additional overhead for both lack and script developers, and introduces quite a bit of complexity.

Unless we are able to do it server-side and write it as a PHP code. No problems with security then.

I think this is quite unlikely to happen.

[sherkaner]

Hmm, this is really going into the details..

I slightly disagree here. With every AJAX-request done at the moment, everyone is already sending back a cookie containing the security info. So we can just use this method for security, that's not where the problem is.
Security through obstrufication in javascript (if you're considering minifying etc) is impossible, I can just see the request I'm sending under normal circumstances. There are tools to send them in a slightly altered form even..
So I guess I would consider sending the information in some format in the body of a POST-request. The server then has to decide whether it's valid and put it in the database if it is. Retrieving the information should be by a GET, response could be some JSON.
Determining what is valid will be the most important part, you can't have a script insert data at will. If the script goes wrong, it should have no way to bring the server down.. And in the end that's a risk Lack might be unwilling to take.

[Foxglove]

Hmm, this is really going into the details..

I slightly disagree here. With every AJAX-request done at the moment, everyone is already sending back a cookie containing the security info. So we can just use this method for security, that's not where the problem is.
Security through obstrufication in javascript (if you're considering minifying etc) is impossible, I can just see the request I'm sending under normal circumstances. There are tools to send them in a slightly altered form even..
So I guess I would consider sending the information in some format in the body of a POST-request. The server then has to decide whether it's valid and put it in the database if it is. Retrieving the information should be by a GET, response could be some JSON.
Determining what is valid will be the most important part, you can't have a script insert data at will. If the script goes wrong, it should have no way to bring the server down.. And in the end that's a risk Lack might be unwilling to take.

Yes - the "script data" database would really need to be isolated - it would be too risky otherwise.

And I don't think that the cookie security info is currently restrictive enough - unless all scripts, written by anyone, would be allowed to save data. Because even if I have my authenticated security info, there is no way (that I have thought of yet ), to guarantee that the specific script I'm running is authorized to submit data.

[sherkaner]

Yes - the "script data" database would really need to be isolated - it would be too risky otherwise.

And I don't think that the cookie security info is currently restrictive enough - unless all scripts, written by anyone, would be allowed to save data. Because even if I have my authenticated security info, there is no way (that I have thought of yet ), to guarantee that the specific script I'm running is authorized to submit data.

Agreed, there is no secure way to determine the script sending data. That actually was 1 of my assumptions.

[Dako]

Of course, we will be forced to use POST to send requests. We can even hash the post body by the token (individual token given by lack for every script that is proven) - that way the obfuscation might actually work.

And yes, script DB should be isolated for sure. The other thing I am concerned about - load on CC server. Imagine ... 20 or more requests from each game load from each plugin user per plugin (just to retrieve settings and common data). That will crash the servers. And right now all the process lies on the client side.

[Chuuuuck]

You all are over my head. If you need any good engineering work done though you can call me.

But I am liking the discussion. Discussion brings possible solutions which brings a way to make CC that much better!

[Dako]

The only problem I see... JavaScript is not secure. I guess it cannot be secure by default because it is exposed to user.

So unless we get to a server side and have a tool of uploading new versions (like it is being done with maps now) - we are stuck with "lame" solutions only. I doubt anyone will try to hack BOB or any other script by still, making them insecure by default is bad.

[Chuuuuck]

I guess we never came up with a solid way to do this from you techies? (I don't mean that in a derogatory way)

[Dako]

Not unless we get our hands to a server side I guess.