Squidguard configuration gui fails when error message is no ascii
-
Hello.
After some testing I have determined that, when in SquidGuard -> Common ACL –> proxy denied error you write Spainsh Characters (perhaps no ASCII) , the GUI gives an error and receive notice (yellow blinking in top/right "pfsense is restoring the configuration /cf/conf/backup......)
Test characters i.e configuración note character ó
España character ñVersion 2.2.5-RELEASE (amd64)
built on Wed Nov 04 15:49:37 CST 2015
FreeBSD 10.1-RELEASE-p24 -
Yeah, don't do ridiculous things.
-
Yeah, don't do ridiculous things.
And by "ridiculous things", you mean things like assuming the user speaks English, and not handling int'l characters properly like it was the 1980's all over again? I can understand it barfing on funny chars in a config file, but a text string???
-
@KOM:
Yeah, don't do ridiculous things.
I can understand it barfing on funny chars in a config file, but a text string???
And guess where it gets stored. Yeah, right - all of this goes to config.xml.
Fixing thing like this requires changing the textarea fields to get base64-encoded. Then, it will require config upgrade code (LOTS of through the package, since there're tons of textarea fields, doesn't make sense to fix just one). Then, the config upgrade will not work anyway because the install phase is cached. Then, zillion other people will complain here that upgrade broke their perfectly working setups that had never had such issue and that they have tons of unreadable base64-encoded garbage instead of their previously working setup. Frankly, this thing ain't reliably doable without renaming all affected fields. Renaming those fields requires changing them all across the messy PHP code in this package. (Read it, the gazillion of useless horribly named defines() there will give you headache in minutes.)
So, yeah, sorry but the best advise here is: Stop putting "ridiculous" characters there. Yeah, stick to ASCII. It's not like having the funky chars in the damned error message would be exactly critical.
-
And guess where it gets stored. Yeah, right - all of this goes to config.xml.
You know what I meant, like a key-value pair or reserved keyword.
OK then, fair enough. The work sounds like a LOT for what it delivers. Too bad it wasn't done properly from the start. Perhaps a way to respond without unnecessarily antagonizing people would be something like "It doesn't support int'l characters at this time."
It's not like having the funky chars in the damned error message would be exactly critical.
Certainly not critical, no. But I know I would be irritated if I were in his position… "Nevermind your native language, you need to code your error text in L33t-5p34K because that's all we considered when we wrote the thing..."
-
Yeah, when things are screwed in the start, it becomes a giant PITA to fix later. I never got to doing anything but random bugfixes with this package. The code gives me headaches realiably, cannot make myself finish anything there. Getting lost over and over again.
P.S. We have tons of "ridiculous" characters in my language as well (ěščřžýáíéďťňúůó). You just get used to avoid them in places where it might cause trouble. This stuff just causes headaches and lots of additional work with computers. There still are much worse languages though even in Europe, e.g. setting your locale to things like et-EE is a great way to cause tons of unexpected compile issues and cryptic bugs – such as totally unexpected values because of failed regexp matching.
