That's great!
I'm glad to hear it.
Thank you very much for providing patches for this issue.
--
Sent from my Android phone
Francisco Figueiredo Jr.
Npgsql lead developer
fxjr.blogspot.com
twitter.com/franciscojunior
Em 10/03/2011 09:01, "Ahmed Shinwari" <ahmed.shinwari@xxxxxxxxx> escreveu:
> Hi Fransisco,
>
> I tested the latest Npgsql driver (2.0.12.0), the issue has been fixed. I
> was able to connect Npgsql test application from my Windows XP client
> machine with the PostgreSQL server running on Windows 2003 Server.
>
> Thank you for applying the patch.
>
>
> On Thu, Feb 24, 2011 at 3:37 PM, Ahmed Shinwari <ahmed.shinwari@xxxxxxxxx>wrote:
>
>>
>>
>> On Sat, Feb 19, 2011 at 11:31 PM, Brar Piening <brar@xxxxxx> wrote:
>>
>>> On Thu, 17 Feb 2011 07:58:46 -0800 (PST), Ahmed <ahmed.shinwari@xxxxxxxxx>
>>> wrote:
>>>
>>>> I tried changing that one line to use UTF-8 encoder, but the password
>>>> packet
>>>> didn't get fixed. It works smoothly if kept in byte array instead of
>>>> string.
>>>>
>>> Yes, as SSPI uses binary bytes we have to avoid to convert them to
>>> characters and back to bytes during message generation.
>>>
>>> While "char *buffer" in C can serve as both a string and a buffer of
>>> binary bytes, we have "byte[]" as binary buffer and "string" as string in
>>> c#.
>>> This is the reason why we need to use byte[] in all places where libpq
>>> uses char* without really caring whether there is a string inside or some
>>> opaque bytes.
>>>
>>>
>>> I think changing the AuthenticationSSPI case to use context.Host may
>>>> break
>>>> the cases Brar's mentioned.
>>>>
>>> If this isn't necessary to fix the problem we should probably get some
>>> more instight to what really happens here before fixing one end and breaking
>>> the other.
>>>
>> I agree.
>>
>>
>> For now, Francisco may check in that part which fixes the bug due to
>> encoding. And, address the later issue after further investigation.
>>
>>
>>
>>>
>>> Regards,
>>>
>>> Brar
>>>
>>
>>
> Hi Fransisco,
>
> I tested the latest Npgsql driver (2.0.12.0), the issue has been fixed. I
> was able to connect Npgsql test application from my Windows XP client
> machine with the PostgreSQL server running on Windows 2003 Server.
>
> Thank you for applying the patch.
>
>
> On Thu, Feb 24, 2011 at 3:37 PM, Ahmed Shinwari <ahmed.shinwari@xxxxxxxxx>wrote:
>
>>
>>
>> On Sat, Feb 19, 2011 at 11:31 PM, Brar Piening <brar@xxxxxx> wrote:
>>
>>> On Thu, 17 Feb 2011 07:58:46 -0800 (PST), Ahmed <ahmed.shinwari@xxxxxxxxx>
>>> wrote:
>>>
>>>> I tried changing that one line to use UTF-8 encoder, but the password
>>>> packet
>>>> didn't get fixed. It works smoothly if kept in byte array instead of
>>>> string.
>>>>
>>> Yes, as SSPI uses binary bytes we have to avoid to convert them to
>>> characters and back to bytes during message generation.
>>>
>>> While "char *buffer" in C can serve as both a string and a buffer of
>>> binary bytes, we have "byte[]" as binary buffer and "string" as string in
>>> c#.
>>> This is the reason why we need to use byte[] in all places where libpq
>>> uses char* without really caring whether there is a string inside or some
>>> opaque bytes.
>>>
>>>
>>> I think changing the AuthenticationSSPI case to use context.Host may
>>>> break
>>>> the cases Brar's mentioned.
>>>>
>>> If this isn't necessary to fix the problem we should probably get some
>>> more instight to what really happens here before fixing one end and breaking
>>> the other.
>>>
>> I agree.
>>
>>
>> For now, Francisco may check in that part which fixes the bug due to
>> encoding. And, address the later issue after further investigation.
>>
>>
>>
>>>
>>> Regards,
>>>
>>> Brar
>>>
>>
>>
