Fixes for #114.

[kentcb]

Where relevant, tokens are obtained in a loop with an increasing buffer size as long as SEC_E_BUFFER_TOO_SMALL or SEC_E_INSUFFICIENT_MEMORY is returned.

As discussed in the forum, there is still a case that is not dealt with here. Namely, if the buffer size is too small then TestNegotiate() will fail with:

System.ComponentModel.Win32Exception : Not enough memory is available to complete this request
        WindowsSecurityContext.cs(143,0): at Waffle.Windows.AuthProvider.WindowsSecurityContext..ctor(String username, WindowsCredentialsHandle credentials, String securityPackage, Int32 fContextReq, Int32 targetDataRep)

It only fails on the second call to InitializeSecurityContext().

[dblock]

These two branches are identical minus a single parameter. Condition with a 1-liner in it: continueSecHandle == Secur32SecHandle.Zero ? IntPtr.Zero : ref continueSecHandle.

[kentcb]

2 problems: 1. I was trying not to change existing code - just do the minimal to fix the issue. 2. That won't compile, which I suspect is why it was written that way in the first place.

[dblock]

:)

[dblock]

The tests succeed for me no-matter what value I use for the initial tokenSize. Do you have a consistent repro by setting a low initial size?

Please update CHANGELOG (via --amend), too.

[dblock]

Have you ever gotten a SEC_E_BUFFER_TOO_SMALL here? It's not a return value from this function. MSDN says that you can only get SEC_E_INSUFFICIENT_MEMORY and the Java Code doesn't check for it.

[kentcb]

I can get either error in the second ctor, but I can't remember whether I saw it in the first (probably not, but I'll check again tomorrow).

[kentcb]

Yes I can get a consistent error with a small buffer size (eg. 1000). I am using Kerberos though - are you perhaps using NTLM? And if you debug through, is your token too large to fit in the initial buffer?

[dblock]

Perfect, merged via 6a8bd45.