Skip to content

Profile and Login Privacy

Profile is where each user controls what login data is collected about their own account. Login geolocation is no longer an Admin Guide concept: it is a per-user privacy preference.

What can I control from Profile?

Open Profile → Privacy.

Setting Default What it does
Login geolocation Off When off, BillTracker does not call ip-api.com for your logins and does not store city, region, country, or ISP for new login-history entries. When on, your login IP can be resolved to approximate location details for new-device login history.

The setting is saved to your user profile through PATCH /api/profile/settings. Changing it affects future login-history entries; it does not retroactively fill in old entries.

What happens when login geolocation is off?

When off:

  • No outbound ip-api.com request is made for your login.
  • Location fields for new login-history entries stay empty.
  • Your login history can still show normal security metadata such as time, success state, session/device indicators, IP, and user agent.
  • Existing location data from earlier enabled periods is not expanded or refreshed.

This is the recommended privacy-first default.

What happens when login geolocation is on?

When on:

  • BillTracker resolves your login IP through ip-api.com after a new-device login.
  • Approximate city, region, country, and ISP may appear in your login history.
  • Location fields are encrypted at rest before they are stored.
  • The data is shown only in your authenticated Profile view.

Approximate, not GPS

Login geolocation is based on the network IP address seen by the server. It is not device GPS and may point to an ISP, VPN, proxy, or nearby city.

What login-history data is encrypted?

BillTracker encrypts these user_login_history fields at rest:

  • ip_address
  • user_agent
  • location_city
  • location_country
  • location_region
  • location_isp

Decryption happens server-side for your Profile login-history view. The raw session token is not stored in the database; sessions use SHA-256(token).

How do I review my login history?

Open Profile → Login History.

The page shows recent login activity, including:

  • Time of login
  • Success or failure
  • Current-session marker
  • New-device/session detection
  • IP and user agent
  • Optional location details, if you enabled login geolocation

Use this view to spot unknown devices or unexpected access. If something looks wrong, change your password, remove unknown 2FA credentials, and ask an admin or operator to review server logs and backups.

How do I enable WebAuthn hardware-key 2FA?

Open Profile → Two-factor authentication and add a WebAuthn/FIDO2 security key.

The user-facing WebAuthn endpoints are:

Endpoint Purpose
GET /api/auth/webauthn/status Enabled flag and credential count
GET /api/auth/webauthn/credentials List registered keys
GET /api/auth/webauthn/setup Begin registration
POST /api/auth/webauthn/enable Complete registration
DELETE /api/auth/webauthn/credentials/:credentialId Remove one key
POST /api/auth/webauthn/disable Remove all keys after password confirmation

Operators still configure WEBAUTHN_RP_ID and WEBAUTHN_ORIGIN for the deployment domain. See Tune Security Settings and Environment Variables.

Why did everyone have to log in once after v0.37?

v0.37 changed sessions so sessions.id stores SHA-256(token) instead of the raw session token. Existing plaintext sessions were deleted during migration, so every user had to log in once after upgrade.

This is expected and improves the database-at-rest posture: the browser cookie keeps the raw token, while the database stores only the hash used for lookup.

What should operators still manage?

Users control their own login geolocation preference. Operators still manage:

  • HTTPS, proxy headers, cookie security, and HSTS
  • TOKEN_ENCRYPTION_KEY
  • WebAuthn RP ID and origin
  • Database and backup filesystem access
  • Rate-limit, import/export, backup, and admin-action policy

See Tune Security Settings and the Security model.

See also