Hi,
If I understand correctly this issue is only applicable when two authentication types are used with one authentication provider? This results in one URL (host header) to authenticate with and you can't choose your authentication mechanism by using a different URL (like with zones).
The only way is changing the URL can be done by either https://[site]/_windows/default.aspx?ReturnUrl= or https://[site]/_trust/default.aspx?trust=.
Building the ClientContext is bases on a URL (see SiteAuth.cs). When using your method specified you determine the authentication mechanism. It seems you get an exception (you can check the logs by setting logging level to Verbose). Although this exception is raised the ClientContext is not cleared. I did not incorporate this in code.
This results in a ClientContext which is authenticated based on the URL and thus authentication type (AD or Claims). Afterwards you can connect your site, because the ClientContext is already loaded.
I guess this is what happens.
If I understand correctly this issue is only applicable when two authentication types are used with one authentication provider? This results in one URL (host header) to authenticate with and you can't choose your authentication mechanism by using a different URL (like with zones).
The only way is changing the URL can be done by either https://[site]/_windows/default.aspx?ReturnUrl= or https://[site]/_trust/default.aspx?trust=.
Building the ClientContext is bases on a URL (see SiteAuth.cs). When using your method specified you determine the authentication mechanism. It seems you get an exception (you can check the logs by setting logging level to Verbose). Although this exception is raised the ClientContext is not cleared. I did not incorporate this in code.
This results in a ClientContext which is authenticated based on the URL and thus authentication type (AD or Claims). Afterwards you can connect your site, because the ClientContext is already loaded.
I guess this is what happens.