Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: API for room occupancy #307

Open
pobv opened this issue Jan 21, 2022 · 3 comments
Open

Feature Request: API for room occupancy #307

pobv opened this issue Jan 21, 2022 · 3 comments
Labels
back end enhancement New feature or request

Comments

@pobv
Copy link

pobv commented Jan 21, 2022

It would be very nice to be able to retrieve the current room occupancy for a given room via either polling (REST request) or active notification on change (WebSocket or MQTT or similar). As the check-in system is now consistently used, works reliably and data is widely available, a display visible for all users "how many are currently logged in" has this "give something back" feeling and might be motivating (and is fun to build). For that, an API reporting room occupancy of a room (if necessary either authenticated or restricted by other means) would be very welcome.

@MorMundHS-MA MorMundHS-MA added back end enhancement New feature or request labels Jan 21, 2022
@MorMundHS-MA
Copy link
Collaborator

I don't think providing notifications through web sockets is feasible for this, since we would have to poll the database on the server-side anyway or make quite significant architectural changes. But a REST endpoint is doable and mostly straight forward.

However I think we should not allow unauthenticated access to this endpoint as public access to this, even if it is read-only. Since we have already ruled out the university's single-sign-on system as an authentication method for the regular login, I don't think it will be useful here either.
The other options I see are:

  • A fixed token passed as environment variable. This does limit the endpoints usefulness significantly as it will be only reasonable accessible for a single use-case.
  • A public key which can verify generated tokens i.e. something like JWT. This allows the administrators to sign as many tokens as necessary, but requires much more implementation and documentation effort, as well as manual management of the tokens.
  • Limiting API access to university IPs. This is easy to implement, but may not translate well to the use-cases other users of this open source project may have.
  • Using the existing login system. This would require the client to authenticate with a username/password and manage the session cookie. It should be as secure as the other options but would require much more documentation for client implementations compared to token-based approaches.

@pobv
Copy link
Author

pobv commented Jan 22, 2022

Thanks, fixed token and restrict to university IPs would be absolutely fine for me. If that is doable, great - thanks in advance.

@Wifi-cable
Copy link
Collaborator

The team is discussing various solutions. The aspects of usability, service and data protection matter to us.Technical solutions often have social implications. We have to ensure that any form of API to is GDPR or DSGVO conform.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
back end enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants