Invision Community 4: SEO, prepare for v5 and dormant account notifications By Matt November 11, 2024
GreenSock Posted November 23, 2012 Posted November 23, 2012 I recently noticed that in 3.3.4 anytime the word "onStart" is used in a post, it forces the "S" to be lowercase even though I type it uppercase! Not only is this SUPER annoying, it actually causes massive problems for us because our forums are for supporting our software which has an "onStart" feature in the API, so anytime we provide sample code to users that has an onStart, it displays incorrectly to them! So if they copy/paste what we tell them in the forums into their app, it won't work because the capital "S" was changed to a lowercase "s"! Please....PLEASE correct this. If anyone knows how to fix this in 3.3.4, I'd really love to know.
Marcher Technologies Posted November 23, 2012 Posted November 23, 2012 Good luck with this lol. It is like onClick (it will lower this), or any javascript attribute, not allowed for security reasons. Edit: 0.o..... it appears Matt changed this on 3.4.... wait a bit and upgrade?
TSP Posted November 23, 2012 Posted November 23, 2012 ...onClick (it will lower this) ...Sentence does not compute.
Marcher Technologies Posted November 23, 2012 Posted November 23, 2012 Sentence does not compute. Yeah, it does not q.q. This forced lowering has been in effect for so long I wholeheartedly expected it to lower it. Matt took me by surprise on this one. :P
TSP Posted November 23, 2012 Posted November 23, 2012 Yeah, it does not q.q. This forced lowering has been in effect for so long I wholeheartedly expected it to lower it.Matt took me by surprise on this one. :tongue:Don't celebrate just yet, it could be a bug he haven't discovered :tongue:
Marcher Technologies Posted November 23, 2012 Posted November 23, 2012 Don't celebrate just yet, it could be a bug he haven't discovered :tongue: I doubt it...... the thing is that the lowering itself was not a protection in any manner, as certain browsers accept and parse the lowered variant anyway(onClick is a good example of this). Considering the 'real' prevention in IPB is swapping a character or 2 for the html entity of it, I have a feeling this was purposely fixed, and was likely a case of it not recognizing case when making the swap.
TSP Posted November 23, 2012 Posted November 23, 2012 Yes, I believe you are right Marcher. It was just a joke. ;) Sometimes things I expect to work a certain way but doesn't anymore (when it did so in earlier versions) is marked as Working As Intended. So I'm just having fun sometimes thinking that unexpected fixedor changed things (for the better and that I would view as WAI/Fixed) are the opposite.I guess we can conclude that this have been fixed by IPS in 3.4. An official temporary fix will not be given from IPS staff so I guess you'll have to rely on someone from the community suggesting a fix for you if you wish this to be sorted in 3.3.4.
Martin A. Posted November 23, 2012 Posted November 23, 2012 From the looks of it, in 3.4.0 the checkXss() method is only used on BBcode options, not the whole post. In 3.3 there was a call to it at the end of the parseBbcode() method, but that is not the case in the new text parser. It's still in the old Bbcode parser, but that's not in use any more. Not sure if that is intentional or not, an IPS dev will have to answer that. (For others who want to dig in code. IPSText::xssMakeJavascriptSafe() is the method that does the sanitisation of JS events)
Marcher Technologies Posted November 23, 2012 Posted November 23, 2012 >_< Here's for my wishful thought xssMakeJavascriptSafe was fixed for case sensitivity..... no, is just not used there -.-
Recommended Posts
Archived
This topic is now archived and is closed to further replies.