> On Oct 10, 2016, at 10:09 AM, Patrick Brunmayr <p.brunm...@linzag.at> wrote: > > Tried this > > <FortRequest> > <contextId>HOME</contextId> > <entity xsi:type="user" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > <userId>test</userId> > <password>112</password> > <password>97</password> > <password>115</password> > <password>115</password> > <password>119</password> > <password>111</password> > <password>114</password> > <password>100</password> > </entity> > </FortRequest> > > Session is created successfully. Why ? None of these passwords do match > or are valid ? What am i missing ?
short answer is this is an array of char’s decimal values: <password>112</password><password>97</password><password>115</password><password>115</password><password>119</password><password>111</password><password>114</password><password>100</password> <password>112</password> = ‘p’ <password>97</password> = ‘a’ <password>115</password> = ’s’ <password>115</password> = ’s’ <password>119</password> = ‘w’ <password>111</password> = ‘o’ <password>114</password> = ‘r’ <password>100</password> = ‘d’ longer answer is this kind of sucks for clients. I could talk about the ‘why’ (related to a perceived security risk for Strings) but it’s not really a good use of our time here & now. I am about 95% convinced the user entity password data type needs to revert back to using a String instead of char[]. That would certainly make services like this more palatable. I would like to hear input from others on this topic. Shawn
