v8.4.3

Author: Tobbe

__fixtures__/test-project/api/package.json

@@ -3,8 +3,8 @@
   "version": "0.0.0",
   "private": true,
   "dependencies": {
-    "@redwoodjs/api": "8.4.2",
-    "@redwoodjs/auth-dbauth-api": "8.4.2",
-    "@redwoodjs/graphql-server": "8.4.2"
+    "@redwoodjs/api": "8.4.3",
+    "@redwoodjs/auth-dbauth-api": "8.4.3",
+    "@redwoodjs/graphql-server": "8.4.3"
   }
 }

__fixtures__/test-project/package.json

@@ -7,8 +7,8 @@
     ]
   },
   "devDependencies": {
-    "@redwoodjs/core": "8.4.2",
-    "@redwoodjs/project-config": "8.4.2"
+    "@redwoodjs/core": "8.4.3",
+    "@redwoodjs/project-config": "8.4.3"
   },
   "eslintConfig": {
     "extends": "@redwoodjs/eslint-config",

__fixtures__/test-project/web/package.json

@@ -11,16 +11,16 @@
     ]
   },
   "dependencies": {
-    "@redwoodjs/auth-dbauth-web": "8.4.2",
-    "@redwoodjs/forms": "8.4.2",
-    "@redwoodjs/router": "8.4.2",
-    "@redwoodjs/web": "8.4.2",
+    "@redwoodjs/auth-dbauth-web": "8.4.3",
+    "@redwoodjs/forms": "8.4.3",
+    "@redwoodjs/router": "8.4.3",
+    "@redwoodjs/web": "8.4.3",
     "humanize-string": "2.1.0",
     "react": "18.3.1",
     "react-dom": "18.3.1"
   },
   "devDependencies": {
-    "@redwoodjs/vite": "8.4.2",
+    "@redwoodjs/vite": "8.4.3",
     "@types/react": "^18.2.55",
     "@types/react-dom": "^18.2.19",
     "autoprefixer": "^10.4.20",

docs/versioned_docs/version-8.4/auth/azure.md

@@ -107,11 +107,11 @@ To add roles exposed via the `roles` claim, follow [Add app roles to your applic
 ## `logIn` Options
 
 `options` in `logIn(options?)` is of type [RedirectRequest](https://azuread.github.io/microsoft-authentication-library-for-js/ref/types/_azure_msal_browser.RedirectRequest.html) and is a good place to pass in optional [scopes](https://docs.microsoft.com/en-us/graph/permissions-reference#user-permissions) to be authorized.
-By default, MSAL sets `scopes` to [/.default](https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#the-default-scope) which is built in for every application that refers to the static list of permissions configured on the application registration. Furthermore, MSAL will add `openid` and `profile` to all requests. In the example below we explicit include `User.Read.All` in the login scope.
+By default, MSAL sets `scopes` to [/.default](https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#the-default-scope) which is built in for every application that refers to the static list of permissions configured on the application registration. Furthermore, MSAL will add `openid`, `profile` and `offline_access` to all requests. In the example below we explicit include `User.Read.All` in the login scope.
 
 ```jsx
 await logIn({
-  scopes: ['User.Read.All'], // becomes ['openid', 'profile', 'User.Read.All']
+  scopes: ['User.Read.All'], // becomes ['openid', 'profile', 'offline_access', 'User.Read.All']
 })
 ```
 

docs/versioned_docs/version-8.4/auth/dbauth.md

@@ -314,16 +314,16 @@ By default no setting is required. This is because each db has its own rules for
 
 These options determine how the cookie that tracks whether the client is authorized is stored in the browser. The default configuration should work for most use cases. If you serve your web and api sides from different domains you'll need to make some changes: set `SameSite` to `None` and then add [CORS configuration](#cors-config).
 
-```js title="api/src/functions/auth.js"
+```javascript
 cookie: {
   attributes: {
     HttpOnly: true,
     Path: '/',
-    SameSite: 'Strict',
+    SameSite: 'Lax',
     Secure: true,
     // Domain: 'example.com',
   },
-  // name: 'session_%port%' 
+  // name: 'session_%port%',
 }
 ```
 
@@ -360,7 +360,7 @@ cookie: {
   attributes: {
     HttpOnly: true,
     Path: '/',
-    SameSite: 'Strict',
+    SameSite: 'Lax',
     Secure: process.env.NODE_ENV !== 'development' ? true : false,
     // highlight-next-line
     Domain: 'example.com'
@@ -564,9 +564,9 @@ export const handler = async (event, context) => {
       attributes: {
         HttpOnly: true,
         Path: '/',
-        SameSite: 'Strict',
+        SameSite: 'Lax',
         Secure: process.env.NODE_ENV !== 'development' ? true : false,
-      }
+      },
     },
 
     forgotPassword: forgotPasswordOptions,

docs/versioned_docs/version-8.4/cli-commands.md

@@ -2126,7 +2126,7 @@ Starts Storybook locally
 yarn redwood storybook
 ```
 
-[Storybook](https://storybook.js.org/docs/7/get-started/install) is a tool for UI development that allows you to develop your components in isolation, away from all the conflated cruft of your real app.
+[Storybook](https://storybook.js.org/docs/6/get-started/install) is a tool for UI development that allows you to develop your components in isolation, away from all the conflated cruft of your real app.
 
 > "Props in, views out! Make it simple to reason about."
 

docs/versioned_docs/version-8.4/cors.md

@@ -109,7 +109,7 @@ const authHandler = new DbAuthHandler(event, context, {
   cookie: {
     HttpOnly: true,
     Path: '/',
-    SameSite: 'Strict',
+    SameSite: 'Lax',
     Secure: true,
   },
   forgotPassword: forgotPasswordOptions,

docs/versioned_docs/version-8.4/how-to/custom-function.md

@@ -60,7 +60,13 @@ from the web side would give you an error like:
 Access to fetch at 'http://localhost:8911/serverTime' from origin 'http://localhost:8910' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
 ```
 
-We could set the headers for `serverTime` to allow requests from any origin... but maybe a better idea would be to never request `8911` from `8910` in the first place. Hence the `apiUrl`! We're making a request to `8910/.redwood/functions/serverTime`—still the same domain—but [Vite](https://github.com/redwoodjs/redwood/blob/main/packages/vite/src/index.ts#L119) proxies them to `localhost:8911/serverTime` for us.
+We could set the headers for `serverTime` to allow requests from any origin... but maybe a better idea would be to never request `8911` from `8910` in the first place. Hence the `apiUrl`! We're making a request to `8910/.redwood/functions/serverTime`—still the same domain—but [Vite](https://github.com/redwoodjs/redwood/blob/main/packages/vite/src/index.ts#L119) proxies them to `localhost:8911/serverTime` for us. Since we can access the `apiUrl` on the frontend via [environment variables](../environment-variables#accessing-api-urls), we can now change the above fetch to work in development as well as in production:
+
+```javascript
+const serverTime = await fetch(globalThis.RWJS_API_URL + '/serverTime')
+```
+
+> Note: If you want to use [Redwood Authentication](https://docs.redwoodjs.com/docs/serverless-functions/#serverless-functions-with-redwood-user-authentication) on your custom function, your fetch needs to send credentials in a cookie via `fetch(globalThis.RWJS_API_URL + '/serverTime', { credentials: 'include' })`. If you are using dbAuth you might need to add the [Domain](https://docs.redwoodjs.com/docs/auth/dbauth/#cookie-domain) property to your cookie configuration.
 
 ## Getting the Time
 

docs/versioned_docs/version-8.4/how-to/oauth.md

@@ -2,6 +2,10 @@
 
 If you're using an auth provider like [Auth0](/docs/auth/auth0), OAuth login to third party services (GitHub, Google, Facebook) is usually just a setting you can toggle on in your provider's dashboard. But if you're using [dbAuth](/docs/auth/dbauth) you'll only have username/password login to start. But, adding one or more OAuth clients isn't hard. This recipe will walk you through it from scratch, adding OAuth login via GitHub.
 
+Alternatively, consider using the [redwoodjs-dbauth-oauth](https://github.com/spoonjoy/redwoodjs-dbauth-oauth) community package. This package streamlines the setup, includes support for multiple providers, and even includes UI components that you can use for making setup even easier.
+
+If you do prefer to set this up manually or are just curious how OAuth and dbAuth can work together, read on!
+
 ## Prerequisites
 
 This article assumes you have an app set up and are using dbAuth. We're going to make use of the dbAuth system to validate that you're who you say you are. If you just want to try this code out in a sandbox app, you can create a test blog app from scratch by checking out the [Redwood codebase](https://github.com/redwoodjs/redwood) itself and then running a couple of commands:
@@ -636,7 +640,7 @@ const secureCookie = (user) => {
     `Expires=${expires.toUTCString()}`,
     'HttpOnly=true',
     'Path=/',
-    'SameSite=Strict',
+    'SameSite=Lax',
     `Secure=${process.env.NODE_ENV !== 'development'}`,
   ]
   const data = JSON.stringify({ id: user.id })
@@ -731,7 +735,7 @@ const secureCookie = (user) => {
     `Expires=${expires.toUTCString()}`,
     'HttpOnly=true',
     'Path=/',
-    'SameSite=Strict',
+    'SameSite=Lax',
     `Secure=${process.env.NODE_ENV !== 'development'}`,
   ]
   const data = JSON.stringify({ id: user.id })