Redwood Stripe Integration

Terris · July 14, 2020, 4:13am

Here’s one way you could integrate Stripe with RedwoodJS.

peterp · July 14, 2020, 10:12am

Oooh, this is great, really love the example site too!

dthyresson · July 14, 2020, 11:23am

That was a fun code read through.

Do people like requirePermission over hasRole? I still prefer the idea of hasRole here since permissions (like edit:product often belong to role`.

github.com

Terris/redwood-stripe-example/blob/e15e52cc5c2e4edeb10e01d1615f37ed3d2529ea/api/src/lib/auth.js#L15


  return decoded
}

export const requireAuth = () => {
  const user = context.currentUser
  if (!user) {
    throw new AuthenticationError("You don't have permission to do that.")
  }
}

export const requirePermission = (role) => {
  const user = context.currentUser
  const permitted = user && user.app_metadata?.roles?.includes(role)
  if (!permitted) {
    throw new AuthenticationError("You don't have permission to do that.")
  }
}

Also a good example of db user/pwd auth + goTrue.

Terris · July 14, 2020, 2:11pm

Thanks. I definitely think you’re right that if I wanted to get more granular with permissions I’d want to use something like hasRole.

rob · July 14, 2020, 5:35pm

If your app has both roles and permissions you generally always want to be checking for permissions and not roles. This way you can shuffle permissions between roles, add new roles, etc, and the code never changes.

A great example is if you offer pricing tiers on your site. You’ve got Basic, Pro and Enterprise. As the app evolves and the featureset changes you may find that Basic users get more and more functionality that used to only belong to Pro. If you’re checking only roles then you’ll have to constantly be swapping out those checks…

if (hasRole('pro') || hasRole('basic'))

But permissions never have to change:

if (hasPermission('inviteUser'))

If you’re using permissions nothing changes—Basic users now have more permissions than they did yesterday. But no code changes! And if you give your Product Manager an admin screen that lets them change permissions on a role you’ll be their best friend for life!

At my last job we also added Role Limits—it determined how many of “something” a certain role could perform. For example, basic could perform only 10 searches a month, but Pro could perform an unlimited number. So we’d add a check like:

if (!hasPermission('search')) throw new AuthenticationError
if (!underLimit('search'))    throw new LimitError

// permission granted, proceed...

If your app only has roles then that’s all you can check anyway, so disregard the above suggestions.

Terris · July 14, 2020, 5:45pm

Ahhhh, aha! Bookmarking for later.

dthyresson · July 14, 2020, 5:53pm

More I think about it, permissions feel like the way to go.

A permission is tied to a feature or set of functionality that is exists in (or was maybe removed from) an “app”.

While “role” or “plan” can change based on Management, Marketing, or Org changes.

It’s not the “Trial” plan it’s “Free” and now not the “Basic” but “Bronze”. Oh and guess what now the “Bronze” role can rename widgets.

Or more current … it’s not the “Master” role, it’s now the “Admin” role.

Would be nice to avoid all the pain of managing “role” changes in code.

rob · July 14, 2020, 9:59pm

If you absolutely, positively need permissions right now I wrote up a quick thing in another thread for rolling your own until we come up with a Redwood Way to do it: Best practices for user permissions based on schema relationships

danny · July 14, 2020, 11:32pm

Nice one! We also implemented Braintree and Paddle checkouts (subscription based) - it was fairly straight forward but I did have to play around with lazy loading to make sure Braintree’s library didn’t get bundled into vendors.

I’m happy to do the write up if the community wants, but only if the demand is there!

(Cc @dom)

adriatic · June 14, 2022, 9:49pm

Does any element in this discussion changes because RedwoodJS is at v2.0-rc today?