Yiyotop / pyrail

Automatically exported from code.google.com/p/pyrail
0 stars 0 forks source link

Lack of input validation can cause AI errors after save #29

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Launch pyRO-RAIL
2. Open any lua file inside RO\AI\USER_AI directory
3. Make changes in the GUI and save

What is the expected output? What do you see instead?
The expected output is that pyRO-RAIL does not open the file. Instead, it 
should give a warning or an error.

What version of the product are you using? On what operating system?
v202-5 on Windows

Please provide any additional information below.
You can check that the first few characters are "rail_state" (eg, the first 
line generated by RAIL is "rail_state = {}" and the output from pyRO-RAIL is 
similar). For users that are unfamiliar with RAIL's configuration setup, this 
will help prevent them from using your GUI to disrupt the RAIL setup as seen 
here: http://code.google.com/p/ro-rail/issues/detail?id=53. The user mistakenly 
used pyRO-RAIL to edit the AI\USER_AI\State.lua file.

Original issue reported on code.google.com by faithful...@gmail.com on 6 Jan 2011 at 4:23

GoogleCodeExporter commented 8 years ago
Hi faithful,

I saw that issue that was posted on RO-RAIL, and wondered how exactly the user 
was able to do that. I had my guesses.

In order to open up any file, RAIL_State must be part of the beginning of the 
file name, unless the user chooses to change the default "files of type" 
dialogue to all files.

In the function ReadStateDict(self), I perform the "rail_state = {}" string 
search. If it is not found, it performs another check for the string 
"rail_state = {", which is what you'd expect to find in a state file before 
RO-RAIL rewrites the file. In both cases, one of two validation error messages 
should pop up ("No new information to read from RAIL." and "Unknown State file 
specified.")

Unfortunately, a newer feature added disabled this check. It has been 
re-enabled in the latest version so the dialogues will now return when the 
'load' button is pressed.

Of note, a user can still hose his or her own files by editing the state file 
location manually. There is nothing currently stopping pyRO-RAIL from 
overwriting a file at the specified location. I'm reluctant to change this to a 
read-only field as it is used often by people who use multiple configuration 
files (for testing, for instance, I write to a file called 
RAIL_State.homu.new.lua, even when RAIL_State.homu.new.lua is a non-existant 
file).

Original comment by landstei...@gmail.com on 6 Jan 2011 at 9:14

GoogleCodeExporter commented 8 years ago
Okay, I think that is fine. I think that if they cannot load the file (or if 
they receive an error while loading), it is unlikely they will save over it. 
Thanks!

Original comment by faithful...@gmail.com on 6 Jan 2011 at 9:53