Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using for 3rd party tenants #464

Open
tyrw opened this issue Jul 10, 2020 · 3 comments
Open

Using for 3rd party tenants #464

tyrw opened this issue Jul 10, 2020 · 3 comments
Labels
support Questions, discussions, and general support

Comments

@tyrw
Copy link

tyrw commented Jul 10, 2020

Support plan

  • which support plan is this issue covered by?: Community
  • is this issue currently blocking your project?: yes
  • is this issue affecting a production system?: no

Context

  • node version: 12.18
  • module version: 19.1
  • environment (e.g. node, browser, native): node
  • used with (e.g. hapi application, another framework, standalone, ...): hapi application
  • any other relevant information: Tried with Twitter, but same for all

How can we help?

We would like to allow our users to build out social logins custom to their project. This means that, within each project and for each social provider, there would be a different clientId and clientSecret.

Example:
Project A, Twitter login:
clientId: aaaaaaaaaaaaaaaa
clientSecret: aaaaaaaaAAAAAAAAaaaaaaaAAAAAAA

Project B, Twitter login:
clientId: bbbbbbbbbbbbbbbb
clientSecret: bbbbbbbBBBBBBBBBbbbbbbbBBBBBBB

However the documented method is to configure for a single application for each provider and then register a route handler:

Registration

async function registerSocial() {
  await server.register(Bell)

  server.auth.strategy('twitter', 'bell', {
    provider: 'twitter',
    password: 'cookie_encryption_password_secure',
    clientId: 'aaaaaaaaaaaaaaaa',
    clientSecret: 'aaaaaaaaAAAAAAAAaaaaaaaAAAAAAA',
  })
}

Route handler

{
  method: ['GET', 'POST'],
  path: '/auth/twitter/login',
  handler: async (request, h) => {
    try {
      if (!request.auth.isAuthenticated) {
        return `Authentication failed due to: ${request.auth.error.message}`
      }

      // Perform any account lookup or registration, setup local session,
      // and redirect to the application. The third-party credentials are
      // stored in request.auth.credentials. Any query parameters from
      // the initial request are passed back via request.auth.credentials.query.

      return h.redirect('/')
    } catch (err) {
      return routeUtils.handleErr(err, h)
    }
  },
  config: {
    auth: {
      mode: 'try',
      strategy: 'twitter',
    },
  },
},

Is it possible to perform the Registration step in some other way? Potential solutions might include:

  • Register strategy generically, and pass in clientId / clientSecret another way
  • Register strategy with dummy clientId / clientSecret and change later in route handler
  • Look up clientId and clientSecret with a method in the options object of the registration, based on a project id in the URL
  • Look up clientId and clientSecret as a method in the config object of the route config, based on a project id in the URL

If this is supported, we would love a hint at the documentation. If it is not supported, we would love a nudge in the right direction for how we might implement this ourselves.

Thank you!

@tyrw tyrw added the support Questions, discussions, and general support label Jul 10, 2020
@tyrw
Copy link
Author

tyrw commented Jul 13, 2020

We have a working proof of concept for this, with an API like:

server.auth.strategy('twitter', 'bell', {
    provider: 'twitter',
    password: 'cookie_encryption_password_secure',
    clientFunction: async function (request, settings) {
        // Set clientId & clientSecret based on request info, e.g.
        // settings.clientId = 'aaaaaaaaaaaa'
        // settings.clientSecret = 'aaaaaaaAAAAAAAAaaaaaaaa'
    }
})

It does require some changes to how & where clientId and clientSecret are passed around.

Technically it's structured so that any of the settings could be looked up & assigned based on information in the request (not just clientId and clientSecret).

If we write up tests and documentation covering this use case, will you accept a PR for it, or do you consider this outside the scope of the normal use?

@tyrw
Copy link
Author

tyrw commented Aug 25, 2020

Is anyone monitoring the issues here?

@cjihrig
Copy link
Contributor

cjihrig commented Aug 26, 2020

Is anyone monitoring the issues here?

Yes. A new group of maintainers has taken over hapi recently, and we're still getting everything up and running. Sorry for any delay.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
support Questions, discussions, and general support
Projects
None yet
Development

No branches or pull requests

2 participants