Page MenuHomePhabricator

[identity] login start
ClosedPublic

Authored by varun on Apr 19 2023, 1:23 PM.
Tags
None
Referenced Files
F1439511: D7538.id25636.diff
Thu, Mar 28, 7:41 PM
F1439510: D7538.id25474.diff
Thu, Mar 28, 7:41 PM
F1439509: D7538.id25419.diff
Thu, Mar 28, 7:41 PM
F1439508: D7538.id25402.diff
Thu, Mar 28, 7:41 PM
F1439507: D7538.id25463.diff
Thu, Mar 28, 7:41 PM
F1439483: D7538.id.diff
Thu, Mar 28, 7:40 PM
F1439466: D7538.diff
Thu, Mar 28, 7:38 PM
Unknown Object (File)
Tue, Mar 12, 6:14 PM
Subscribers

Details

Summary

start OPAQUE login workflow, maintain login state in cache while
we wait for finish RPC from client

Test Plan

tested with login finish in subsequent diff

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

Harbormaster returned this revision to the author for changes because remote builds failed.Apr 19 2023, 1:36 PM
Harbormaster failed remote builds in B18538: Diff 25402!
Harbormaster returned this revision to the author for changes because remote builds failed.Apr 19 2023, 2:34 PM
Harbormaster failed remote builds in B18554: Diff 25419!
jon added inline comments.
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>

This revision now requires changes to proceed.Apr 20 2023, 11:51 AM

address feedback

services/identity/src/database.rs
431–445

I don't think the db client should decide whether not getting back a user id is an error or not. that's up to the caller

450

same reasoning as above

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:

  • If there's a legit possibility of having table entry without user_id (e.g. the user was deleted or sth), returning None is OK - the caller will decide what to do
  • If all entries always must have the user_id, lack of this field means database inconsistency/corruption, then an error should be thrown.
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.

This revision is now accepted and ready to land.Apr 24 2023, 1:08 PM
This revision was automatically updated to reflect the committed changes.