Deferring close of encoder in XOAuth2String function truncates result

[atc0005]

@sqs

Thank you for creating this package! It was very helpful in understanding the XOAuth2 string format is handled.

While using this package, I noticed that I was getting different results from the XOAuth2String function than I did a PowerShell implementation here:

if ( $SharedMailbox ) {
    $b="user=" + $SharedMailbox + "$([char]0x01)auth=Bearer " + $accessToken + "$([char]0x01)$([char]0x01)"
    Write-Host "Accessing Sharedmailbox - $SharedMailbox - with Accesstoken of User $userName." -ForegroundColor DarkGreen
} else {
        $b="user=" + $userName + "$([char]0x01)auth=Bearer " + $accessToken + "$([char]0x01)$([char]0x01)"
        }

$Bytes = [System.Text.Encoding]::ASCII.GetBytes($b)
$POPIMAPLogin =[Convert]::ToBase64String($Bytes)

Write-Verbose "SASL XOAUTH2 login string $POPIMAPLogin"

After some trial & error, I realized that it was due to these lines:

go-xoauth2/xoauth2.go

Lines 25 to 26 in 0911dad

	defer encoder.Close()
	return buf.String()

I believe that the bug is due to the buffer being read before the encoder is closed. Per the docs:

when finished writing, the caller must Close the returned encoder to flush any partially written blocks.

If we return the buffer as a string (at function end) before the encoder is closed (via defer) we'll be returning only part of the base64 encoded string. In testing, this repeated led to AQ== being left off of the returned base64 encoded string. When I explicitly closed the encoder before returning the string the result was valid every time.

refs https://github.com/DanijelkMSFT/ThisandThat/blob/bc7649953761cd2d1b462172df7df6be9bb9eb9b/Get-IMAPAccessToken.ps1

[atc0005]

I don't recall where I found it, but this is a potential alternative to the current implementation:

func XOAuth2String(user, accessToken string) string {
	s := OAuth2String(user, accessToken)
	return base64.StdEncoding.EncodeToString([]byte(s))
}

I can't speak to the performance impact from converting the string to bytes and then back to a string again, but the implementation is simpler (fwiw).

[atc0005]

Now I'm having trouble reproducing this. Will test further and close if unable to create a reproducible test case.

[atc0005]

I can't reproduce any longer, so closing. Sorry for the noise.