[jake-low]

This PR is the very first step in a plan I've been developing along with the other maintainers to incrementally rewrite the MapRoulette backend.

There are several operational and maintainablity problems with the current backend codebase:

• Scala, the programming language it's written in, is fairly obscure and dissuades new contributors
• The codebase is huge (65k LOC) and hard to navigate. Crucial functions like authorization checks are scattered throughout every layer of the system, rather than centralized, and in a lot of cases there are several ways to do the same thing (resulting from incomplete past refactors). This makes any code change carry higher risk of causing an outage or opening a security hole.
• The API surface is similarly huge: over 300 endpoints, with inconsistent semantics, permission models, request and response schemas, and HTTP verbs. For example: there are at least four ways to trigger a challenge rebuild (requiring different permissions and going through distinct code paths), six endpoints which return a single challenge as JSON (in varying shapes), and around a dozen mutating GET endpoints.
• Recently we needed to disable API key authentication to fix a security issue. Our plan is to replace this with a new, more secure authentication mechanism, but doing so in the existing codebase would be an invasive and high risk change.

To address these problems, our current plan is this:

1. Add a new server component to the MapRoulette backend which is a separate codebase from the current Scala backend. The new component will serve a new version of the MapRoulette API under /api/v3/, which makes breaking changes in order to simplify the API surface and make the semantics more consistent. It will coexist with the current Scala codebase for a while, behind a reverse proxy that directs /api/v3/ requests to the new backend and /api/v2/ requests to the old one. Both backends use the same database schema and PostgreSQL server.
2. API v3 will support more granular authentication using personal access tokens, in order to restore access for third-party scripts and applications that was removed when we disabled API keys on API v2 (on October 7). We will focus initially on adding support for rebuilding challenges, since this has been the most requested feature in the weeks since.
3. Over time, we will move more functionality from API v2 to API v3, and update the maproulette.org frontend to use these new endpoints.
4. Eventually, once all required functionality is available in API v3, we can retire the Scala codebase that powers API v2.

The new server will be implemented in Rust. This PR is just the basic scaffolding. It's a web server using the axum framework and sqlx query library which just supports health check endpoints (the same liveness/readiness/status endpoints supported by API v2).

Next steps:

• add authentication using both MapRoulette API v2's session cookies as well as new personal access tokens (the latter of which can be scoped to specific capabilities)
• add endpoints to support rebuilding a challenge by uploading new tasks in newline-delimited GeoJSON format
• deploy this new service in production and configure the reverse proxy to route traffic to it
• add support for creating and managing Personal Access Tokens in the maproulette.org UI
• switch the UI over to use the new challenge rebuild API

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud