🚀 Feature: Claim field override or custom per service mapping templating #96

New Issue

OVERLORD · 2025-10-07T00:01:28+03:00

OVERLORD commented

2025-10-07 00:01:28 +03:00

Originally created by @Ulrar on GitHub.

Feature description

Some basic templating support in the Custom Claims section of the user, to override fields such as email with something like $serviceName. There may be a better way of doing this, that's just the first thing that came to mind.

Pitch

I realize this is a bit of a niche use case, but I use a different email address per service. Currently PocketID just sends whatever it has as the user's email to the apps in the claim, which mean all of these apps are using the PocketID specific email address of my user, instead of their own.

But I'm sure there's other use cases for templated custom mapping fields.

Originally created by @Ulrar on GitHub. ### Feature description Some basic templating support in the Custom Claims section of the user, to override fields such as email with something like `$serviceName`. There may be a better way of doing this, that's just the first thing that came to mind. ### Pitch I realize this is a bit of a niche use case, but I use a different email address per service. Currently PocketID just sends whatever it has as the user's email to the apps in the claim, which mean all of these apps are using the PocketID specific email address of my user, instead of their own. But I'm sure there's other use cases for templated custom mapping fields.

OVERLORD added the needs more upvotes label 2025-10-07 00:01:28 +03:00

OVERLORD commented

2025-10-07 00:01:30 +03:00

@ItalyPaleAle commented on GitHub:

Indeed, having to maintain an API is the price you pay.

The benefits are that it's a lot more flexible (you can interact with external DBs, for example), and it doesn't require implementing a new DSL, which would result in a lot of things asked for the future.

An alternative I considered for #781 was suggesting the inclusion of a built-in engine, for example using wazero, but that comes with other complexities

@ItalyPaleAle commented on GitHub: Indeed, having to maintain an API is the price you pay. The benefits are that it's a lot more flexible (you can interact with external DBs, for example), and it doesn't require implementing a new DSL, which would result in a lot of things asked for the future. > An alternative I considered for #781 was suggesting the inclusion of a built-in engine, for example using [wazero](https://github.com/tetratelabs/wazero), but that comes with other complexities

OVERLORD commented

2025-10-07 00:01:31 +03:00

@Ulrar commented on GitHub:

@ItalyPaleAle there's already a way to add custom fields from the UI, but as far as I know it only takes plain text. I suppose fetching these from http may work but then I'd have to make and maintain an api for that, it's not ideal

@Ulrar commented on GitHub: @ItalyPaleAle there's already a way to add custom fields from the UI, but as far as I know it only takes plain text. I suppose fetching these from http may work but then I'd have to make and maintain an api for that, it's not ideal

OVERLORD commented

2025-10-07 00:01:31 +03:00

@ItalyPaleAle commented on GitHub:

Would #781 be a way for you to implement this?

@ItalyPaleAle commented on GitHub: Would #781 be a way for you to implement this?

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pocket-id#96