`Parser` shouldn't produce signable `Builder`s? about paseto HOT 10 CLOSED

Yes, I think that would be a better design. I was trying to oversimplify before.

from paseto.

63c2af7 side-steps the anti-patterns with the parser. I'll make sure the builder doesn't do anything weird either.

from paseto.

I believe this is closable now?

from paseto.

Will this not still cause a type mismatch?

As ->setKey still requires a secret key in the asymmetric crypto case, but the parser has a public one.

i.e. shouldn't the parser produce a JsonToken (since they now do not require a key)

from paseto.

I think if you add a test case where the parser uses a 'public' purpose you'll get an error when trying to construct the builder (at present the tests only use 'local' in the parser and then convert the resulting object to the asymmetric case).

from paseto.

Shit, you're right.

from paseto.

An idea I had was to make a couple of empty interfaces extending KeyInterface named SendingKey and ReceivingKey (would match language in cbd01fe#diff-fa390ca15b142c05e438dcbc19a23aa5R65) and make AsymetricPublicKey implement ReceivingKey, AsymetricSecretKey implement SendingKey and SymmetricKey implement both. This might help declare the key intent upfront to catch this earlier in future ;-)

from paseto.

I'll update #37 for the current master, since it defers the key intent just configuring a couple of array consts in Purpose, and then allows you to defer key and purpose validity checks there depending on intent.

from paseto.

Okay, I'll stop making changes to dev-master for the evening then. :)

from paseto.

Closing due to 63c2af7 :)

from paseto.