I am looking at samples for IdentityServer 4 for production which doesnt have this annoying InMemory 'this and that'. Basically we need to configure the IdentityServer's IdentityResource, ApiResource, Client, Scope (basically everything) from database.
I have got following (so far) in my code, But not sure how to get all above from the database.
services.AddIdentity<User, Role>()
.AddEntityFrameworkStores<RegistrationContext>()
.AddDefaultTokenProviders();
Any help or pointers are much appriciated.
This is for IdentityServer4, dotnet core, and EF Core.
Related
I'm new at prisma 2 but have got a database working. I have used prisma 'init' and 'migrate dev' to create database tables for my model and can interact with the database using the Prisma client - prisma 2.22.1
Usually for a project, I'd have dev, test and prod environments and use env-cmd to set the relevant differences, e.g. connection details for getting to the database.
With prisma 2 however, it seems like there's a single .env file that is used for the database connection details, so I cannot see how to proceed for the different environments.
Note that I'm not meaning different types of database - in this example all are postgresql.
I can see possibilities for getting past this hurdle, for example for the script to write a suitable .env file according to the required environment as part of running the app, but 'not ideal' really doesn't give this idea the review that it deserves. Or getting more computers.
Any suggestions please for using different databases from the same project? Am I missing something basic or is it deliberately blocked?
I'm making an api in which I separate my requests by responsibilities, services, repository and routes, I'm using typeorm to connect to the database, and I'm trying to implement unit tests to test my application so I have to unclip my code from the typeorm of so that my tests are not depending on it. However, at the time of decoupling, the typeorm is no longer able to connect with the bank, which is mongodb, returns the following error: ConnectionNotFoundError: Connection "mongo" was not found.
I've been reading about it and from what I understood the typeorm wouldn't give full support to the mongo, that's why it failed. I would like to confirm with you if that would be the case and what would be the best alternative to solve this.
MongoDB is supported by TypeORM (although I have not used it personally myself).
You can follow a short tutorial here.
What is not supported for Mongo is the typeorm "Migration" feature. For example see typeorm issue 6695. Migration is an advanced topic and you probably do not need it. But if you do, a workaround is on stackoverflow answer here.
But this Migration issue has nothing to do with your error. Almost certainly, your getConnection() call or ormconfig.json are incorrect. Start a with simple project based on the TypeORM Mongo tutorial, nothing else, verify you can connect to MongoDB, and work up from there.
I have two folders for my migrations (AuthContext and UserProfileContext), each has their own migration and some custom sql to run afterwards for data migrations and whatnot.
This works fine when using package manager console. I
Restore from production
Run Update-Database -ConfigurationTypeName Migrations.Auth.Configuration
Run Update-Database -ConfigurationTypeName Migrations.UserProfile.Configuration
Then everything is very happy in the new database, migrations executed data shuffled where it needs to.
I tried to test out the migrations on publish piece by:
Restore production on dev database
Single connection string (all contexts use the same) pointed to dev database
Publish to azure web site
Checked the box for Apply Code First Migrations
Selected that single connection string
Okay it published fine; however, when I went to look at the database, nothing happened! It did not create the necessary tables, columns, or data moves.
TLDR; Code first migrations are not running after publish to Azure
Update 1
I've tried any combination of the below: only one single connection string so I'm guessing that's not the issue, and execute migrations is checked.
On publish the api runs but no database changes are made. I thought perhaps I needed to hit it first but I just get random errors when I try to use the api (which now of course relies on the new database setup), and the database is still not changed.
I've seen a couple references out there about needing to add something to my Startup class but I'm not sure how to proceed.
Update 2
I solved one issue by added "Persist Security Info=True" to my connection string. Now it actually connects to the database and calls my API; however, no migrations are running.
I attached debugger to Azure dev environment and stepped through... on my first database call it steps into the Configuration class for the Migration in question, then barfs and I can't track down the error.
public Configuration()
{
AutomaticMigrationsEnabled = false;
MigrationsDirectory = #"Migrations\Auth";
ContextKey = "AuthContext";
}
Update 3
Okay, dug down and the first time it hits the database we're erroring. Yes this makes sense since the model has changed, but I have migrations in place, enabled, and checked! Again, it works fine when running "Update-Database" from package manager console, but not when using Execute Code First Migrations during publish to Azure
The model backing the 'AuthContext' context has changed since the
database was created. Consider using Code First Migrations to update
the database (http://go.microsoft.com/fwlink/?LinkId=238269).
Update 4
Okay I found the root issue here. VS is setting up the additional web.config attrib for databaseInitializer on only one of my database contexts, the one not mentioned is in fact hit first from my app.
So now I have to figure out how to get it to include multiple contexts, or, combine all of my stuff into a single context.
The answer to this post is not very detailed.
This article explains what I had to do to fix a similar problem to this:
https://blogs.msdn.microsoft.com/webdev/2014/04/08/ef-code-first-migrations-deployment-to-an-azure-cloud-service/
I'll roughly describe the steps I had to take below:
Step 1
Add your connection strings to your dbContexts, in my situation, they were both the same.
Step 2
Add this to your web.config
<appSettings>
<add key="MigrateDatabaseToLatestVersion" value="true"/>
</appSettings>
Step 3
And add this to the bottom of your global.asax.cs / Startup.cs(OWIN startup)
var configuration = new Migrations.Configuration();
var migrator = new DbMigrator(configuration);
migrator.Update();
Solved! To summarize the solution for posterity:
Enable Code First Migrations only enables them for one base connection string per checkbox checked, regardless of how many contexts have migrations against that base connection string. So in my case I broke out the two in question into two different connection strings.
Then I was hitting other errors and identified that if you're changing the base connection string to the model backing asp identity you need to include (one time publish) the additional flag base("AuthContext" , throwIfV1Schema: false)
For anyone who has this issue and may have overlooked the following: be sure to check that you have correctly set the connection string in your Web.config file and/or Application settings on Azure. This includes DefaultConnection and DefaultConnection_DatabasePublish.
In our case the former was correct but the latter contained the wrong database instance because it had been carried over from an App Service clone operation. Therefore the wrong database was being migrated.
I am using Entity Framework using Code First and the Fluent API.
When developing on my local machine, the database and tables are created as expected and everything works fine.
When deploying to my Azure web role the database is created, but the tables are never created. If I try a HTTP request touching DbContext, the request times out and finally my web role only returns "Service Unavailable".
The model is large, but not extremely so (43 tables are created on my dev machine).
What can be wrong here? Here is my Azure SQL connection string, where you can see that I set the timeout quite high:
<add name="MyConnectionString" connectionString="Server=tcp:myserveronazure.database.windows.net,1433;Database=MyDatabase;User ID=MyUser#myserveronazure;Password=thepassword;Trusted_Connection=False;Encrypt=True;Connection Timeout=120;PersitSecurityInfo=true;" providerName="System.Data.SqlClient" />
EDIT: After RDP:ing into the Azure VM, I see in the Event Log that w3wp.exe (the IIS worker process, if I'm not mistaken) crashes. The log doesn't list any error message.
Enityframework have three Database Initializer by default CreateDatabaseIfNotExists,DropCreateDatabaseWhenModelChanges and DropCreateDatabaseAlways that are executed when you hit the context for the first time, if you are using migrations (i think is the case) you must use the MigrateDatabaseToLatestVersion initializer to work in the application deployment. Hope it works!
When on my dev machine, all works perfectly. Even using production connection values (so even when I connect to production from the dev machine). I don't think it's a permission problem because I am using the same credentials, just using EF5 instead of linq2sql, as the previous version of the service that worked. Also, the sql-profiler does not show a failed login attempt.
Connection string is:
Data Source=MYSQLSERVER;Database=MYDB;Integrated Security=True;
The error is:
Invalid value for key 'attachdbfilename'.
I have logged the connection string being passed into the dbContext code:
Database.Connection.ConnectionString = settings.DbConnectionHourly;
This is a class that inherits from my real dbContext (which packaged in a dll) and the settings get injected. Again, this works in Dev but not in production (server 2008 r2, IIS 7.5, framework.4).
Turns out that entity framework was trying to be very smart, but it was giving a very un-smart error message. So by convention, if you don't pass the context name in as a constructor, entity framework will assume the classname as the name of the connection string. What it will also do (which I was unaware of), is in development it will automatically connect to and create a schema using the visual studio built in sqlExpress. So in development, everything worked because this 'automagic' creation succeeded and since I later changed the connection to a different database, I was none the wiser about what EF was doing under the covers (EF was doing the wrong things but the end result worked).
However, when the application went to production, there is no sqlexpress or any database on the webserver so the automagic connection/creation sequence failed. Now if the error message had any useful information in it, this would be obvious. But since I had never set an 'attachdbfilename', nor did it tell me what the value of 'attachdbfilename' was or any context or what it was trying to do, this made figuring this out that much more challenging.
The fix was simple:
public HourlyContext(ISettingsWrapper settings)
: base(settings.DbConnectionHourly)
{ }
Instead of setting the connection after the context gets created (the creation process will immediately try to work it's magic with it's built in conventions/defaults), I now set it immediately through the constructor.