Hi Folks, Thanks for your continued interest in this thread.
I did check the SQL logs to see what happens when I update the User form Password field (FID 102) using the join form with the corresponding field renumbered to something other than FID 102... it does not encrypt the contents, neither in the SQL UPDATE nor in the database table. The password is sent in clear text. When the password field in the join retains it's FID=102, everything works correctly and the result is encrypted all the way to the database table. As an interesting aside, the user_cache entry is encrypted in both cases described above. So in my case, renumbering the Password field on the join form turned out to be a poor choice. That really only left me one field that I could renumber to avoid the 9070 error... "Login Name" (FID 101). I have renumbered "Login Name" on my join and everything seems to be working as expected. Hope this is helpful. Larry On Jan 18, 2011, at 10:25 AM, Misi Mladoniczky wrote: > Hi, > > I suspect that if the field id is not 102, it will not encrypt the content > before it is sent over the network. The SQL log will still show it > encrypted though, as it is encrypted by the server before it is stored. > > It would be complicated to track the 102 to the actual regular form, as a > join may be implemented in multiple tiers. > > Best Regards - Misi, RRR AB, http://www.rrr.se > > Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10): > * RRR|License - Not enough Remedy licenses? Save money by optimizing. > * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. > Find these products, and many free tools and utilities, at http://rrr.se. > >> Hi Misi, >> >> I have not checked the SQL logs but I was assuming (hoping) that since the >> renumbered password field (on the join form) still maps to the real >> password field in the real User form (with it's original FID), then it >> would still be treated as such and encrypted as appropriate. I did in fact >> set the Display-Type to "Edit Masked" as you suggest and that part works >> just fine. If I get a few minutes today, I'll check the SQL logs to see >> what is getting sent. >> >> Thanks. >> Larry >> >> On Jan 18, 2011, at 3:54 AM, Misi Mladoniczky wrote: >> >>> Hi, >>> >>> All else to the side, in this case, couldn't you just set the >>> Display-Type >>> to "Edit Masked"? >>> >>> I an guessing that it changes the way modified data is sent to the >>> server, >>> as the password field is normally sent encrypted. >>> >>> In the old days, I sometimes renamed the User-form to a Swedish >>> equivalent, which worked just fine, and it probably still does. >>> >>> If you had multiple User-forms the system could suddenly switch forms, >>> for >>> example when you imported a record into UserCopy, the user cache could >>> get >>> reset with only the newly imported user in it... I am sure it worked >>> like >>> this in version 2.0 and 2.1, and possibly a bit after that as well ;-) >>> >>> Why is the 9070 message missing from the Error Message Guide? >>> >>> Best Regards - Misi, RRR AB, http://www.rrr.se >>> >>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10): >>> * RRR|License - Not enough Remedy licenses? Save money by optimizing. >>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy >>> logs. >>> Find these products, and many free tools and utilities, at >>> http://rrr.se. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
