Build the first GPS sensor/client (browser location API)

[untitaker]

Prerequisites

• I have read CONTRIBUTING.md

What problem does this feature solve or what does it enhance?

Based on #971.

We now should be able to use the browser's geolocation API to fill out GPS coordinates both for "static/fixed mode" and for continuously providing new location data. This would serve both as the first "official" data source for GPS and show others how to attach their own sensors.

Proposed Solution

The input fields for lat/long in the config UI would be extended by a "fill from browser location" button, and there should be some sort of mode where if one keeps the web interface open, it continuously grabs the user's location and feeds it back to the GPS API.

Alternatives Considered

We don't need to take any precaution as to whether the website/tab is suspended or not, we can just document that the user has to take care of that somehow. But maybe there is a way to package this as PWA or service worker that works better with Android power management.

An alternative is to extend https://codeberg.org/untitaker/rayhunter-companion or some other android app for sharing location, but that is rather platform-specific

[recanman]

The browser's geolocation API requires a secure context (i.e. HTTPS), so AFAIK, it wouldn't be usable without serving HTTPS.

[untitaker]

Good callout. there's probably ways around this. there was previously a proposal to add https to the web interface but we didn't quite know why we'd want that, now we would have a reason.

I think localhost is also considered a secure context, so maybe there are other escape hatches like this.

[recanman]

As long as the supported devices are capable enough (they should be), HTTPS with a self-signed cert sounds like a good idea.

I considered localhost, but that doesn't really work for users that connect to the device's WiFi hotspot to access it (e.g through 192.168.1.1:8080) such as myself.

[untitaker]

I think for the purpose of this ticket we should "just" get the frontend part out of the door under the assumption that secure context is not a problem. It would probably help if the UI showed a half-decent error message when there's no secure context.

Port forwarding would be the workaround for now (i.e. adb forward or running some sort of reverse proxy like socat on localhost), so it's still useful for people who know how to do that.

At a later point we can fix the secure context issue properly.