start OPAQUE login workflow, maintain login state in cache while
we wait for finish RPC from client
Details
- Reviewers
• jon bartek - Commits
- rCOMM62822c20850e: [identity] login start
tested with login finish in subsequent diff
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
services/identity/src/client_service.rs | ||
---|---|---|
238–247 | I think this should work, not a fan of a nested if let | |
services/identity/src/database.rs | ||
431–445 | All users should have a user id, can we just make this Result<String, Error>? Error::NotFound relating to whatever would fit best | |
450 | Similar to above, collapse Result<Option<T>, E> to Result<T,E> |
services/identity/src/database.rs | ||
---|---|---|
431–445 | I'm saying that a user entry will always have a user_id. If it's not there, then we can assume that it's an error. |
services/identity/src/database.rs | ||
---|---|---|
431–445 | ok, imagine we're doing some cleanup workflow and we want to make sure a user with username foo was deleted by calling this function. in this scenario, Ok(None) is the most appropriate return value, hence the Option within the Result. |
services/identity/src/database.rs | ||
---|---|---|
431–445 | maybe i'm not fully understanding your point... we can discuss over Comm if that's the case |
services/identity/src/database.rs | ||
---|---|---|
431–445 | Maybe you already discussed this elsewhere, just wanted to put my point here My reasoning of such cases is:
|
services/identity/src/database.rs | ||
---|---|---|
431–445 | We could just use the username_available method in that case, and we don't have to deal with ternary logic. Seems like are trying to find a problem for a potential solution. |
I'm not sure the best path forward for handling the dynamodb logic, but in time I'm sure we will become more clear.