fixes CNVS-7452
User#active_pseudonyms will query on User#shard regardless of
Shard.current. But the value yielded to a partition_by_shard block is a
set of local_ids. So e.g. if visible_accounts included an account from
shard2 but @user is on shard1, we'd look for a pseudonym on shard1
belonging to both the user and an account on shard1 with the same local
id, rather than looking for a pseudonym on shard2 belonging to both the
user and the intended account.
the majority of the time, this bug would only cause the pseudonym to not
be found (in cooperation with another bug, this caused CNVS-7452). but
this could also provide unintended access, which is more severe. for
example:
* user1 and account1 are on shard1
* account2 is on shard2 but has the same local id as account1
* user1 has pseudonyms in both account1 and account2
* user2 has admin privileges in account2 but not account1
* user2 requests user1's authentication log
* user2 should get the events for the account2 pseudonym
* user2 gets the events for the account1 pseudonym instead
test-plan:
- setup user1, user2, account1, account2, and pseudonyms as in the
example above
- generate some authentication events for both pseudonyms
- user2 should get the events for the account2 pseudonym
- user2 should not get any events for the account1 pseudonym
Change-Id: Icc639d7a4b8217b77bd859629f983fbc1d30ccc0
Reviewed-on: https://gerrit.instructure.com/23204
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
when querying authentication events in the API, allow specifying
start_time and end_time. these are passed to the underlying event
stream.
fixes CNVS-6996
test-plan:
- create some authentication events (logging a user in and out)
- request the authentication events through the API
- choose an event in the middle and note its timestamp
- pass that timestamp as the start_time in the query string (ISO8601
formatted); only the newer portion of events should be returned,
including the selected event.
- pass that timestamp as the end_time in the query string (ISO8601
formatted); only the older portion of events should be returned,
including the selected event.
- try combining start_time and end_time where
* start_time < end_time (subset of events returned)
* start_time = end_time (only the event with matching timestamp
returned)
* start_time > end_time (no events returned)
Change-Id: I156ead6a535e08b17f44ed352cad7561ee246161
Reviewed-on: https://gerrit.instructure.com/22488
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes CNVS-390
stores and allows querying by user/account/pseudonym of login/logout
events.
test-plan:
[setup]
- set up an 'auditors' keyspace in cassandra and run migrations
- have shardX and shardY on one database server, and shardZ on a
different database server
- have accountW and accountX on shardX
- have accountY and accountZ on shardY and shardZ, respectively
- have userA on shardX with pseudonymAW in accountW and pseudonymAX in
accountX (cross-account, single-shard user)
- have userB on shardY with pseudonymBY in accountY and pseudonymBX in
accountX (cross-shard user)
- have userC on shardZ with pseudonymCZ in accountZ and pseudonymCX in
accountX (cross-db-server user)
- log in and out of each pseudonym above multiple times
[index isolation]
- /api/v1/audit/authentication/pseudonyms/<pseudonymAX> should
include logins and logouts from pseudonymAX only
- /api/v1/audit/authentication/accounts/<accountX> should include
logins and logouts from pseudonymAX, pseudonymBX, and pseudonymCX
but not pseudonymAW
- /api/v1/audit/authentication/users/<userA> should include logins
and logouts from both pseudonymAW and pseudonymAX but not
pseudonymBX or pseudonymCX
[permission isolation]
(in each of these, either :view_statistics or :manage_user_logins on
an account qualifies as "having permission")
- /api/v1/audit/authentication/pseudonyms/<pseudonymAX> should be
unauthorized if the current user doesn't have permission on
accountX
- /api/v1/audit/authentication/accounts/<accountX> should be
unauthorized if the current user doesn't have permission on
accountX
- /api/v1/audit/authentication/users/<userA> should be unauthorized
if the current user doesn't have permission on either of accountW
or accountX
- /api/v1/audit/authentication/users/<userA> should include logins
and logouts from accountW but not from accountX if the current
user has permission on accountW but not on accountX
[sharding]
- /api/v1/audit/authentication/users/<userB> should include logins
and logouts from both pseudonymBY and pseudonymBX
- /api/v1/audit/authentication/users/<userB> should not include
duplicate logins and logouts from either pseudonymBY and
pseudonymBX (potential for bug due to both pseudonyms' shards
being on the same database server)
- /api/v1/audit/authentication/users/<userC> should include logins
and logouts from both pseudonymCZ and pseudonymCX
Change-Id: I74b1573b346935f733fe5b07919d2d450cf07592
Reviewed-on: https://gerrit.instructure.com/21829
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
Jacob Fugal