Commented by: @AlexPeshkoff

It's big surprise that WTA works at all with russian user names - according to standard CURRENT_USER must be ASCII. I have no quick idea what can be done here before 3.0, where we will be able to map OS users to database users.

But may be the problem is not SO awful? Please, check - does it work correctly with UTF16 charset?

Commented by: GR (gr)

Hi, Alex.

> according to standard CURRENT_USER must be ASCII.

Really ? IIRC, it is implementation defined.
Nevertheless, mon$user is UNICODE_FSS.

> I have no quick idea what can be done here before 3.0,
> where we will be able to map OS users to database users.

There is no way to transliterate string to connection
charset correctly ? With charset NONE it works fine.

> Please, check - does it work correctly with UTF16 charset?

How to check it ? ISQL throws exceptions
"charset UTF16/UTF-16 not defined".

Commented by: @dyemanov

From the SQL specification:

"The declared type of CURRENT_USER, CURRENT_ROLE, SESSION_USER, SYSTEM_USER, CURRENT_
CATALOG, CURRENT_SCHEMA, and CURRENT_PATH is character string. Whether the
character string is fixed length or variable length, and its length if it is fixed length or maximum length if
it is variable length, are implementation-defined. The character set of the character string is SQL_IDENTIFIER."

and

"SQL_IDENTIFIER is an implementation-defined character repertoire consisting of the <SQL language
character>s and all other characters that the SQL-implementation supports for use in <regular identifier>s."

So, in our case, it corresponds to UNICODE_FSS. And we do conform, as CURRENT_USER is described as ttype_metadata, which is UNICODE_FSS.

I suppose the issue is caused by the fact that AuthSspi returns the user name in the ANSI encoding (CP1251 for Russia) and it's not transliterated into UTF-8 when passed via DPB (or later, when written into usr_user_name, I'm not sure which one is correct).

Commented by: @asfernandes

There is very related ticket CORE1604. At the time, AFAIR the problem was we didn't treat user names as unicode strings at all.

Some changes were introduced more recently related to DPB items conversions, so maybe now it's possible to fix this.

Commented by: @AlexPeshkoff

The main problem is how does windows context authentication API return non-ascii user name. When user name contains ascii only characters this is definitely ascii. Taking into an account that we use QueryContextAttributesA to query user name, I hardly imagine how can it be UNICODE. Converting from national character sets like win1251 requires knowledge what character set is used for this particular windows version.

May be the best way is to use QueryContextAttributesU instead and always convert resulting string to UNICODE_FSS?

Commented by: @asfernandes

Both approaches seems possible as we have functions to convert from system code page.

Usage of QueryContextAttributesU seems better because it won't throw an error if a valid name in the client is not representable in the server code page.

Commented by: GR (gr)

> May be the best way is to use QueryContextAttributesU instead and always convert resulting string to UNICODE_FSS?

Exactly.