Sharing DbContext for internal admin app

[sshquack]

Hey @pdevito3 I'm still learning the ropes of VSA but I couldn't find an answer in the docs. Currently when generating using Craftsman, it provides a nice bounded context that isolated the DB. This is great because it enforces cross-boundary communication using MQ / bus. Let's look at a concrete example:

CarbonKitchen (Domain)/
├─ RecipeManagement (Bounded Context)/
│  ├─ Domain/
│  │  ├─ Recipes (DBSet)
│  │  ├─ Ingredients (DBSet)
├─ ShoppingManagement (Bounded Context)/
│  ├─ Domain/
│  │  ├─ Shopping Lists (DBSet)/

In the above example, Recipes DBSet is tied to the BC. Now I want to introduce an internal only admin app (console app) that talks to the DB. The purpose of this internal app could be to for a community moderation bot (add, update or remove) spam recipes or shopping lists (pun intended). The admin app doesn't really need an API or auth. What would be the best way for the admin app to access the DBSet?

[pdevito3]

So you have your main recipe boundary that's protected with a JWT. In order to talk to it, you need to be able to present that.

There's two flows that you use to authenticate to get that token, either interactively with a code flow or in an automated way with a client credentials flow.

So in this case I'd consider the admin console app as a client consuming your api the same way a SPA or server side app would, only in this case your bot is an automated process (not an interactive user), so you'd use a client credentials flow.

In practice, you'd create a client for your admin app on your auth server and set it to use a client credentials flow that has an audience with your api. Then, your admin app can hit your auth server to get a token that your api will accept, and actually make a request to the api to wipe the spam.

Does that make sense? Did I understand the use case properly?

[sshquack]

Yes -- That perfectly answers my question. I will look into the code credentials flow for bot token. Thank you!

Another slightly related question, in the Craftsman auth example from 0.13 release notes, I see the Roles.SuperAdmin. Is it the right way to assign this SuperAdmin role for the automated bot user jwt or is better to create a separate role for this bot?

[pdevito3]

You could give it superadmin permissions, but I'd create a new role for good measure and only give it the explicit permissions you want.

[sshquack]

Ok makes sense. Appreciate the quick response. Cheers!