encoding problem snapin import

[esex]

hey,
I use a snapin to install deb packages. But if I try to export and import the snapin i get problems with the encoding.

Snapin preferences befor export:

Snapin preferences after inport:

I have the same problem if i try to create a snapin with selenium and python.
Is there any way to masked the specialsigns?

[george1421]

While I can’t fix it, I understand what is happening. There needs to be a uudecode to remove the encoding of the file. The question is, is the problem coming from the import or export. When you look at the exported file do you see the encoding there or is it normal?

[esex]

The exported file shows the encoded text. If I edit the file by hand and import the the file after that, everithing is fine.

[george1421]

@esex I’m not near a fog console at the moment, but if you export the image definitions is the encoding there too (assuming you have special characters in your image names)?

Also I should have asked already, what version of FOG are you running?

[esex]

FOG version 1.5.7

Yes, it is the same for images.

[esex]

The encoding changes also if I add a member to the snapin.

[Sebastian Roth]

@esex I will try to look into this but it won’t be soon. Feel free to ping me here if you don’t hear back within the next two weeks.

[Sebastian Roth]

@esex Sorry still have not found the time to fix this…

[Sebastian Roth]

@esex I knew this is gonna be a big one. Probably why I kept on putting it off.

@Tom-Elliott did a great work generalizing most of the code like loading and saving information from/to the database. I just dug through a lot of code to try and figure out a nice way to prevent from the issue @esex described but I fear this would question most of the generalized sanitation code.

As we see this also happens if you have HTML special characters in your image names (and probably many other fields). It does not happen when you enter a name in the field an click the save button because this will directly store the input to the database. But when you do things like manipulating object associations (e.g. add member to snapin or image or group) that object is loaded and saved in the background as well. Now what happens is that the object is loaded, sanitized and saved back.

Now that I look at it I’d say that sanitation should only happen when information is being displayed in the web UI really. But I know it’s very hard to get this perfectly right in all places.

To make a long story short: I kind of know what we are looking at here but I am not sure if I’ll find the time to change and test all the sanitation magic at the very basis of the FOG web UI framework. Surely I can implement a fix that would make the problem as described here go away but it would cost us a hell of a lot of work to make sure this doesn’t cause other sanitation problems anywhere else in the web UI.

[Sebastian Roth]

@Tom-Elliott What do you think about this? Do you remember the reason for encoding HTML chars not just for displaying them on the web UI but when saved in internal variables that end up in the DB?

[Tom Elliott]

@Sebastian-Roth If my memory serves me correctly we did encode all of this for a little while, but too my knowledge we’ve moved away from encoding special characters in preference of using proper sanitization of inputs into the database. That’s not to say everything was fixed, but I’m pretty sure we moved away from this particularly because the & would get encoded as &amp, then the & in the &amp would get encoded, and so on and so forth.