Git Code Commit (all commits between last post and this commit (link))
Next for The Globe In My BucketList Application (TGIMBA) Application Programmable Interface (API) are the API and service layers. The biggest change is the API is in its own solution now.
Like the data layer, I see no reason to change the service contract, just the implementation underneath. So I added the suffix ‘_Old’ to the current service interface and added a new one with a stub implementation. The Misc methods are implemented with tests.
- GeneratorHelper.cs – I added a method for generating a JSON Web Token (JWT) based on a previous post here.
- GeneratorHelper.cs – The private key and issuer methods just return strings. I generated the private key using existing .NET classic ‘RSACryptoServiceProvider’ class. Apparently, it does not exist in .NET Core 2.x, but does in .NET Core 3.x. I am running .NET Core 2.2 now. Eventually I will upgrade and remove the .NET Class project 🙂
- I updated the method for hashing my passwords. Specifically, using the ‘Rfc2898DeriveBytes’ provider in conjunction with the HashAlgorithmName.SHA256 algorithm. Previously, I had just used the SHA256 algorithm. Apparently, this is considered more secure. References #4 and #6 were especially helpful with this.
- I had planned on doing the service layer first, but found it difficult to break the parameter validation and error handling between the API and server layers. So, these two functions are handled in the API layer since it is the entry and exit points. Also, based on what I have read, specific errors (i.e. 404, 500, etc) are easier when they reside in the API layer.
- Interesting side bit. As I was looking for a general error to return in case of an issue (remember, you never want to return specifics but a general error with a code and log the specifics in your database), I discovered that the ASP .NET Core team has removed ‘HttpResponseException’. The details are in reference #2, but their justification seems a bit flat to me. As developer, I want options and not to be forced down a certain route. I also found this in my research (see blog post here) on ways to do .NET Core authorization and authentication. They had removed specific interfaces/implementations others had used. It would be nice if options are persisted and not removed just because a designer on a team feels all folks should use a specific approach. More to the point, in reference #2, there are a couple of folks who are implementing their own replacement for HttpResponseException. I ended up placing a try catch in each API method and in case of an error, I return a 500 via the HttpStatusCode enumeration.
The API/service layer will be done in three posts – misc, user and bucket list related methods/tests. I would have done all of this in one blog post, but it would be another 2-3 months before it was ready.
I am trying to work in digestible chunks that fit in with working full time and having a family 🙂