Nikki's Lunch

It is all started from my intention to add "iat" claim to access token. IssuedAt (iat) claim is optional so it takes a bit of searching to figure out how to do that. Add that to my unfamiliarity with IdentityServer4, it becomes quite a task. At this point, I am using IdentityServer4 version 3.0.2.0. First, I found out that you might be able to add custom claim by extending IProfileService. It works well for some random claim, but not "iat". Strange, it must be filtered somewhere then. Then browsing the source code in github, I found out that it was indeed filtered by FilterProtocolClaims method in DefaultClaimService: https://github.com/IdentityServer/IdentityServer4/blob/master/src/IdentityServer4/src/Services/Default/DefaultClaimsService.cs Ok, so I think I can extend DefaultClaimsService. I tried by adding a custom class in the StartUp using the following code: services.AddTransient<IClaimsService,CustomClaimsService>(); Sadly, it didn't work...

We were in the middle of moving to MySQL and would like to use EF Migrations against MySQL. But the error held us back a little. When trying to apply EF Migrations, it failed with "Specified key was too long; max key length is 767 bytes" error. The following article helped solve my problem. https://docs.microsoft.com/en-us/aspnet/identity/overview/getting-started/aspnet-identity-using-mysql-storage-with-an-entityframework-mysql-provider#adding-custom-migrationhistory-context Under "Adding custom MigrationHistory context" section, it talks about creating a custom HistoryContext class. In my case: Public Class MySqlHistoryContext           Inherits HistoryContext      Sub New(existingConnection As DbConnection, defaultSchema As String)           MyBase.New(existingConnection, defaultSchema)      End Sub      Protected Overrides Sub OnModelCreating(modelBuilder As DbModelBuilder) ...

As we all know, Entity Framework has default schema of "dbo", but MySQL will ignore it when performing migrations. But it gets troublesome when we try to rollback, because the dbo doesn't get ignored in that case.  Due to the fact that dbo doesn't get ignored, rolling back the migrations often caused error in my case. And removing the schema manually every time a new migration file is generated is tiring. That prompted me to find a way to remove the schema when new migration file is generated.  My first attempt is by looking inside the Configuration file. In my case, I have a custom HistoryContext because some MigrationHistory keys are just too long. And the custom HistoryContext is set in the Configuration file constructor: SetHistoryContextFactory(MySqlProviderInvariantName.ProviderName, Function(connection, schema) New MySqlHistoryContext(connection, schema)) After some online search, it seems like for some databases, setting the schema to something else alters ...

One of the complicated errors on EF6 that I often troubleshoot is the following: Unable to update database to match the current model because there are pending changes and automatic migration is disabled. Either write the pending model changes to a code-based migration or enable automatic migration. Set DbMigrationsConfiguration.AutomaticMigrationsEnabled to true to enable automatic migration. Usually, I will just run Add-Migration on Package Manager Console to see what changes in the schema. But this time it is strange, the Add-Migration includes the code to create existing tables. I searched for the migration files between the time those tables were created and the latest migration, I can't find anywhere that those tables were dropped. When trying to find some clue online, I bumped into the following amazing article:  https://tech.trailmax.info/2014/03/inside_of_ef_migrations/ . So, I went into the database and decompress a few blob/binary files from Model column. The files ...

I have an ASP.NET Core app hosted by A2 Hosting. A2 Hosting provides free SSL certificate through Let's Encrypt, so I decided to install it for my application. Since the portal is by Plesk, I follow the guide in: https://support.plesk.com/hc/en-us/articles/115000165013 However, it didn't work as expected. My application still has a web.config file. After trying different ways, I commented out aspNetCore module in the web.config and then the certificate was installed successfully. By commenting the module, ASP.NET Core processing by IIS is disabled, so the validation request by Let's Encrypt is treated like a regular request towards a static file.