feat(statusline): honor user-configured location over IP geolocation (#843)#1309
Open
rpriven wants to merge 1 commit into
Open
feat(statusline): honor user-configured location over IP geolocation (#843)#1309rpriven wants to merge 1 commit into
rpriven wants to merge 1 commit into
Conversation
…anielmiessler#843) The statusline determined location/weather purely via ip-api.com IP geolocation, returning the wrong city for VPN/proxy/corporate-network users whose exit node differs from their actual location — and falling back to hardcoded San Francisco coords. settings.json already has a `.location` object (city/regionName/lat/lon) but the statusline ignored it. This makes settings.json `.location` authoritative when present: - Location display uses the configured city/region - Weather uses the configured lat/lon - Optional `.location.countryCode` drives the flag emoji (falls back to 🌐) - ip-api.com is skipped entirely when location is configured (correctness for VPN users + one fewer third-party request exposing the user's IP) - IP geolocation remains the fallback for unconfigured users The `.location.*` reads are guarded with `?` so a malformed user-edited location can't break the rest of the settings cache. Tested end-to-end on Debian 13 / PAI v5.0.0: configured (with + without countryCode), unconfigured ip-api fallback, partial (city-only → weather falls back gracefully), and malformed-location paths.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The statusline determines location and weather purely via
ip-api.comIP geolocation, which returns the wrong city for users behind a VPN, proxy, or corporate network whose exit node is in a different city — then falls back to hardcoded San Francisco coordinates.settings.jsonalready has a.locationobject (city,regionName,lat,lon) but the statusline ignores it for both display and weather.Fix
Make
settings.json.locationauthoritative when present:city/regionNamelat/lon.location.countryCodedrives the flag emoji (falls back to 🌐 when unset)ip-api.comis skipped entirely when location is configured — correct for VPN/proxy users, and one fewer third-party request exposing the user's IPThe
.location.*reads are?-guarded so a malformed user-edited.location(e.g. a string instead of an object) can't break the rest of the settings cache.Testing
Tested end-to-end on Debian 13 / PAI v5.0.0:
countryCode→ shows configured city + flag, skips ip-apicountryCode→ shows city + 🌐 fallback, skips ip-apicountryCodepopulated from ip-api)cityonly, no coords) → city displays, weather falls back gracefully (no crash).location→ guarded;TEMP_UNIT/ counts / rest of settings cache intactCloses #843. Thanks to @DAESA24 for the original analysis and workaround.