New ApiKeys with named connection

ServiceStack Authentication
1

Hi, we’re using a separate database for the auth tables and for the data. So we register an extra named connection for the “authdb” and we do

                services.AddSingleton<IAuthRepository>(c =>
                    new OrmLiteAuthRepository<UserAuth, UserAuthDetails>(c.GetRequiredService<IDbConnectionFactory>(), "authdb")
                    {
                        UseDistinctRoleTables = true
                    });

But for the new style API keys, it seems it is not using the AuthRepo at all? We’re getting Invalid object name 'ApiKey'. from the admin-ui when creating a key.

We have done this to Init the tables:

               // Add ApiKeys schema to DB
                using var db = appHost.Resolve<IDbConnectionFactory>().Open("authdb");
                var feature = appHost.GetPlugin<ApiKeysFeature>( );
                feature.InitSchema(db);

When we init the tables w/o the named connection, it works fine. We’ve looked at the implementation of the new ApiKeys, and it seems there’s no support for named connection? Or why doesn’t it use the Auth Repo?

2

The ApiKeysFeature is for ASP .NET Core Identity Auth projects that by design works very different to the previous ServiceStack Auth API Key Auth Provider.

I’ve just added support for using a custom db connection in this commit where you’d be able to use a custom named connection with:

services.AddPlugin(new ApiKeysFeature {
    UseDb = () => HostContext.AppHost.GetDbConnection(namedConnection),
    //...
});

This change is available from v8.8.1+ that’s now available in the pre-release packages.

3

Thanks, we’ll try this right away. So I guess works very different is why AuthRepo is not used?

And for anyone else seeing this: I sent this request on Friday last thing, got the answer before Monday morning. Not just a “this doesn’t work”, but even a fix!

4

The works very different docs I linked to explains why.

5

I understand the reasons why ApiKey provider was rewritten, as the old one was very inconvenient to use, and the new one looks very promising, which is why we’re using it.

As to why AuthRepo was not used as storage backend, I could not find that anywhere (search for repo/storage/persist did not give any results), so I guess I just had to deduce this because the new ApiKeyProvider is not part of the ServiceStack Auth (where Auth Repository belongs) but rather the ASP.NET Core Identity Auth.

6

It couldn’t be reused simply because the Data Models are incompatible, have different schemas and Primary Keys.

7

Hi again, we have tested now.

Following the instructions, we got the new Nuget prerelease package, and the UseDb statement is there.

But the star of the show, the Admin-UI is still looking at the default connection.

Could this be it here?

public class AdminApiKeysService ....

    public async Task<object> Get(AdminQueryApiKeys request)
    {
        var feature = await AssertRequiredRole().ConfigAwait();

        using var db = Db;
8

Yeah the Admin UI APIs need to use the configured DB as well which is done in this commit.

This change is available in the latest v8.8.1+ which is now available in the latest pre-release packages. Since you’ve already installed v8.8.1 you’ll need to clear your NuGet packages cache to download the latest v8.8.1 packages.

dotnet nuget locals all --clear
1 Like
9

Works fine now!

Thanks for being flexible and fast, so we could use the new and cool ApiKeys without totally switching to Core Identity, which seems like more work (we have our own override of CredentialsAuthProvider, so that might not work the same w. Core Identity I guess).

1 Like