timdrysdale
commented
1 year ago pushing back on implementing sessions for a moment: it's tempting to consider implementing knowledge of sessions held by a user into the server itself, but it's effectively a minimal implementation of sharing, a concern typically handled by Oauth or GNAP, and perhaps better not to add features that will make migration to Ory or other identity management system difficult in future (i.e. by hardbaking considerations beyond the application logic in the server code). If tracking which anonymous ID uses which pre-booked session is important, then we can do that by comparing the times and equipment identity, with no further server code required(just access to the server logs).
A similar argument could be made against groups, except that we're effectively enabling permission discovery, and off the top of my head, it's not obvious how keto would facilitate this without doing a check against every known possible role. While it may be possible, it's outside the scope of work just now to figure that out, and it may be useful to have a "permission discovery" endpoint to offer a short list of things to check the user's actual permissions against. So, in short, it's not clear that groups do duplicate keto features, and it has immediate benefits to how we communicate with course organisers, so worth implementing groups.
1) Consider adding groups (of policies) to the manifest, and using them as the means of associating users with lists of equipment they can access.
Use case - groups can represent a fixed demand-side identity, e.g. public usage, class name + year, etc, that indirects to a list of policies that can change based on operational needs (i.e. supply-side fulfillment), without needing to change the publicly shared link that allows access to that group of policies. It's worked well for the old booking system, but is not currently included in the API. It was thought a list of policies could be shared out of band, or a single policy may satisfy a single use-case - but it probably stretches the idea of a policy too far to include different equipment in a single policy. It could be managed out of band, but this creates additional room for management error.
Proposal: rather than adding policies to a user, store groups instead. From the browser side, each new visit should begin by requesting the list of groups associated with the user (and or adding any groups in the url params of the link), then requesting policies contained within a group, then asking for those policies' details, then showing slots and allowing booking as appropriate.
This is a breaking change, and potentially better to do this while still developing the booking app.
2) sessions
for some classes we want to book one or two bits of kit at specific times and give them to individuals. One way to do this would be to create a meaningfully-named one-time user (with an short random unguessable salt like airport booking codes), and then share that user-name as a code. Internally all users would be treated the same, but we could track which sessions have ben assigned to users, so that they don't have to re-enter them after refreshing their cache. Does it offer any benefits? Yes, it lets us see which accounts got which session codes, which helps confirm which users are in particular studies.