Support multiple devise models

[bilouw]

Hi !

My Rails app use devise and doorkeeper. My app have 2 (in fact 3, but let begin with 2) devise model: User and Customer.

Doorkeeper by default handle only one devise model. By that, i mean that generators and example are based on use case with only one devise model.

With some controllers override, we can make doorkeeper handle multiples devise models.

Now, i have the same problem with this gem. I found a workaround (the same thing i did with doorkeeper), but i want to know if there is a legacy way to do that, or if an PR could be done to handle that.

Let me explain: When i want to access the /.well-known/openid-configuration url, the DiscoveryController try to build the json object with some hardcoded helpers:

Because i have two devise model (in two namespaces), these helpers methods does not exists for me.
What i did: Override the DiscoveryController in each of my namespaces, then override the provider_response methods to correct the helpers methods.

For now, that work !

But want to know if anybody have already handle this use case or if there is a best practice to handle this case.

Thanks !

[55728]

Hi @bilouw, thank you for the detailed write-up and for sharing your workaround.

As a collaborator: a quick clarification first — Doorkeeper itself isn't strictly tied to a single resource owner model. The resource_owner_authenticator block is model-agnostic, so a host app can dispatch to current_user || current_customer within a single Doorkeeper mount, and claims / userinfo / ID token generation flow naturally from whatever the block returns.

The actual sticking point in your case is narrower: DiscoveryController#provider_response calls named route helpers like oauth_authorization_url directly (source), which becomes ambiguous when the engine is mounted under multiple namespaces.

The existing discovery_url_options setting (added in #126) covers per-endpoint host / protocol overrides, but doesn't let you swap which named helper is invoked, so it doesn't fully cover the multi-mount case. Your per-namespace controller override is currently the most idiomatic way to handle this, and it's a supported extension pattern for Rails engines.

I'll follow up with a small README note describing this multi-namespace mount pattern and linking back to this issue, so others who hit the same situation can find your workaround.

@nbulaj — would you consider first-class multi-mount support in scope for this gem, or would you prefer to keep it as a documented extension pattern? Happy to follow whichever direction you take.