Page MenuHomePhabricator

[Identity] Handle key payload
ClosedPublic

Authored by jon on Apr 4 2023, 8:02 AM.
Tags
None
Referenced Files
F3382511: D7298.id24598.diff
Thu, Nov 28, 11:10 AM
F3382464: D7298.id24841.diff
Thu, Nov 28, 10:56 AM
Unknown Object (File)
Tue, Nov 26, 11:17 AM
Unknown Object (File)
Sun, Nov 24, 6:32 PM
Unknown Object (File)
Sun, Nov 24, 6:31 PM
Unknown Object (File)
Sun, Nov 24, 6:26 PM
Unknown Object (File)
Sun, Nov 24, 4:16 PM
Unknown Object (File)
Fri, Nov 22, 7:54 AM
Subscribers

Details

Summary

Allow for the key payload to be serialized and deserialized.

This is needed later for verifying that the payload is correctly
structured and a device is also identified by the identity public key.

Test Plan
cd services/identity
cargo test

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

Clean up accidental additions

varun requested changes to this revision.Apr 5 2023, 11:22 AM
varun added inline comments.
services/identity/src/database.rs
40–46 ↗(On Diff #24599)
49 ↗(On Diff #24599)

DDB complains if we don't escape the payload?

51 ↗(On Diff #24599)

How about

impl FromStr for KeyPayload {
  type Err = serde_json::Error;

  fn from_str(s: &str) -> Result<Self, Self::Err> {
    serde_json::from_str(&s.replace(r#"\""#, r#"""#))
  }
}
This revision now requires changes to proceed.Apr 5 2023, 11:22 AM
jon marked 3 inline comments as done.

Address feedback

services/identity/src/database.rs
49 ↗(On Diff #24599)

no, that's just what is currently in DDB. I'm assuming how we create the payload on the JS side is creating an escaped payload

51 ↗(On Diff #24599)

sure

varun added inline comments.
services/identity/src/database.rs
52 ↗(On Diff #24725)
57–59 ↗(On Diff #24725)

we're intentionally leaving this commented? we probably won't ever need this method since the payload is created on the client, right?

This revision is now accepted and ready to land.Apr 6 2023, 12:32 PM
jon added inline comments.
services/identity/src/database.rs
57–59 ↗(On Diff #24725)

no, looks like I forgot about this.

we probably won't ever need this method since the payload is created on the client, right?

Did it because of it felt "right" for serialize/deserialize, but yea, this should be pretty much immutable, so there's no need to "serialize" it.

jon marked an inline comment as done.

Address feedback

This revision was automatically updated to reflect the committed changes.