Problem saving/loading characters
There is a problem in the Safe class that raises errors when loading a world with characters, prevempting the client to be started.
I found that the problem initially is with the passphrase file, but when I solved this I found some problems regarding encrypting and decrypting with unexpected results.
Currently I am investigating the pyaes library to solve this myself.
Anyway, can you give me directions on this?
#2 Updated by Vincent Le Goff 9 months ago
It's strange, I don't have this issue and I have several characters that are already created. Does it happen when new characters are added though?
Safe class is meant to be a simple wrapper around something rather complex: encryption. We used other libraries before, but some of these libraries haven't updated to Python 3 yet, so I decided to find something else.
pyaes is the new find. As far as I can tell, it works perfectly well with characters created before this version: I can open a word, select this character, and the username, password and other commands are read from the encrypted file with no problem. It's unfortunately possible I didn't test creating new characters with encryption, though I believe I did.
Likely culprits in this case: the str/unicode issue is one we have most problems with in this version, handling Python 2 to Python 3 support. So I would first check for the proper str types to be used: in Python 3, the rule is pretty straightforward: everything should be a str, except if it's in early input or late output (as it is, when writing to a file). The
Safe class can manage raw bytes, it writes into files after all.
Another option is the fact that old characters work fine, but perhaps new ones don't: perhaps this issue regards a particular method which is called only for new characters?
BTW, a unittest on the
Safeclass is a very good idea. We don't have enough unittests as is and we could use many, many more, even if testing the UI itself is a bit difficult.
#3 Updated by Francisco Del Roio 9 months ago
I've found that the problem is on retrieve function when checking if the decrypted value is an str, and that condition never occurs because all strings returned at this moment are always bytes arrays or anithing other.
The way around I've tested is to save a tuple with a "str" value as the first item and the value as the second ones and it worked well.
#5 Updated by Vincent Le Goff 9 months ago
I will test it in a few minutes. The tricky part, of course, is that it has to keep on working with older versions, so that information of characters created before the change aren't lost. But I have a few to test, we'll see how it works. Thanks for debugging and for the PR!
#6 Updated by Vincent Le Goff 9 months ago
- Sprint/Milestone set to 16
I brought a fix in commit 58dd663a6c5a289acda6b3431bca82527ffd74b9. Storing as a tuple was a valid idea, unfortunately it broke compatibility with older versions. The old str/unicode code was obviously not working in Python 3, so I had to adjust a little the `Safe.retriev` and `Safe.store` methods. I will let you close this after testing with your characters: note, however, that the characters you have created with your fix will not work, you will have to create new ones. It seems to work just fine with old and new characters.
I also placed this issue in the sprint 16 (which is the version for CocoMUD 49). This should be released around Christmas I believe, so that most issues we close now end up in it, to keep track of what was done during this version.
Please register to edit this issue