Feature: Accept Asymmetric Algorithm

[filwaline]

I implemented SymmetricSecret and AsymmetricSecret, and drop replace it.

New tests all passed, and fully covered.

I am poor in English, so docs remain old.

[filwaline]

For #70

LoginManager now accept single secret still, nothing is broken. But It also accept dict, for asymmetric purpose.

# random string or private-key(pem format)
random_string = ...  
private_key_pem_bytes = ...

# algorithm must match secret type
# random string & HS256
LoginManager(secret=random_string, algorithm="HS256", ...)
# private-key & RS256
LoginManager(secret=private_key_pem_bytes, algorithm="RS256", ...)
# dict secret
LoginManager(secret={"private_key":private_key_pem_bytes, "password": ...}, algorithm="RS256", ...)

[filwaline]

I am using black as code formatter, lots of changes just formatting.

[MushroomMaula]

Looks really good. Thanks a lot for your help.
Maybe you can answer the two questions regarding my comments.

[MushroomMaula]

Can you give an example of how this class should be used?
I assume this is one way the input can be given to the secret parameter for LoginManager when using asymmetric keys? If so I think it is a good idea to add a test case that uses this class in addition to the dictionary approach.

[filwaline]

Test cases about dictionary-secret already exists, see

https://github.com/filwaline/fastapi_login/blob/0f0dc21d9b07f35a6b5c909c4e44d89602ecfe5d/tests/test_secret.py#L22-L36

and

https://github.com/filwaline/fastapi_login/blob/0f0dc21d9b07f35a6b5c909c4e44d89602ecfe5d/tests/test_secret.py#L61-L66

---

Each item of above is one test case, thank to pytest.

Read more at https://docs.pytest.org/en/6.2.x/parametrize.html

[filwaline]

Parsing are handled by pydantic model AsymmetricSecret, so RawPrivateSecret will be take care and should not use directly.

RawPrivateSecret is part of AsymmetricSecretIn, and the latter one is used to pre-validate AsymmetricSecret's secret field.
https://github.com/filwaline/fastapi_login/blob/0f0dc21d9b07f35a6b5c909c4e44d89602ecfe5d/fastapi_login/secrets.py#L45-L48

[MushroomMaula]

But RawPrivateSecret is never invoked directly? In AsymmetricSecret data is of type AsymmetricPairKey, this is also mismatch of the type when passing to AsymmetricSecretIn as the data parameter here expects either SecretBytes or RawPrivateSecret, therefore I don't see how or why pydantic should cast the given value to either one of them.

[filwaline]

Because the flag pre=True indicated that it is a pre-validator.
Therefore AsymmetricSecret haven't paring raw data into AsymmetricPairKey yet, not until the end of pre-validator secret_must_be_asymmetric_private_key, AsymmetricSecretIn is actually dealing with raw data.

---

A step-by-step debug process will show you how data flows, it is better than plain text.

[filwaline]

secret_must_be_asymmetric_private_key is handling three different jobs:

1. validate the syntax of raw data
   • L48
2. validate if given data is a valid asymmetric key
   • L49-L53
3. derive it's public key and cast into AsymmetricPairKey
   • L55-L67

[MushroomMaula]

I think I got it now.
If one passes {"private_key": "...", "password": "..."} to AsymmetricSecret, this is then passed onto AsymmetricSecretIn, which in turn is recognized by pydantic as having the same fields as RawPrivateSecret and is thus validated as such. If all of this passes the public key is derived from the private key and then cast together as AsymmetricPairKey.

[filwaline]

I think I got it now. If one passes {"private_key": "...", "password": "..."} to AsymmetricSecret, this is then passed onto AsymmetricSecretIn, which in turn is recognized by pydantic as having the same fields as RawPrivateSecret and is thus validated as such. If all of this passes the public key is derived from the private key and then cast together as AsymmetricPairKey.

Yes, that what I meant!

[filwaline]

Current code only accept PEM format key, do you think we should accept other formats?
For example, DER format.

[MushroomMaula]

I think PEM is sufficient for now, if the other formats are needed it shouldn't be too much trouble adding them later on.

[MushroomMaula]

Yeah I saw that, but I think if the support is there it doesn't hurt to make it available directly.

[MushroomMaula]

On the other hand it is probably a good idea to not include it if it isn't needed 🤔 . If so, I think it would be helpful to show a message that cryptography needs to installed when a key pair is passed as the secret.

[filwaline]

On the other hand it is probably a good idea to not include it if it isn't needed 🤔 . If so, I think it would be helpful to show a message that cryptography needs to installed when a key pair is passed as the secret.

Current message is a pydantic validation error that algorithm"RS256" is invalid, if user selected "RS256" but not installed cryptography.

Maybe you can add some documents about it, just like FastAPI Form Data

[MushroomMaula]

I will add some documentation in the following days explaining the workflow with asymmetric keys and will then merge and publish a new package version.
Thanks a lot for your help so far.