mytechdiary

 I had a habit of always adding a null check at the start of a method, for validating method arguments. However, I gradually learnt this might not always be a good idea. Checking for nulls when your code does not expect a null value would just hide the problem happening upstream. Also, since the error would manifest in some other part of the code, it will be a nightmare the debug what actually failed. Instead, if you let the code throw an NPE, your application will fail fast and report exactly where the exception was thrown. So, unless your code expects nullable values, its not a good idea to add null checks. More discussion on this - https://softwareengineering.stackexchange.com/questions/147480/should-one-check-for-null-if-he-does-not-expect-null

CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS Cookies https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies - You can ensure that cookies are sent securely and aren't accessed by unintended parties or scripts in one of two ways: with the Secure attribute and the HttpOnly attribute. - Secure - A cookie with the Secure attribute is only sent to the server with an encrypted request over the HTTPS protocol. It's never sent with unsecured HTTP (except on localhost), which means man-in-the-middle attackers can't access it easily. - HttpOnly - A cookie with the HttpOnly attribute is inaccessible to the JavaScript Document.cookie API; it's only sent to the server. For example, cookies that persist in server-side sessions don't need to be available to JavaScript and should have the HttpOnly attribute. This precaution helps mitigate cross-site scripting (XSS) attacks. This does not mean HttpOnly cookies are not sent with XHR requests. TODO CSRF, XSS, Cac...

Publisher - Subscriber model Loosely coupled, program to interfaces and not implementations - because the Publisher does not store concrete implementation of the Observer is. It just stores Observer interface references in a list. This achieves loose coupling.

Checked exceptions are compile-time exceptions, meaning the compiler will throw an error if it sees your code is not handling a checked exception. The intention is to allow the developer to handle these recoverable situations gracefully. As opposed to this, there are exceptions from which you cannot recover. For example, when a user tries to login with the wrong set of credentials, you don't really have an option but to fail the request and show an error, in this case, a 401 which prompts the client to ask the user to authenticate.

 https://developer.okta.com/docs/concepts/saml/#understanding-sp-initiated-sign-in-flow - This is really a must read before working with SAML apps

 Key Rotation - https://developer.okta.com/docs/concepts/key-rotation/ Validating Tokens - https://developer.okta.com/docs/guides/validate-access-tokens/dotnet/main/