refactor(sso): update trusted origins handling and introduce license …

[Siumauricio]

What is this PR about?

Please describe in a short paragraph what this PR is about.

Checklist

Before submitting this PR, please make sure that:

• You created a dedicated branch based on the canary branch.
• You have read the suggestions in the CONTRIBUTING.md file https://github.com/Dokploy/dokploy/blob/canary/CONTRIBUTING.md#pull-request
• You have tested this PR in your local instance. If you have not tested it yet, please do so before submitting. This helps avoid wasting maintainers' time reviewing code that has not been verified by you.

Issues related (if applicable)

Screenshots (if applicable)

Greptile Summary

This PR refactors SSO trusted origins handling and enterprise license validation to be organization-aware rather than user-specific. The key changes are:

• License validation is now organization-based: enterpriseProcedure and haveValidLicenseKey now look up the organization owner's license status instead of checking the calling user's ctx.user properties. A new hasValidLicense() service function encapsulates this logic.
• Trusted origins operate on the organization owner: All trusted origin CRUD operations (add, remove, update, getTrustedOrigins) now resolve the organization owner and read/write their trustedOrigins field, instead of using ctx.session.userId.
• Frontend updated: The SSO settings component now queries api.sso.getTrustedOrigins (a new dedicated endpoint) instead of fetching trusted origins from api.user.get.
• Login callback URL added: callbackURL: "/dashboard/projects" was added to the email sign-in call.

Issues found:

• Bug: The new user.getTrustedOrigins endpoint in user.ts is broken — it queries members without with: { user: true }, so it always returns []. It also doesn't filter by user. This endpoint appears to be dead code after the frontend refactoring but should be removed or fixed.
• Performance: enterpriseProcedure now makes 2 DB queries (organization + user lookup) on every request, where it previously used pre-loaded context properties.
• Code duplication: hasValidLicense and getOrganizationOwnerId both implement the same organization owner lookup.

Confidence Score: 3/5

• This PR has a confirmed bug in the new user.getTrustedOrigins endpoint (always returns []), though it appears unused after the frontend refactoring. Core SSO refactoring is sound.
• Score of 3 reflects that the main refactoring (organization-based license validation and trusted origins) is logically correct, but there is a confirmed broken endpoint in user.ts (missing Drizzle relation loading), and a performance regression in enterpriseProcedure adding 2 DB queries per request. The broken endpoint appears to be dead code post-refactoring, which prevents a lower score.
• Pay close attention to apps/dokploy/server/api/routers/user.ts (broken getTrustedOrigins endpoint) and apps/dokploy/server/api/trpc.ts (performance regression in enterpriseProcedure middleware).

_{Last reviewed commit: 4e8d37b}

[greptile-apps]

_{9 files reviewed, 3 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Two additional DB queries on every enterprise procedure call

hasValidLicense() performs two DB queries (organization lookup + user lookup) and is now called in the middleware for every enterpriseProcedure request. Previously, this check used ctx.user properties that were already loaded during context creation.

This means every SSO operation (list providers, get trusted origins, add/remove/update origins, register/update/delete providers) now incurs two extra DB round-trips. Consider caching the license validation result on the context during createTRPCContext or using a short-lived in-memory cache to avoid redundant lookups on every request.

[greptile-apps]

Additional Comments (1)

apps/dokploy/server/api/routers/user.ts
Query missing with: { user: true } — always returns []

This query does not include with: { user: true }, so memberResult will only contain member table columns. memberResult?.user will be undefined, and memberResult?.user?.trustedOrigins ?? [] will always evaluate to [].

Additionally, the where clause only filters by organizationId without filtering by a specific user, so it would return an arbitrary member of the organization even if the relation were loaded.

This endpoint appears unused after this PR (the frontend was refactored to use api.sso.getTrustedOrigins instead), so consider removing it to avoid confusion. If it's intended to be kept, it needs to be fixed:

	getTrustedOrigins: protectedProcedure.query(async ({ ctx }) => {
		const memberResult = await db.query.member.findFirst({
			where: and(
				eq(member.userId, ctx.user.id),
				eq(member.organizationId, ctx.session?.activeOrganizationId || ""),
			),
			with: {
				user: {
					columns: { trustedOrigins: true },
				},
			},
		});
		return memberResult?.user?.trustedOrigins ?? [];
	}),