I want to read Scopes and Clients from database instead of InMemoryClients & InMemoryScopes in Identity Server 3.
Any one please help me how to read how we can achieve this in identity server 3.
Thanks in advance.
From the docs (https://identityserver.github.io/Documentation/docsv2/ef/overview.html):
If scope or client data is desired to be loaded from a database (rather than use in-memory configuration), then we provide a Entity Framework based implementations of the IClientStore and IScopeStore services.
If you do not wish to use Entity Framework, you just need to implement these two interfaces yourself.
Related
I want to implement a multi-tenant solution where I have one webserver and one database shared across all tenants. Regarding to this blog post from AWS it is "pooled multi tenancy model".
I'm using nest.js and sequelize. If sequelize is not a good fit for this I also could switch to another library like typeORM if necessary.
How can this be implemented? I'm absolutely clueless how I can use a different connection (different database user) for each HTTP request and also I don't know how to set a runtime context variable for the connection in a good way.
What I get currently is that every HTTP requests contains a header tenant-id. This should be used for all queries.
There is also the concept of scopes in sequelize. But this is something that is implemented on the client side and not on the database directly. Also, this is something that is specific to sequelize. I would prefer a solution that is independent from sequelize and maybe more specific to PostgreSQL.
Is there any way to implement this with sequelize? A hint or a basic approach would be sufficient.
That seems that this approach is similar. https://learn.microsoft.com/en-us/microsoft-365/education/deploy/design-multi-tenant-architecture.
I'm studding for create a similar architecture, but i will use the "silo" model or "physical database". I think that at first you need to create a internal database called "catalog" that will contains the information of the user (this user already have a login? if true select this information) where have to contains a previous credentials how tenant-id. About the Sequelize, i guess that is necessary to use RAW queries for create ROLE|GRANT|DATA BASE etc and the MIGRATIONS to create the same DB for each new clients.
Situation:
For our SaaS API we use schema-based multitenancy, which means every customer (~tenant) has its own separate schema within the same (postgres) database, without interfering with other customers. Each schema consists of the same underlying entity-model.
Everytime a new customer is registered to the system, a new isolated schema is automatically created within the db. This means, the schema is created at runtime and not known in advance. The customer's schema is named according to the customer's domain.
For every request that arrives at our API, we extract the user's tenancy-affiliation from the JWT and determine which db-schema to use to perform the requested db-operations for this tenant.
Problem
After having established a connection to a (postgres) database via TypeORM (e.g. using createConnection), our only chance to set the schema for a db-operation is to resort to the createQueryBuilder:
const orders = await this.entityManager
.createQueryBuilder()
.select()
.from(`${tenantId}.orders`, 'order') // <--- setting schema-prefix here
.where("order.priority = 4")
.getMany();
This means, we are forced to use the QueryBuilder as it does not seem to be possible to set the schema when working with the EntityManager API (or the Repository API).
However, we want/need to use these APIs, because they are much simpler to write, require less code and are also less error-prone, since they do not rely on writing queries "manually" employing a string-based syntax.
Question
In case of TypeORM, is it possible to somehow set the db-schema when working with the EntityManager or repositories?
Something like this?
// set schema when instantiating manager
const manager = connection.createEntityManager({ schema: tenantDomain });
// should find all matching "order" entities within schema
const orders = manager.find(Order, { priority: 4 })
// should find a matching "item" entity within schema using same manager
const item = manager.findOne(Item, { id: 321 })
Notes:
The db-schema needs to be set in a request-scoped way to avoid setting the schema for other requests, which may belong to other customers. Setting the schema for the whole connection is not an option.
We are aware that one could create a whole new connection and set the schema for this connection, but we want to reuse the existing connection. So simply creating a new connection to set the schema is not an option.
To answer my own question:
At the moment there is no way to instantiate TypeORM repositories with different schemas at runtime without creating new connections.
So the only two options that a developer is left with for schema-based multi tenancy are:
Setting up new connections to connect with different schemas within the same db at runtime. E.g. see NestJS Request Scoped Multitenancy for Multiple Databases. However, one should definitely strive for reusing connections and and be aware of connection limits.
Abandoning the idea of working with the RepositoryApi and reverting to using createQueryBuilder (or executing SQL queries via query()).
For further research, here are some TypeORM GitHub issues that track the idea of changing the schema for a existing connections or repositories at runtime (similar to what is requested in the OP):
Multi-tenant architecture using schema. #4786 proposes something like this.photoRepository.useSchema('customer1').find()
Handling of database schemas #3067 proposes something like getConnection().changeDefaultSchema('myschema')
Run-time change of schema #4473
Add an ability to set postgresql schema per call #2439
P.S. If TypeORM decides to support the idea discussed in the OP, I will try to update this answer.
Here is a global overview of the issues with schema-based multitenancy along with a complete walkthrough a Github repo for it.
Most of the time, you may want to use Postgres Row Security Policy instead. It gives most of the benefits of schema-based multitenancy (especially on developer experience), without the issues related to the multiplication of connections.
Since commenting does not work for me, here a hint from the documentation of NestJS:
https://docs.nestjs.com/techniques/database#async-configuration
I am not using NestJS but reading the docs at the moment to decide, if it's a fitting framework for us. We have an app where only some modules have multi tenancy with schema per tenant, so using TypeOrmModule.forRootAsync(dynamicCreatedDbConfig) might be an option for me too.
This may help you if you have an interceptor or middleware, which prepares the dynamicCreatedDbConfig data before...
I'd like to know if it's mandatory to use DataAnnotations for breezejs ef metadata provider to properly get all configurations for each entity? Alternatively, can one avoid the use of any conventions or data annotations and instead configure a mapping class for each entity with explicit mappings and configurations?
You have several options:
1) You can define the metadata yourself on either the client or server, instead of having it generated from EF metadata. See the Breeze Metadata discussion here
2) You can define this same metadata on the client. See the MetadataStore addEntityType method.
3) Along with either of the two options above, you can 'reinterpret' any json results returned from any web service call with the JsonResultsAdapter. We will have an example of this out within the next week or so. By default, this is done for you, but you can intercept the process.
4) Hybrid use, where some entities are defined via metadata from the server and some from client side metadata are also possible. Similarly, you can choose to implement a JsonResultsAdapter for just selected queries and use the default for the rest.
Hope this helps.
Setup
I have a SQL Server 2008 database that is accessed using the Entity Framework on the server.
Each client has a SQL Server Compact Edition 3.5 database for storing data when offline.
I use self tracking entities that are generated from the server defined Entity Framework.
Question
At the moment i have two EDMX defined, one for the server and another for the client, even though they are identical except for the storage provider. I use the self tracking entities from the server and they work fine with the client database. Is there a way to have just a single EDMX? At the moment there is a risk I will make a change to one EDMX and forget to make it to the other. Or am I using the wrong approach?
Note
I do not want to use the sync framework because of complex business logic that needs applying at the server side.
Unfortunately there is no direct way to use single EDMX with multiple storage providers. You must always have separate SSDL part for each provider. The common workaround is to export SSDL, MSL and CSDL as separate files (default setting adds them as resources to assembly) and use some script or pre-build action to create copy of SSDL file with all necessary changes for second provider (there can be also different data types between SQL Server and SQL Server CE). You will than use correct SSDL file per application by specifying it in connection string.
Another "better" solution is not using EDMX and use code first where this problem mostly doesn't exist - but that is architecture change.
I have an ADO.NET Managed Data Provider that is registered in machine.config in DbProviderFactory - It is available for use from, say, Analysis Services, so I know it is correctly registered.
However, I need to be able to query the managed provider from Excel, but the managed provider doesn't appear as a choice from Data Link Properties | All Ole Db Providers.
How do I get an ADO.NET Managed Data Provider to appear there, or is there another technique I need to use?
Thanks in advance,
Eli.
Turns out there is no way to directly use an ADO.NET provider in Excel.
Had to write an OLE DB provider (in ATL C++ no less) to bridge the two - that was fun...
It is a late post, but now there is an ADO.NET way to this - http://support.microsoft.com/kb/316934#12
I have a potential workaround.
I am going to create a CLR stored procedure that will in turn perform a passed SQL query using the managed provider.
I can then invoke the stored procedure using SQLServer OLE DB or ODBC providers.
It should work, if Murphy stays away.