Forums

Hi all,

We are having a frustrating problem with the logon page of our web app. Basically, one of our customers has requested that the password should be forced to include a symbol as well as usual alphanumeric characters, so, we decided upon 8 that should be valid to use. One of these was the '£' symbol but it appears to cause the system to crash and is never accepted. Entering it into other areas of the system causes it to encode in the following way: '£' so i'm assuming it's something related to the ASCII encoding of the character. There is no cn_dump created when this occurs so it's difficult to pin down the exact error. The text box in question is a password field.

I just thought i'd check to see if anybody has ever seen this before? If there's a way of changing the way the character is handled so that we can use it then that'd be great, otherwise we'll have to get back to the customer and swap it for another useable character - but this isn't ideal in the circumstances.

As ever, any help will be appreciated

Rich

Is your JADE database ANSI or unicode?

There are caveats to using an ANSI database to be at the backend of a web browser, which is naturally unicode. What happens when unicode character comes in to the back end? How do you store or process this in Jade? Depending on the encoding type it will come across as multiple characters as you have noticed. There are quite a few unicode characters that can make their way into a web browser form even on English language workstations - characters like em (U+2012) and en (U+2013) dashes. Characters pasted from common word processing apps can include peculiar apostrophes (U+2018, U+2019). The pound symbol is U+00A3, otherwise £ or £ in HTML.

If you are not using a unicode database at the back end and you want to store them in the database, then you should consider using StringUtf8 instead of String. Other mechanisms include sanitising the input either in the Jade side or in the browser (in Javascript). This could include replacing characters e.g. replacing an em dash with a normal "-". Pound is often replaced with "#". I would be wary of doing this as there is no easy way to convert it back and show the user what they actually entered.

Hi allistar,

Thanks for your reply!

That makes total sense. Our databases are ANSI so the problem being caused by Unicode characters makes the problem much clearer. I had been advised it might be related to the locale of the IIS Server but your suggestion sounds more likely.

I have taken your advice on the sanitising option (Just using Jade string manipulation) and managed to get it working. The field is a password field and we don't extract it or give it back to the employee so it's simple to do that. If it was a username field or anything then it might have been more messy.

Thanks for your help!

Rich

I have an update for this as we've made steps in solving the problem, i thought i'd share them!

It turns out the crashing was actually being caused by the fact that the textbox had a maxLength of 10 and when entering £ as one of the characters it was creating an 11th character (Â) which caused the textbox to be "overfull". I extended that and then used simple string manipulation to make the system work and we can now use the character like any other. In the process i've been speaking with our Network Support team and they said they've seen it before and it's regarding the encoding on the web page. If you go to "Tools" then "Encoding" on IE, and change the encoding from "Unicode(UTF8)" to any of the ANSI ones (Such as Western European) then the spurious  character does not appear. The Meta Tags in the HTML header force the encoding back to Unicode(UTF8) but they said if i can get the Jade Web App methods (The reply method, perhaps) to force it to an ANSI one then that should stop it happening.

Thanks for all your help!

Rich