github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-07-15 14:22:28 -05:00
Code Issues 690 Packages Projects Releases 11 Wiki Activity

EmailFallback only fallbacks to local user #668

New Issue
Open
opened 2025-11-01 21:01:28 -05:00 by GiteaMirror · 7 comments
GiteaMirror commented 2025-11-01 21:01:28 -05:00
Owner
Copy Link

Originally created by @maggch97 on GitHub (Oct 16, 2025).

Description

a5e2fbbe69/pkg/modules/auth/openid/openid.go (L285)

		// try finding the user on fallback mappingproperties

		searchUser := &user.User{
			Issuer: user.IssuerLocal,
		}

I'm not sure why here's this limitation. But for my use case, I switch to another oidc provider, EmailFallback does not work for my case.
For most website, it's normal that I can sign up with my Google account and then login with my Github account, if they have the same email address.
Could we remove the IssuerLocal limitation?

Vikunja Version

latest

Browser and version

No response

Can you reproduce the bug on the Vikunja demo site?

Please select

Screenshots

No response

Originally created by @maggch97 on GitHub (Oct 16, 2025). ### Description https://github.com/go-vikunja/vikunja/blob/a5e2fbbe6975275201a95c6fefe347798de90579/pkg/modules/auth/openid/openid.go#L285 ``` // try finding the user on fallback mappingproperties searchUser := &user.User{ Issuer: user.IssuerLocal, } ``` I'm not sure why here's this limitation. But for my use case, I switch to another oidc provider, EmailFallback does not work for my case. For most website, it's normal that I can sign up with my Google account and then login with my Github account, if they have the same email address. Could we remove the IssuerLocal limitation? ### Vikunja Version latest ### Browser and version _No response_ ### Can you reproduce the bug on the Vikunja demo site? Please select ### Screenshots _No response_
GiteaMirror commented 2025-11-01 21:01:29 -05:00
Author
Owner
Copy Link

@maggch97 commented on GitHub (Oct 16, 2025):

What I can think of is that the system does not require unique email address for oidc users. But I think it's not a good design that multiple users in this system can share a same email.

@maggch97 commented on GitHub (Oct 16, 2025): What I can think of is that the system does not require unique email address for oidc users. But I think it's not a good design that multiple users in this system can share a same email.
GiteaMirror commented 2025-11-01 21:01:29 -05:00
Author
Owner
Copy Link

@maggch97 commented on GitHub (Oct 16, 2025):

I can imagine some fixes:

  1. Just remove the IssuerLocal in query, self-host maintainer needs to configure carefully to avoid users with same email address
  2. When local auth is disabled, remove the IssuerLocal. Because in this case, local fallback has no effect.
  3. Add a new optional field, CrossOidcFallback
@maggch97 commented on GitHub (Oct 16, 2025): I can imagine some fixes: 1. Just remove the IssuerLocal in query, self-host maintainer needs to configure carefully to avoid users with same email address 2. When local auth is disabled, remove the IssuerLocal. Because in this case, local fallback has no effect. 3. Add a new optional field, CrossOidcFallback
GiteaMirror commented 2025-11-01 21:01:29 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Oct 19, 2025):

EmailFallback does not work for my case.

What does not work about it for you?

What I can think of is that the system does not require unique email address for oidc users

Since we don't control the email address, but the provider does, we don't have control over its uniqueness or anything really. That's why we don't use the email as an identifier for login.

@kolaente commented on GitHub (Oct 19, 2025): > EmailFallback does not work for my case. What does not work about it for you? > What I can think of is that the system does not require unique email address for oidc users Since we don't control the email address, but the provider does, we don't have control over its uniqueness or anything really. That's why we don't use the email as an identifier for login.
GiteaMirror commented 2025-11-01 21:01:29 -05:00
Author
Owner
Copy Link

@maggch97 commented on GitHub (Oct 20, 2025):

What does not work about it for you?

Migrate from A OIDC provider to B OIDC provider. A user has same email in different providers, but the issuer and subject are different.
Vikunja community also has a simillar feedback: https://community.vikunja.io/t/oidc-map-login-to-existing-user/2116/15

I have a PR for this https://github.com/go-vikunja/vikunja/issues/1672

@maggch97 commented on GitHub (Oct 20, 2025): > What does not work about it for you? Migrate from A OIDC provider to B OIDC provider. A user has same email in different providers, but the issuer and subject are different. Vikunja community also has a simillar feedback: https://community.vikunja.io/t/oidc-map-login-to-existing-user/2116/15 I have a PR for this https://github.com/go-vikunja/vikunja/issues/1672
GiteaMirror commented 2025-11-01 21:01:29 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Oct 21, 2025):

If you only want to migrate, I would prefer if this was a one-time cli command due to the security implications of allowing this.
It would adjust the issuer in the database or even better, just tell it "migrate this user from this provider to that provider as configured in the config" and it will just update it.

Then again, it might be fine as you proposed in the PR since it's configurable. How are other tools solving this?

@kolaente commented on GitHub (Oct 21, 2025): If you only want to migrate, I would prefer if this was a one-time cli command due to the security implications of allowing this. It would adjust the issuer in the database or even better, just tell it "migrate this user from this provider to that provider as configured in the config" and it will just update it. Then again, it might be fine as you proposed in the PR since it's configurable. How are other tools solving this?
GiteaMirror commented 2025-11-01 21:01:30 -05:00
Author
Owner
Copy Link

@maggch97 commented on GitHub (Oct 22, 2025):

I agree with you that a one time migration should fix my problem.

As what I know, headscale also had a similar discussion before https://github.com/juanfont/headscale/issues/1990. They used email before and finally choose to use iss+sub to identify a user, because some providers allow users to modify their username and email.

I'm fine with one time migration. Another scenario I’m considering is something like Cloudflare: I can sign in to the same account with either GitHub or Google as long as they share the same email. I didn't need this flow yet, but my understanding is that if the OIDC provider is trusted, then this flow should be secure. The key point is that the instance maintainer should ensure the provider is trusted, otherwise, without email fallback, the instance is still not secure.

Adding a new config option would increase both configuration and ongoing maintenance complexity. I’m planning to solve my issue with a one time migration. For the PR you can decide to merge or not, I'm ok with both.

@maggch97 commented on GitHub (Oct 22, 2025): I agree with you that a one time migration should fix my problem. As what I know, headscale also had a similar discussion before https://github.com/juanfont/headscale/issues/1990. They used email before and finally choose to use iss+sub to identify a user, because some providers allow users to modify their username and email. I'm fine with one time migration. Another scenario I’m considering is something like Cloudflare: I can sign in to the same account with either GitHub or Google as long as they share the same email. I didn't need this flow yet, but my understanding is that if the OIDC provider is trusted, then this flow should be secure. The key point is that the instance maintainer should ensure the provider is trusted, otherwise, without email fallback, the instance is still not secure. Adding a new config option would increase both configuration and ongoing maintenance complexity. I’m planning to solve my issue with a one time migration. For the PR you can decide to merge or not, I'm ok with both.
GiteaMirror commented 2025-11-01 21:01:30 -05:00
Author
Owner
Copy Link

@maggch97 commented on GitHub (Oct 22, 2025):

Migration with cli also needs some code change because issuer and subject are not supported to be updated with current cli. I will have a PR later.

@maggch97 commented on GitHub (Oct 22, 2025): Migration with cli also needs some code change because issuer and subject are not supported to be updated with current cli. I will have a PR later.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label
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/vikunja#668
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?