Part of ENG-4939. We need to support both access token coming from users (commServicesAccessToken) and private service-to-service token. I've decided to create an enum for this
Details
Details
NOTE: I'm open to naming suggestions
Added unit tests. Also tested later in the stack
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Just some nits
services/comm-services-lib/src/auth.rs | ||
---|---|---|
6–7 ↗ | (On Diff #31305) | Can we update the comment? |
23–27 ↗ | (On Diff #31305) | I would prefer to keep the name as close as possible (e.g. someone sees that there is servicesToken sent and can search for services_token to find the "definition"). Actually this is going to be service-to-service (and so rust-to-rust) only right? We could probably remove the renames than... |
services/comm-services-lib/src/auth.rs | ||
---|---|---|
6–7 ↗ | (On Diff #31305) | Yes, good catch |
23–27 ↗ | (On Diff #31305) | Technically it doesn't matter but I find my way clean. Let me explain why:
{ "servicesToken": "foobar" } In this case, it's natural and definitely a better choice than { tokenValue: foo } which is ambiguous.
let services_auth_token: ServicesAuthToken = ...; // this looks obvious - we access raw value let raw = services_auth_token.token_value; // this is confusing - why we're extracting token from itself? let raw = services_auth_token.services_token; Perhaps we should rename ServicesAuthToken or AuthorizationCredentials structs too? |
services/comm-services-lib/src/auth.rs | ||
---|---|---|
6–7 ↗ | (On Diff #31305) | Was this addressed? |