Public Roadmap for RedwoodJS Bighorn Epoch

Announcements
1

Public Roadmap

This roadmap is related to Tom’s announcement about Redwood’s next epoch. You can read more about that in his announcement blog post.

The Core Team is committed to being more transparent about the roadmap and status as we head into the new Bighorn epoch. Additionally, there are going to be many opportunities, and invitations, for community collaboration.

redwoodjs.com/roadmap

Initiatives > Projects

This epoch has six core initiatives, each with associated projects:

  1. RSC + SSR: all in on react server components
  2. Deploy: unlock deploy + add first class for many more providers
  3. Startups at Scale: grow with the startups using Redwood
  4. Full-stack Table Stakes: add “missing” self-hosted features
  5. Getting Started UX: deliver on our promises to new devs as they onboard
  6. Fundamentals: low level work that’s critical for other features

Roadmap Project on Notion

We’re excited to publish the initial public roadmap, which will update in real-time as each project is implemented. There’s a lot on this Notion doc that is still in “draft” form — we’ll keep refining and clarifying as we go.

Link to RedwoodJS Public Roadmap on Notion👇

9 Likes
3

this all looks amazing!!! so excited for this next era of Redwood and so stoked to be part of this community

4 Likes
4

I also can’t wait to see how this looks! Very exciting!

1 Like
5

@thedavid something I don’t see mentioned on the roadmap is bringing OAuth support to dbAuth, do you know if there are any initiatives around this? I know some folks have done PoCs around this.

I’m considering looking into what this entails and taking it on, because I find that only supporting email/pass as login is a pretty big hurdle for user adoption of products using dbAuth.

Thanks!

cc @danny @rob @dthyresson in case one of you have any insight on this

2 Likes
6

Correct, it’s not on the roadmap, meaning it’s not a focus or priority for the Core Team. Since v4 and the improved Redwood Auth architecture and API, we’ve changed the process for Auth development from “framework-first” (i.e. implementation within the framework packages) to being “custom-first” (i.e. via custom implementation “how to” guides, let the community create the Auth integrations they need). If you’re up for leading a community effort, I think you have all the pieces here to put something together. The process could look like:

  1. post a public RFC
  2. build a custom implementation including documentation (as you know, the best example of this is the work by @pi0neerpat, who effectively created a dbAuth + OAuth implementation)
  3. iterate on the above
  4. given momentum + adoption, work with the Core Team to discuss/determine adding to the framework directly

To be clear, I can’t guarantee the amount of Core Team support or if this will end up in the framework. I can guarantee we’ll do our best to enable you to lead the way and take a shot at this :rocket:

1 Like
7

Got it! Working now on a PoC and then will work on the RFC etc as you mentioned :slight_smile:

1 Like
8

I could have sworn there was a GitHub issue for this and lots of back and forth but I can’t find it now…maybe it was on the forums?

I’ve always felt like OAuth should be some kind of addon/plugin that’s maintained outside of the Redwood codebase proper, especially now that we’ve moved our login logic to separate packages and out of the core framework.

Here’s an implementation I came up with for a recent project. It involves adding a single oauth.js function to api/src/functions, a new Prisma model Identity, and some .env vars.

Here’s the flow:

  1. User clicks a “Login with GitHub” button
  2. Browser is sent to github.com’s oauth authentication endpoint, https://github.com/login/oauth/authorize and sets a bunch of query variables, including a redirect which is the URL to the new oauth.js function
  3. GitHub verifies credentials and then directs back to oauth.js
  4. oauth.js fetches the access_token from GitHub
  5. oauth.js looks up a user in the Identity table based on the uid from GitHub.
  6. A local User and Identity are created, if they don’t exist, with data from their GitHub user
  7. oauth.js sets the same session cookie they would have got if they went through the standard dbAuth flow (this is key to the simplicity of this implementation)
  8. oauth.js redirects to the main site

So everything is self-contained in a single function—it doesn’t require any changes to dbAuth proper. When the client needs to verify that the user is still logged in, that happens through the regular dbAuth flow, and since the cookie is identical, everything just works. And, dbAuth itself is still available for login duties, so you can have both email/password and OAuth login in the app.

That implementation only supports GitHub right now, but it could pretty easily be extended to support any OAuth provider without too much work, since once you have the access_token (which entails just a single fetch to the host provider) everything is local to your own app and database.

Update In the vein of @thedavid’s post above, I’m going to turn this implementation into a Cookbook article and put it on the docs site!

3 Likes
9

Not sure how I missed your response, that looks awesome and gives me lots of ideas!

I do think it should be more baked into dbAuth, though, especially because it’s not really general purpose and rewrites a bunch of dbAuth functionality - it would be useful for maintainability to be able to access those directly. I’m specifically thinking that the oAuth integration could mirror the structure of the Webauthn integration.

On the same line, I was thinking the dbAuth “client” parameter, which is currently just used for Webauthn, could be used to expose further functionality such as this - what’s your take on that? It always felt kind of weird to me that we have this param to expose auth implementation specific items but designed its usage to only work for this one item.

Even if not, I would love to see this become an official Redwood plug-in to make it more accessible.

Let me know what you think!

EDIT: actually, I have an idea on how to reuse the dbAuth stuff while include this as a custom auth provider by just passing the authHandler into the oAuthHandler in the redwood project’s auth function. Starting to understand more about how the framework is structured as I stumble through it :slight_smile:

EDIT: @rob your cookbook looks great! I’m leveraging it in my reusable solution, which I think you’re gunna like :slight_smile: It’s coming along nicely, just wrapping things up, then need to write up usage docs and publish it to NPM, at which point I’ll make a new post in this community and the discord. At launch, it’ll integrate into any RW app very much the same way that dbAuth is integrated, be extremely easy to configure, and allow for Google, Apple, and GitHub. It supports signup, login, and linking to as many providers as a user wants.

It’ll also be providing components with signup/login/link buttons so that a user can onboard the library in <10 minutes.

One minor nit re your cookbook: you’re using status code 302 to handle your redirects from the API side back to the Web side, but I feel 303 is more idiomatically correct. Although I believe browsers generally treat these the same, so it doesn’t really matter.

EDIT: Just released the OAuth plugin! 🎉 Announcing dbAuth OAuth Plugin v1.0.0 - easily enable Sign in with Apple, GitHub, Google, and more!

10

regarding Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.

I defer doesn’t seem to allow self-hosting?

11

That was my first question! Consider that research notes. Could be a great integration but, you’re correct, wouldn’t meet the self-hosted requirement.

1 Like
12

How do we interact with this or give feedback just comment?

13

Comment here is perfect!