It will findout all the interfaces on the target type, and if they are one of these interfaces:
- IConfigureOptions<>
- IPostConfigureOptions<>
- IValidateOptions<>
It will register it by calling:
AddJwtBearer() provides a delegate to configure JwtBearerOptions, see example. The problem is that there's no way to set the value based on another option.
For example, if you created a custom AuthOptions, which includes basic information like the signing key, audience, issuer, and so on to be configured environment by environment, there's no way to access it in AddJwtBearer() method.
If you prefer to read the code, here is an implementation.
| # top-most EditorConfig file | |
| root = true | |
| [*] | |
| indent_style = space | |
| indent_size = 4 | |
| end_of_line = crlf | |
| charset = utf-8 | |
| trim_trailing_whitespace = false | |
| insert_final_newline = false |
Please refer to the codebase for details:
Last time, I posted about binding a custom domain of https://stack.codewithsaar.net to GitHub Page, (Read it here), noticing that is actually a subdomain(stack.abc.com). Ever since, I have turned on another GitHub page for my own - https://www.codewithsaar.net (and also https://codewithsaar.net) on an apex domain.
Since DNS is not my day to day job, it took me a couple of try and error to get it work. So, I am here to do a follow up.
It had always been a pain to host a small/basic/quick/light-weight website on a custom domain that supports HTTPS. Common issues are Domain verification, certificate rotation/management, and quick iteration with a easy to understand CI/CD pipeline.
However, this year, when I try it again with GitHub pages, it blowed my mind. I think it addresses all those pain points and I have to say, good job GitHub!
(Image comes from internet)
I'll put down some reasons to enable HTTPs on a custom domain of my own. If you only want to see how I did it, jump to How I did it.