github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-23 07:18:56 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

Enrich sessions with geolocation #1958

New Issue
Closed
opened 2026-03-13 09:16:22 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-03-13 09:16:22 -05:00
Owner
Copy Link

Originally created by @issam-seghir on GitHub (Sep 18, 2025).

Is this suited for github?

  • 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.
  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). ### 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 enhancement label 2026-03-13 09:16:23 -05:00
GiteaMirror commented 2026-03-13 09:16:25 -05:00
Author
Owner
Copy Link

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

@dosubot what do you think about that ?

@issam-seghir commented on GitHub (Sep 18, 2025): @dosubot what do you think about that ?
GiteaMirror commented 2026-03-13 09:16:26 -05:00
Author
Owner
Copy Link

@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

@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)
GiteaMirror commented 2026-03-13 09:16:27 -05:00
Author
Owner
Copy Link

@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?

@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?
GiteaMirror commented 2026-03-13 09:16:28 -05:00
Author
Owner
Copy Link

@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.

@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.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#1958
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?