tag:blogger.com,1999:blog-2780703305680355567.post2994686913928444559..comments2023-10-03T17:36:50.117+01:00Comments on Indistinguishable from magic: Doing RSS right (3) - character encodingjw35http://www.blogger.com/profile/01606359745703313801noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-2780703305680355567.post-53443534640889985662013-01-14T12:37:26.780+00:002013-01-14T12:37:26.780+00:00This comment has been removed by a blog administrator.StardustShining Bloghttp://stardustshining.wordpress.com/noreply@blogger.comtag:blogger.com,1999:blog-2780703305680355567.post-17503899180432398872012-11-05T17:10:03.593+00:002012-11-05T17:10:03.593+00:00Yup that's a further example of much the same ...Yup that's a further example of much the same problem. Actually it's also an example of one of the 'other problems' that I mentioned near the end - in this case 'what encoding is used for data from forms?'. When I last looked (quite a while ago) this was a mess, but a likely outcome will be that form data will uploaded in the same encoding as used by the page. Hence why changing the encoding of the page helped. <br /><br />In your password case, what's happening is that the user is entering the _characters_ of his password and these are being encoded into numbers for transmission to your web server. Then, by the sound of it you are passing those numbers into a password verification function which is making assumptions about the underlying character encoding. Providing they match, it works. If they don't match then it works much of the time but fails when presented with a less-than-common character like £. Sound familiar?jw35https://www.blogger.com/profile/01606359745703313801noreply@blogger.comtag:blogger.com,1999:blog-2780703305680355567.post-18452546758984580492012-11-05T08:42:05.565+00:002012-11-05T08:42:05.565+00:00Unfortunately this lovely world of character encod...Unfortunately this lovely world of character encoding also bleeds into identity management. We just encountered a problem when users used 8 bit Asci characters (e.g. £) in their passwords with our login gateways. Turns out if the login page is utf-8 it doesn't work, setting it to charset=iso-8859-1 worked as this is the closest approximation of the windows active directory charset we have (I believe the euro symbol will now fail in passwords....but since it isn't on our keyboards it's a better option). When you combine this with the impact of kerberos enctypes and character sets you enter a lovely world where the client settings, webserver, html, tomcat, kerberos enctypes and password store can all fight about character sets. calhttps://www.blogger.com/profile/16678073702152443219noreply@blogger.com