Why doesn't InfoPath tell us who is the current user? Turns out there is a good reason...

This is a question I have often asked, and been asked by virtually every customer I have worked with:

Infopath's User object includes the following two methods:
   IsCurrentUser(domain\username) returns True if the current(ly logged in) user matches the specified user name
   IsUserMemberOf(domain\groupname) returns True if the current(ly logged in) user is a member of the specified group

So why oh why doesn't InfoPath take the next logical step and actually let us know who the user is?  This is always a hassle to anyone working with users, roles or application-level permissions in Infopath.

Well the answer - straight from the InfoPath team - is:

InfoPath (as a fully trusted executable running with permissions on your system) does "know" who the logged in user is. Any such fully trusted executable can. InfoPath provides these "test" [addys: IsCurrentUser, IsUserMemberOf] functions for use by untrusted code since that doesn’t reveal (much) personal information.

Consider this: some random web site puts up an XML file. You click on it, expecting perhaps to navigate to another page. InfoPath pulls down the XML and XSN and executes the code – which is not trusted. If InfoPath revealed your username to this untrusted code, the code could post back to the server (which is in the same domain) and thus you would have unknowingly provided your email address to a web site.

Thus, the bar is that code needs to be trusted to be given your login information. And trusted code already has permission to call system APIs which determine this, so you don’t need InfoPath APIs to provide this information.

This was a very careful decision made on the basis of the Trustworthy Computing pillars, not an oversight on the part of the InfoPath team.