ServiceStack Auth and Xamarin

#1

Hi,
On a customer project we have upgraded one project to use blazor server, so to make it work with authentication i have removed UseTokenCookie = false, i had this on the previous version to get the bearer token.

Currently my Xamarin Forms worked with Bearer and Refresh Token, now the Services does not return tokens anymore, i guess it is expected to work with cookies now? there is a way to still get the bearer and refresh token?

Is the ServiceStack client going to store cookies client side for me?
I have tried to get the token with client.GetTokenCookie() but after a successful authentication return null

Thanks

#2

Yes, UseTokenCookie=true is the default since v6 which only sends the JWT Tokens over Secure HttpOnly Cookies.

The GetTokenCookie() and GetRefreshTokenCookie() is what you should be able to get the ss-tok and ss-reftok cookies respectively. What ServiceClient are you using? I’d recommend using the same JsonApiClient as your Blazor project.

The clients doesn’t have any special behavior for Xamarin, it all behaves the same way where during usage the cookies are maintained in client.CookieContainer which is where the ss-tok and ss-reftok cookies should be stored after Authentication.

#3

Currently i have this on my Xamarin project

<PackageReference Include="ServiceStack.HttpClient" Version="6.*" />

i’m using JsonHttpClient

On the Android side i have also added this

  
            JsonHttpClient.GlobalHttpMessageHandlerFactory = new Func<System.Net.Http.HttpMessageHandler>(() => new AndroidMessageHandler()
            {
                ServerCertificateCustomValidationCallback = (message, certificate2, arg3, arg4) => true
            });
#4

The JsonApiClient doesn’t require an additional dependency as it’s included in ServiceStack.Client net6.0 builds and also includes:

JsonApiClient.GlobalHttpMessageHandlerFactory
#5

I don’t think i can use that, the project is netstandard2.0 and the android project is old style as i don’t use maui

#6

Ok then JsonHttpClient should still work, are you able to call a secure API after authenticating with the same client instance?

#7

Yes on the same instance i call protected services, but GetTokenCookie return null, and the cookie container is empty

#8

Ok, looks like the GlobalHttpMessageHandlerFactory takes over the HttpClientHandler construction, try configuring it to use the same CookieContainer, something like:

var cookieContainer = new CookieContainer();
var client = new JsonHttpClient(baseUrl) {
    CookieContainer = cookieContainer
};
JsonHttpClient.GlobalHttpMessageHandlerFactory= new Func<HttpMessageHandler>(()=>
    new AndroidMessageHandler() {
        ServerCertificateCustomValidationCallback = (msg,cert,arg3,arg4) => true,
        CookieContainer = cookieContainer
    });
#9

Tried but still dosen’t work, i will try to use ApiKeys for now

#10

Ok i got it working, i had to change these in the apphost, maybe is something strange on the server that was causing some issues, i have a cloudflare dns in front.

   UseHttpOnlyCookies = false,
   UseSecureCookies = false,

Still the snippet you provide above was need, if i remove would not work again

now GetTokenCookie works

But when i check if is authenticated now i get this error.

Could not retrieve new AccessToken from: 500

to check if is authenticated i use this

client.PostAsync(new Authenticate());

#11

Not seeing how this would help in a C# App as HTTP Only cookies should only prevent JavaScript in a webpage to access the cookies, it would be an issue with Blazor WASM since all HTTP access is still going through fetch/Web sandbox, but this a native Android App that isn’t going through a Web View right?

Are you just using dns or are the calls going through a Cloudflare reverse proxy? Is it doing SSL termination?

Also weird that you’re able to Authenticate & call protected APIs but not access the cookies since you need cookies to call authenticated services.

IMO we’d need to see the HTTP Headers (with sensitive info scrubbed) to see if it provides any more insight into the behavior.

#12

Yeah, it is a very strange behaviour, i will try to send more data, now i’m a rush to fix other issues…
But yeah we are using an unusual configuration with cloudflare.
The customer has a messy setup, so we had to use proxied dns entries on cloudflare, https is handled by him and on the server we have a Origin Certificate also we are using a non default port 8443 has they have occupied on other iis sites the standard https port and we can’t touch it :sweat_smile:
If i have more time later today I will do more testing and let you know.
BTW thanks for the support

1 Like