API: Applications open and close (GET /v1/applications/enabled)

[anishalle]

Summary

Implement BOTH a hacker endpoint (/v1/applications/enabled) and a SUPERADMIN endpoint (POST /v1/superadmin/applications/enabled) to allow superadmins to enable and disable applications.

Endpoint

GET /v1/applications/enabled AND POST /v1/superadmin/applications/enabled

GET /v1/applications/enabled:
Auth: Requires hacker role (we can explore making this public, but nobody needs it except hackers)

POST /v1/superadmin/applications/enabled
Auth: Requires super_admin role (behind RequireRoleMiddleware(store.RoleSuperAdmin))

Request Payload

POST with superadmin

{
"enabled": true
}

Storing in DB

(this is to be debated) --> Create a new table called application_info that will store global data about enabled, or maybe enabled_time to allow for auto disabling applications after a certain time instead of making it manual, or any other related info about the application process itself instead of just having the new table for one field only.

Validation

• POST requires a field "enabled", and must be SUPERADMIN
• GET requires nothing, just that it is locked behind hacker.

Response

Both of the endpoints will return the same payload, with the SUPERADMIN POST returning the updated enabled value after the post.
200 OK

{
"enabled": true
}

400 Bad Request — invalid payload, no "enabled" field during POST
403 Forbidden — caller is not a super admin if posting, caller is not hacker if doing GET.

Handler logic

1. Parse and validate request body
2. Update database with new enabled value
3. Return new enabled value

Labels

enhancement

[anishalle]

@balebbae what are we thinking

[balebbae]

Yeah I like it very straight forward. Store the enabled in the settings table. And we can just do a get to confirm enabled when the hacker clicks Go To Application. And def not public endpoint, at least for now. We will in the future set up a public API for like hackathon schedules, sponsors, etc.