Since the OAuth server I’ve detailed previously is using OWIN, I’ve been looking at what it will take to move it to .NET Core. The OWIN OAuth Server provides all of the Secure Token creation. This functionality is not provided with .NET Core’s native middleware.
My first thought is to integrate with IdentityServer4 or Openiddict which provide Secure Token generation and are .NET Core compatible. After some cursory information gathering, I’m putting a few research links here for later use.
Long, long ago, I wrote about StartSSL. It was actually one of my first blog posts. After using the StartSSL (StartCom) service without issue for over two years, it appears that their root authority has been revoked making their free service virtually useless. I had to find an alternative.
I’ve been reading up on Angular2, Redux, React and other various libraries and frameworks over the weekend.
I’m in the process of understanding what using Redux w/ an Angular2 app provides that using a singleton service doesn’t. But, it seems to be more about preference (imho) than real-world benefit. It may help tie into observable / push notifications to make state change detection between immutable / mutable objects more performant. However, I can see a benefit if one wants to swap out frameworks and allow their previous state management work across frameworks. It’s an interesting prospect from that perspective.
I have amassed a lot of code. When I’m creating a new web application, this is handy because it provides me with a good basis. However, I’ve never gone to the trouble of wrapping all of this into a template to eliminate the redundancy.
A friend of mine asked me earlier today what a good pattern for accessing an Api from within a class library would look like. In .NET, I generally like to wrap this type of functionality within a service that can be injected.
In my last post, I discussed some observations that I made regarding maintaining legacy web-sites. Although, afaik, all of the information I presented in that post is accurate, if you want to bring your old quirks/compatibility-view reliant page up to modern HTML5 standards, here are some tips.
Over the weekend, I had an interesting experience updating an old, legacy website that uses ASP. ASP is interesting, but the more interesting thing is that many of these old applications rely on specific browser modes or default to “quirks” mode.
While testing a new application that utilizes my multiselect drop-down widget, I noticed some weird behavior with IE11.
Earlier today I was playing around with Google’s Font API. I wanted to pull down OpenSans to host locally, but Google’s Font API is geared more toward utilizing Google’s hosting resources.
Continuing the discussion of integrating server-side validation with client-side validation, let’s check out a demo of this in action.
All of the Angular code for this demo has been moved to my general demo Github repository.