This would basically involve creating a intermediary object that can create itself from the Paseto message format, and serialise itself back into it (that way we centralise the construction of messages away from individual implementations too). Then we can pass that to decrypt and verify methods, and it could be produced by encrypt and sign methods. The new PasetoMessage object in this PR is almost capable of being that intermediary object (sans a serialisation implementation).
The end result would be a little more verbose in PHP as you'd have to check the header validity manually where it matters (in the above implementation header correctness is enforced by choice of type parameters).
This is me basically just ripping this out in its PHP equivalent form
https://github.com/aidantwoods/swift-paseto/blob/f39f8a0c639c18fbeb417b4a52a5ff9c1115294d/Sources/Paseto/Blob.swift#L39-L54![screen shot 2018-03-14 at 00 01 35](https://user-images.githubusercontent.com/3288888/37376140-e6bfa4ac-271a-11e8-9b14-d2d9e2eb8e01.png)
I found it useful for creating a "take a peak at the header" convenience function, and it serves to basically do that here except for the footer (to avoid duplicating the parsing code). https://github.com/aidantwoods/swift-paseto/blob/f39f8a0c639c18fbeb417b4a52a5ff9c1115294d/Sources/Paseto/Util.swift#L24-L27![screen shot 2018-03-14 at 00 02 44](https://user-images.githubusercontent.com/3288888/37376173-0dadb7b6-271b-11e8-8237-b94a1945ba89.png)
In-fact it also serves to separate message deconstruction from the validation specifics inherited by the parser object settings too.
If there is appetite, its possible to actually take this a little further and defer to a shared message deconstruction implementation within the protocols too, e.g. something like https://github.com/aidantwoods/swift-paseto/blob/f39f8a0c639c18fbeb417b4a52a5ff9c1115294d/Sources/Paseto/Implementations/Version2.swift#L58-L78![screen shot 2018-03-14 at 00 05 03](https://user-images.githubusercontent.com/3288888/37376333-a74b6b52-271b-11e8-92a3-8e5e2ef6a907.png)
This would basically involve creating a intermediary object that can create itself from the Paseto message format, and serialise itself back into it (that way we centralise the construction of messages away from individual implementations too). Then we can pass that to
decrypt
andverify
methods, and it could be produced byencrypt
andsign
methods. The newPasetoMessage
object in this PR is almost capable of being that intermediary object (sans a serialisation implementation).The end result would be a little more verbose in PHP as you'd have to check the header validity manually where it matters (in the above implementation header correctness is enforced by choice of type parameters).
This also fixes the issue pointed out in https://github.com/paragonie/paseto/commit/2d3d70d102c58c7267f0544a8ed4218bbf53712b#r28076938 by @rlittlefield. Apparently the parser has somehow been getting away without having any test cases that have a footer in public mode 😆 (test cases filling this gap still need to be added)