[GH-ISSUE #4743] Enrich sessions with geolocation #27367

Closed
opened 2026-04-17 18:21:26 -05:00 by GiteaMirror · 4 comments
Owner

Originally created by @issam-seghir on GitHub (Sep 18, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/4743

Is this suited for github?

  • Yes, this is suited for github

Summary

Add optional geolocation enrichment for "Session" records (derive country/city from "ipAddress" at session creation) and expose a minimal session view in the UI (last known location, user agent, ip, createdAt). This improves auditability, security signals (suspicious location changes) and admin troubleshooting without changing default privacy posture.


Motivation / problem

Currently "Session" contains "ipAddress" and "userAgent" but no derived location fields. Many users want to see a high-level location (country, city) for security auditing (e.g., detect impossible travel) and to present useful session metadata in admin consoles. Operators should be able to opt-in to geolocation enrichment; it must remain disabled by default and respect privacy/consent laws.

Example use-cases:

  • Detect sessions created from country A and then from country B in a short timeframe.
  • Allow users/admins to see approximate origin of sessions without exposing raw IPs to all users.
  • Improve incident investigations and abuse reports.

Describe the solution you'd like

Proposed solution

  1. Add optional, nullable fields to Session Prisma model: country, city, latitude, longitude, and maybe geoProvider/geoAt.
  2. Provide a configurable enrichment hook (server-side) that:
    • Resolves "ipAddress" to a location using a configurable provider (MaxMind, ip-api, ipinfo, or a custom URL).
    • Writes the resolved location into the session record at creation/update.
    • Is opt-in via configuration and provider config.
  3. Document privacy considerations and defaults (disabled by default, only store country/city, mask ip in UI by default).
  4. Add migration and tests.

Prisma schema suggestion

model Session {
  id           String   @id @default(cuid())
  userId       String
  user         User     @relation(fields: [userId], references: [id], onDelete: Cascade)
  sessionToken String   @unique
  expires      DateTime

  ipAddress    String?
  userAgent    String?

  // New optional geo fields (nullable)
  country      String?
  city         String?
  latitude     Float?
  longitude    Float?
  geoProvider  String?   // e.g. "maxmind", "ip-api", "custom"
  geoAt        DateTime? // when geo was resolved

  createdAt    DateTime @default(now()) @map(name: "created_at")
  updatedAt    DateTime @updatedAt @map("updated_at")

  @@index([userId])
  @@index([sessionToken])
  @@map(name: "sessions")
}

Describe alternatives you've considered

..

Additional context

No response

Originally created by @issam-seghir on GitHub (Sep 18, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/4743 ### Is this suited for github? - [x] Yes, this is suited for github ### Is your feature request related to a problem? Please describe. ### Summary Add optional geolocation enrichment for "Session" records (derive country/city from "ipAddress" at session creation) and expose a minimal session view in the UI (last known location, user agent, ip, createdAt). This improves auditability, security signals (suspicious location changes) and admin troubleshooting without changing default privacy posture. --- ### Motivation / problem Currently "Session" contains "ipAddress" and "userAgent" but no derived location fields. Many users want to see a high-level location (country, city) for security auditing (e.g., detect impossible travel) and to present useful session metadata in admin consoles. Operators should be able to opt-in to geolocation enrichment; it must remain disabled by default and respect privacy/consent laws. Example use-cases: - Detect sessions created from country A and then from country B in a short timeframe. - Allow users/admins to see approximate origin of sessions without exposing raw IPs to all users. - Improve incident investigations and abuse reports. --- ### Describe the solution you'd like ### Proposed solution 1. Add optional, nullable fields to `Session` Prisma model: `country`, `city`, `latitude`, `longitude`, and maybe `geoProvider`/`geoAt`. 2. Provide a configurable enrichment hook (server-side) that: - Resolves "ipAddress" to a location using a configurable provider (MaxMind, ip-api, ipinfo, or a custom URL). - Writes the resolved location into the session record at creation/update. - Is opt-in via configuration and provider config. 4. Document privacy considerations and defaults (disabled by default, only store country/city, mask ip in UI by default). 5. Add migration and tests. --- ### Prisma schema suggestion ```prisma model Session { id String @id @default(cuid()) userId String user User @relation(fields: [userId], references: [id], onDelete: Cascade) sessionToken String @unique expires DateTime ipAddress String? userAgent String? // New optional geo fields (nullable) country String? city String? latitude Float? longitude Float? geoProvider String? // e.g. "maxmind", "ip-api", "custom" geoAt DateTime? // when geo was resolved createdAt DateTime @default(now()) @map(name: "created_at") updatedAt DateTime @updatedAt @map("updated_at") @@index([userId]) @@index([sessionToken]) @@map(name: "sessions") } ``` ### Describe alternatives you've considered .. ### Additional context _No response_
GiteaMirror added the lockedenhancement labels 2026-04-17 18:21:26 -05:00
Author
Owner

@issam-seghir commented on GitHub (Sep 18, 2025):

@dosubot what do you think about that ?

<!-- gh-comment-id:3306898198 --> @issam-seghir commented on GitHub (Sep 18, 2025): @dosubot what do you think about that ?
Author
Owner

@dosubot[bot] commented on GitHub (Sep 18, 2025):

This proposal fits really well with Better Auth’s architecture. The session model is designed to be extensible—adding optional geolocation fields (country, city, latitude, longitude, geoProvider, geoAt) is straightforward using additionalFields in the session config, and migrations will handle schema updates automatically.

Enrichment hooks for session creation/update are already supported via databaseHooks, so you can resolve IP addresses to location data server-side and populate those fields as sessions are created or updated. This approach is also used by others for similar use-cases, like attaching geoip-lite location info to sessions via hooks or plugins (example). Privacy and opt-in configuration are handled at the application layer, so you can keep enrichment disabled by default and mask sensitive data in the UI.

The only open questions are around UI integration (how/where to show location info), preferred geolocation providers, and privacy policy alignment, but technically everything you described is feasible and aligns with current patterns in Better Auth (docs, hooks). If you want to move forward, you can prototype with a before-create hook and custom fields, then iterate on provider selection and UI.

To reply, just mention @dosu.


How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

<!-- gh-comment-id:3306909764 --> @dosubot[bot] commented on GitHub (Sep 18, 2025): <!-- Answer --> This proposal fits really well with Better Auth’s architecture. The session model is designed to be extensible—adding optional geolocation fields (country, city, latitude, longitude, geoProvider, geoAt) is straightforward using `additionalFields` in the session config, and migrations will handle schema updates automatically. Enrichment hooks for session creation/update are already supported via `databaseHooks`, so you can resolve IP addresses to location data server-side and populate those fields as sessions are created or updated. This approach is also used by others for similar use-cases, like attaching geoip-lite location info to sessions via hooks or plugins ([example](https://github.com/better-auth/better-auth/issues/821)). Privacy and opt-in configuration are handled at the application layer, so you can keep enrichment disabled by default and mask sensitive data in the UI. The only open questions are around UI integration (how/where to show location info), preferred geolocation providers, and privacy policy alignment, but technically everything you described is feasible and aligns with current patterns in Better Auth ([docs](https://github.com/better-auth/better-auth/blob/d1fe10962079c82920ea078a9847f65a59907b81/docs/content/docs/reference/options.mdx), [hooks](https://github.com/better-auth/better-auth/blob/d1fe10962079c82920ea078a9847f65a59907b81/docs/content/docs/concepts/database.mdx)). If you want to move forward, you can prototype with a before-create hook and custom fields, then iterate on provider selection and UI. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/61854e79-dee4-4d34-85bc-9ceaf281bd08?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/61854e79-dee4-4d34-85bc-9ceaf281bd08?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/61854e79-dee4-4d34-85bc-9ceaf281bd08?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/61854e79-dee4-4d34-85bc-9ceaf281bd08?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/61854e79-dee4-4d34-85bc-9ceaf281bd08?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/61854e79-dee4-4d34-85bc-9ceaf281bd08?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/61854e79-dee4-4d34-85bc-9ceaf281bd08?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/4743)
Author
Owner

@issam-seghir commented on GitHub (Sep 18, 2025):

@docusbot ok give me your suggested custom solution bcz this feature isn't implemented for the moment
And which package do you suggest for extracting the address from an IP address?

<!-- gh-comment-id:3306946542 --> @issam-seghir commented on GitHub (Sep 18, 2025): @docusbot ok give me your suggested custom solution bcz this feature isn't implemented for the moment And which package do you suggest for extracting the address from an IP address?
Author
Owner

@Kinfe123 commented on GitHub (Sep 18, 2025):

you can use third party services like https://ipinfo.io/ for resolving the ip address and save it to your db and but this will something that we also offer as a part of the infra when released.

<!-- gh-comment-id:3309482720 --> @Kinfe123 commented on GitHub (Sep 18, 2025): you can use third party services like https://ipinfo.io/ for resolving the ip address and save it to your db and but this will something that we also offer as a part of the infra when released.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#27367