# 【编程技术】你还在手写各种第三方授权登录吗？来学学NuxtAuth吧（基于Nuxt3）

在如今的互联网应用中，用户身份验证几乎是每个项目不可或缺的一部分。尤其是当应用需要整合外部服务时，第三方授权登录成为了一种常见的做法。然而，很多开发者仍然手动实现各种第三方登录功能，既费时又容易出错。为了简化这个过程，`@sidebase/nuxt-auth` 提供了一个强大且易于集成的解决方案，让你无需再手动编写每个服务的授权代码。

本文将带你了解为什么你应该使用 `@sidebase/nuxt-auth`，如何通过它实现第三方授权登录，并探讨它的优点。



## 为什么使用第三方授权登录？

### 1. 提升用户体验

通过集成第三方登录（如 `Google`、`GitHub` 等），用户无需记住和输入复杂的密码，只需要通过已有的账户即可快速登录。这种方式显著降低了登录的门槛，提升了用户体验。

### 2. 提高安全性

自定义密码存储和管理需要承担较高的安全责任。通过第三方登录，尤其是 `OAuth` 授权协议，应用可以将认证责任交给专业的第三方提供商，减少安全漏洞的风险。

### 3. 加速开发进程

实现一个完备的用户身份验证系统通常需要不少时间和精力，尤其是要兼容多个第三方服务。而使用 `@sidebase/nuxt-auth`，你可以通过简单的配置快速集成多个第三方登录，节省了大量开发工作。

## 常见的第三方授权服务

1. **Google 登录**：最常见的第三方登录服务之一，支持 OAuth 2.0 认证机制。
2. **GitHub 登录**：常用于开发者社区，允许用户通过其 GitHub 账户登录。
3. **Twitter 登录**：为社交媒体应用提供便捷的认证方式。
4. **Azure 登录**：微软的身份验证服务，常用于企业级应用。
5. **自定义 OAuth 登录**：如果你有自己的身份认证服务，也可以实现自定义 OAuth 登录。

这些第三方服务的集成，通常涉及 OAuth 认证流程、API 密钥配置、回调地址处理等多个步骤。

## @sidebase/nuxt-auth 的作用

`@sidebase/nuxt-auth` 是一个为 `Nuxt 3` 框架设计的身份验证模块，它封装了流行的 **NextAuth.js** 库，将其引入到 Nuxt 生态中。通过它，你可以快速集成 `OAuth` 提供商，如 `Google`、`GitHub`、`Twitter `等，同时它还支持自定义 `OAuth` 和基于凭证的登录方式。

### 常见的集成方式包括：

- **OAuth 登录**：集成 `GitHub`、`Google`、`Twitter` 等 `OAuth` 提供商，支持快速的身份验证。
- **凭证登录**：通过用户名和密码进行认证，适用于传统的身份验证需求。
- **电子邮件魔法链接**：通过发送邮件链接进行身份验证，适用于不希望使用密码的应用。

此外，`@sidebase/nuxt-auth` 还提供了诸如会话管理、刷新令牌、保护页面等功能，极大简化了身份验证的实现。

## @sidebase/nuxt-auth 功能的实现方式

`@sidebase/nuxt-auth` 基于 **NextAuth.js** 封装而成，利用其强大的 `OAuth` 支持以及会话管理能力。它通过以下方式实现了第三方授权功能：

1. **OAuth 支持**：集成多个常见的 `OAuth` 提供商（如 `Google`、`GitHub`、`Twitter`），只需配置几个参数即可完成集成。
2. **自定义 OAuth**：如果内置的 `OAuth` 提供商不符合需求，可以自定义 OAuth 提供商，灵活满足个性化需求。
3. **会话管理**：通过 `useAuth` API，可以在应用中获取和管理用户会话，支持获取 `session`、刷新令牌等操作。
4. **保护页面**：提供页面级别的保护功能，可以轻松配置哪些页面需要登录才能访问，避免未经授权的用户访问敏感信息。

### 示例配置

通过简单的配置，你可以在 `Nuxt 3` 应用中快速集成第三方登录。例如，在 `nuxt.config.ts` 中配置：

```ts
export default defineNuxtConfig({
  modules: ['@sidebase/nuxt-auth']
})
```

然后，按需配置 `OAuth` 提供商，如 `Google` 和 `GitHub`：

```ts
export default defineNuxtConfig({
  auth: {
    providers: {
      google: {
        clientId: 'your-google-client-id',
        clientSecret: 'your-google-client-secret',
      },
      github: {
        clientId: 'your-github-client-id',
        clientSecret: 'your-github-client-secret',
      },
    }
  }
})
```

这样一来，你就能在应用中快速实现 Google 和 GitHub 登录。

## 为什么选择 @sidebase/nuxt-auth？

1. **快速集成**

`@sidebase/nuxt-auth` 可以让你几分钟内集成多个第三方登录服务，省去手动实现 `OAuth` 认证流程的麻烦。

2. **强大的社区支持**

作为基于 **NextAuth.js** 的封装，`@sidebase/nuxt-auth` 拥有稳定的社区支持和大量的文档资源，使得开发者可以轻松找到解决方案。

3. **灵活的配置与扩展性**

除了提供默认的第三方认证外，它还支持自定义 `OAuth` 提供商和凭证登录等多种认证方式，适应不同的业务需求。

4. **会话与安全性管理**

内置的会话管理功能使得你无需额外编写复杂的会话逻辑，同时提供了完善的安全性措施，确保用户数据安全。

## 什么时候建议使用 @sidebase/nuxt-auth？

- **快速开发和原型设计**：如果你需要快速开发一个应用，并且希望在最短时间内集成多个第三方认证方式，`@sidebase/nuxt-auth` 是一个理想的选择。
- **中小型项目**：对于没有复杂身份验证需求的应用，使用 `@sidebase/nuxt-auth` 可以省去大量的开发时间，降低开发成本。
- **支持多种认证方式的应用**：如果你的应用需要支持多种登录方式（如 GitHub、Google、Twitter 等），@sidebase/nuxt-auth 提供了一个统一的解决方案，避免了逐个服务集成的复杂性。

## 总结

无论你是正在构建一个新应用，还是在为已有应用添加第三方授权登录功能，`@sidebase/nuxt-auth` 都能提供一个高效、灵活且安全的解决方案。它不仅能节省开发时间，还能帮助你轻松管理用户身份验证和会话，使你的应用更加安全、易用。如果你还在手动编写每个第三方登录的代码，赶快尝试 `@sidebase/nuxt-auth`，享受更加便捷的开发体验吧！

【编程技术】你还在手写各种第三方授权登录吗？来学学NuxtAuth吧（基于Nuxt3）

## 简介

[@sidebase/nuxt-auth](https://auth.sidebase.io/) 是一个搭配 `Nuxt3` 使用的项目鉴权插件，其功能是基于 【[Authjs](https://authjs.dev/)】实现的，因此很多配置项与 `Authjs`相同。

> ps: Authjs支持的功能比较多，所以一般都采用 `Authjs` 方案，但 `@sidebase/nuxt-auth` 

## 问题

在使用 `@sidebase/nuxt-auth` 时，需要配置一些基本配置项，可以参考官方文档：https://auth.sidebase.io/guide/authjs/quick-start

其中基础配置项为：

```ts
export default defineNuxtConfig({
  modules: ['@sidebase/nuxt-auth'],
  auth: {
    provider: {
      type: 'authjs',
      trustHost: false,
      defaultProvider: 'github',
      addDefaultCallbackUrl: true
    }
  }
})
```

配置上述内容后，即需要根据 `@sidebase/nuxt-auth` 官方文档编写登录接口，具体内容再次不赘述，有需要可自行查阅。

之后就可以正常启动测试，但是启动时大概率会报错：

```
ℹ AUTH_NO_ORIGIN: No origin - this is an error in production, see https://sidebase.io/nuxt-auth/resources/errors. You can ignore this during development
```

根据这个错误信息可以知道，开发环境可以忽略这个错误，但是如果你看到这里就不管了，生产环境不做处理必然会报错，那么如何解决呢？



## 官方说明

根据错误信息提示打开网址，可以看到关于 `AUTH_NO_ORIGIN` 错误的如下说明：

> `AUTH_NO_ORIGIN` 将在开发期间显示为警告消息，并在生产期间抛出为错误，从而停止应用程序。可以安全地忽略开发警告 - 它只是为您以后的生产部署提供提醒。
> 
> `AUTH_NO_ORIGIN` 当您未设置应用程序的来源时，就会发生这种情况。`NuxtAuth` 会尝试按以下顺序查找应用程序的来源（来源）：
> 
> 1. 环境变量和`runtimeConfig`
> 使用 `AUTH_ORIGIN` 环境变量或（`runtimeConfig.authOrigin`如果已设置）名称可以自定义，请参阅[originEnvKey](https://auth.sidebase.io/guide/application-side/configuration#originenvkey)。
>
> 2. baseURL  
> 根据提供的计算origin得出。请参阅[此处](https://github.com/sidebase/nuxt-auth/blob/9852116a7d3f3be56f6fdc1cba8bdff747c4cbb8/src/runtime/helpers.ts#L9-L23)的实现。
> ```
> export default defineNuxtConfig({
>   auth: {
>     baseURL: `http://localhost:${process.env.PORT || 3000}`
>   }
> })
> ```
> 3. 仅限开发：自动从传入的 `HTTP` 请求中  
> 当服务器以开发模式运行时，`NuxtAuth` 可以从传入的请求中自动推断它。
> 
> 提示：这样做只是为了您的方便 - 请确保在生产中设置正确的原点。
> 
> 如果上述步骤之后仍然无效，`AUTH_NO_ORIGIN` 则生产时会抛出错误。

### 总结

总结一下官方说明，可以通过两种方式配置 `ORIGIN`，如果配置在生产环境无效，则会报错。

## 解决

### 直接环境变量

1. 配置环境变量，如`NUXT_AUTH_ORIGIN`：

```sh
# 生产环境别忘了改
NUXT_AUTH_ORIGIN="http://localhost:9910/api/auth"
```

2. 指定 `origin` 的环境变量 `key`：

在 nuxt 配置文件中增加 `originEnvKey`配置，如：

```ts
export default defineNuxtConfig({
  auth: {
    originEnvKey: 'NUXT_YOUR_ORIGIN'
  },
  runtimeConfig: {
    yourOrigin: ''
  }
})
```

- 补充：本来以为 `AUTH_ORIGIN` 环境变量直接配置，就不用再配置 `originEnvKey` 了，结果发现并不是这么回事，必须配置 `originEnvKey` 才能生效，不知道是老狗打开方式不对还是BUG？。。。

### 配置baseUrl

通过 `auth.baseUrl` 配置项，直接指定url，如果没有单独配置 `origin` 环境变量，则会默认使用 `baseUrl` 为 `origin`。配置如下：

```ts
export default defineNuxtConfig({
  auth: {
    baseURL: https://localhost:3001/api/auth",
  },
})
```

- 补充：`baseUrl` 也可以使用环境变量配置，如：`baseURL: process.env.NUXT_AUTH_ORIGIN`

## 吐槽

这一个配置高这么复杂干嘛，一种方式固定配置得了呗，文档虽然写了这么多，但写 `origin` 这个配置干啥用的至今也没找到相关说明。。。。

使用@sidebase/nuxt-auth开发项目部署时报错AUTH_NO_ORIGIN解决

在 Windows 的 CMD 窗口中，将编码修改为 UTF-8 可以按照以下步骤操作：




## 临时修改

在 `CMD` 窗口中运行以下命令：

```cmd
chcp 65001
```

这会将 `CMD` 的代码页设置为 `UTF-8`（代码页 65001）。设置完成后，CMD 窗口的编码将变为 UTF-8。

> 注意：这种方法是临时的，只对当前 CMD 会话有效。关闭 CMD 窗口后，编码会恢复为默认值。

## 永久修改

如果希望 `CMD` 默认以 `UTF-8` 编码运行，可以通过以下方法设置：

> 修改注册表方案在Windows11中已经失效（`或者操作有误`），再次不做介绍，有兴趣可自己尝试。

在最新的 `Windows10/11` 中，提供了全局修改的方法，但还是测试版本，因此知道的人还不多：

通过 `Win + R` 打开【运行】窗口，输入 `intl.cpl` 点击确定，如下图

![oldmoon.top](https://images.oldmoon.top/images/dingdangdog/1734698865287-1-.jpg)

确定后，将弹出一个窗口，按照如下图中指示修改即可：

![oldmoon.top](https://images.oldmoon.top/images/dingdangdog/1734698514111-1-.jpg)

点击确定后需要重启电脑，使其生效！

> 提示：此方法会将所有 CMD 窗口的默认编码设置为 UTF-8。

Windows修改CMD窗口编码为UTF8 - 最新方案

#### **作用/效果**

该脚本的主要功能是递归处理指定文件夹及其子文件夹中的文件，按照文件名的编码部分（通过空格拆分获取第一个部分）去重，只保留最新创建的文件，并删除重复文件。该功能在文件备份管理中非常有用，能够有效减少冗余文件，节省存储空间。




## Python

需要安装 `Python` 环境！

```python
import os
import shutil

# 指定目标文件夹路径
target_folder = input("请输入目标文件夹路径：")

# 检查文件夹是否存在
if not os.path.exists(target_folder):
    print(f"指定的文件夹 {target_folder} 不存在!")
    exit(1)

# 遍历目标文件夹中的所有文件
for filename in os.listdir(target_folder):
    file_path = os.path.join(target_folder, filename)

    # 确保是文件而不是文件夹
    if os.path.isfile(file_path):
        # 按照'-'分割文件名，取第一个部分作为文件夹名称
        folder_name = filename.split('-')[0]

        # 创建目标文件夹（如果不存在的话）
        folder_path = os.path.join(target_folder, folder_name)
        if not os.path.exists(folder_path):
            os.makedirs(folder_path)

        # 将文件移动到对应的文件夹
        new_file_path = os.path.join(folder_path, filename)
        shutil.move(file_path, new_file_path)

        print(f"文件 {filename} 已移动到 {folder_name} 文件夹")

```

### 运行方式

1. 保存脚本为 `deduplicate.py`。

2. 运行命令：

   ```sh
   python deduplicate.py
   ```

3. 按照提示，输入文件夹，如：

   ```sh
   请输入目标文件夹路径：/path/to/folder
   ```

4. 脚本会自动处理指定文件夹及其所有子文件夹，删除多余文件。

通过该脚本，可轻松实现文件夹中冗余文件的自动化清理工作。


## Nodejs

需要安装Nodejs环境！

```js
const fs = require('fs');
const path = require('path');
const readline = require('readline');

// 创建一个读取用户输入的接口
const rl = readline.createInterface({
    input: process.stdin,
    output: process.stdout
});

// 提示用户输入目标文件夹路径
rl.question('请输入目标文件夹路径：', (targetFolder) => {
    // 检查目标文件夹是否存在
    if (!fs.existsSync(targetFolder)) {
        console.error(`指定的文件夹 ${targetFolder} 不存在!`);
        rl.close();
        return;
    }

    // 读取目标文件夹中的所有文件
    fs.readdir(targetFolder, (err, files) => {
        if (err) {
            console.error('读取文件夹内容失败：', err);
            rl.close();
            return;
        }

        files.forEach((filename) => {
            const filePath = path.join(targetFolder, filename);

            // 确保是文件而不是文件夹
            if (fs.lstatSync(filePath).isFile()) {
                // 按照 '-' 分割文件名，取第一个部分作为文件夹名称
                const folderName = filename.split('-')[0];

                // 创建目标文件夹（如果不存在的话）
                const folderPath = path.join(targetFolder, folderName);
                if (!fs.existsSync(folderPath)) {
                    fs.mkdirSync(folderPath);
                }

                // 移动文件到对应的文件夹
                const newFilePath = path.join(folderPath, filename);
                fs.renameSync(filePath, newFilePath);

                console.log(`文件 ${filename} 已移动到 ${folderName} 文件夹`);
            }
        });

        console.log('操作完成!');
        rl.close();
    });
});

```

### 运行方式

1. 保存脚本为 `deduplicate.js`。

2. 运行命令：

   ```sh
   node deduplicate.js
   ```

3. 示例：

   ```sh
   请输入目标文件夹路径：/path/to/folder
   ```

4. 脚本会自动处理指定文件夹及其所有子文件夹，删除多余文件。

通过该脚本，可轻松实现文件夹中冗余文件的自动化清理工作。

## Shell

Linux & MacOS 可直接使用的shell脚本：

```sh
#!/bin/bash

# 提示用户输入目标文件夹路径
read -p "请输入目标文件夹路径: " target_folder

# 检查目标文件夹是否存在
if [ ! -d "$target_folder" ]; then
  echo "指定的文件夹 $target_folder 不存在!"
  exit 1
fi

# 遍历目标文件夹中的所有文件
for file in "$target_folder"/*; do
  # 确保是文件而不是文件夹
  if [ -f "$file" ]; then
    # 获取文件名
    filename=$(basename "$file")
    # 按照 '-' 分割文件名，取第一个部分作为文件夹名称
    folder_name=${filename%%-*}

    # 创建目标文件夹（如果不存在的话）
    folder_path="$target_folder/$folder_name"
    if [ ! -d "$folder_path" ]; then
      mkdir "$folder_path"
    fi

    # 移动文件到对应的文件夹
    mv "$file" "$folder_path"
    echo "文件 $filename 已移动到 $folder_name 文件夹"
  fi
done

echo "操作完成!"

```

文件分组脚本 | Python | Nodejs | Shell

设置 `type` 为 `"commonjs"` 和 `"module"` 的主要区别是决定了你在项目中使用 **模块化语法** 的方式。它们是两种不同的模块化规范，各有特点和适用场景。在 Electron 项目中，这种选择会影响你的代码组织和兼容性。

> PS：下面都是一堆屁话，试用electron强烈推荐使用 `commonjs` 语法，因为使用 `ESM(module)` 语法可能会遇到各种各样奇怪的问题，一旦出现问题比较麻烦！！！

------



## 基本区别

### **CommonJS (`type: "commonjs"`)**

- 规范来源：Node.js 原生支持。
- 语法：
  - 导入模块：`const module = require("module");`
  - 导出模块：`module.exports = someValue;`
- 特点：
  - 模块是同步加载的，代码在运行时加载依赖。
  - 更适合于后端或环境中代码运行时动态加载依赖。

### **ES Module (ESM, `type: "module"`)**

- 规范来源：ECMAScript 标准（现代 JavaScript）。
- 语法：
  - 导入模块：`import module from "module";`
  - 导出模块：`export default someValue;` 或 `export { something };`
- 特点：
  - 模块是静态加载的，代码在编译阶段解析依赖。
  - 提供更高的性能和优化潜力，比如 tree-shaking（移除未使用的代码）。

------

## 优缺点

在 Electron 中，你通常需要写两个部分的代码：

1. **主进程代码**：管理窗口、事件、和操作系统交互（典型文件是 `main.js`）。
2. **渲染进程代码**：与用户界面相关的前端代码（类似普通 Web 应用）。

这两部分可以分别使用 CommonJS 或 ESM，选择的设置主要影响 **主进程** 的代码。

### **CommonJS in Electron**

- **特点**：
  - Electron 的核心 API（如 `require("electron")`）完全兼容 CommonJS。
  - 大量的 Node.js 库原生支持 CommonJS。
  - 更加成熟和广泛使用，适合 Electron 的传统开发模式。
- **优点**：
  - 与现有 Electron 项目和教程兼容，学习曲线低。
  - 不需要调整 Node.js 中原生模块的使用方法。
- **缺点**：
  - 随着 JavaScript 的发展，ESM 正在成为标准规范，CommonJS 在新项目中使用率逐渐下降。
  - 缺少 ESM 的一些高级功能（比如 tree-shaking）。

### **ESM in Electron**

- **特点**：
  - Electron 和 Node.js 现在都支持 ESM，完全可以在项目中使用现代语法。
  - 需要将所有模块改为 `import` 和 `export` 语法。
- **优点**：
  - 使用现代 JavaScript 语法，便于未来维护。
  - 与前端代码统一（渲染进程通常是基于 ESM 的）。
  - 更容易实现性能优化（如 tree-shaking）。
- **缺点**：
  - 如果依赖的库是 CommonJS 格式，需要额外处理（如用 `createRequire` 动态加载）。
  - 部分旧库可能不支持 ESM。

------

## 应用场景

### **选择 `"commonjs"` 的场景**

- 你是初学者，对 JavaScript 和 Electron 生态不熟悉。
- 项目需要大量使用旧的 Node.js 模块或教程。
- 你希望快速实现一个功能原型，不希望花时间调整代码结构。

### **选择 `"module"` 的场景**

- 你想从一开始就使用现代 JavaScript 语法，保持代码的现代化。
- 项目有前后端代码统一为 ESM 的需求。
- 你需要依赖一些现代的 ESM-only 的库（如 `node-fetch@3`）。

------

## 如何选择和使用

### **保持 CommonJS**

1. `package.json`:

   ```
   json复制代码{
     "type": "commonjs"
   }
   ```

2. 主进程代码（`main.js`）：

   ```
   javascript复制代码const { app, BrowserWindow } = require("electron");
   
   app.whenReady().then(() => {
     const win = new BrowserWindow();
     win.loadFile("index.html");
   });
   ```

3. 优化点：

   - 如果需要 ESM-only 的库（如 

     ```
     node-fetch@3
     ```

     ），用 

     ```
     dynamic import
     ```

     ：

     ```
     javascript复制代码const fetchData = async () => {
       const { default: fetch } = await import("node-fetch");
       const data = await fetch("https://api.example.com").then((res) => res.json());
       console.log(data);
     };
     ```

### **迁移到 ESM**

1. `package.json`:

   ```
   json复制代码{
     "type": "module"
   }
   ```

2. 主进程代码（`main.js`）：

   ```
   javascript复制代码import { app, BrowserWindow } from "electron";
   
   app.whenReady().then(() => {
     const win = new BrowserWindow();
     win.loadFile("index.html");
   });
   ```

3. 如果依赖 CommonJS 库，使用 `createRequire`：

   ```
   javascript复制代码import { createRequire } from "module";
   const require = createRequire(import.meta.url);
   const fs = require("fs"); // 加载 CommonJS 模块
   ```

------

## 总结

- 如果你是初学者，并且希望快速开始，**选择 CommonJS (`type: "commonjs"`)**。这能让你避免一些兼容性问题，同时与大部分 Electron 教程一致。
- 如果你希望项目与现代 JavaScript 保持一致并长期维护，**选择 ESM (`type: "module"`)**，尤其是当你已经熟悉了 ESM 语法和工具。

两种方式都可以用在 Electron 项目中，选择适合你当前需求和学习阶段的即可。

Electron项目中，应该使用commonjs还是module？

twitter:card

twitter:title

twitter:site

twitter:image

努力做一只帅气、有才、豁达的老狗！

twitter:description

程序员,笔记,Bug记录,编程技术,AI,Java,Node,Golang,个人博客,资源分享,月上老狗,dingdangdog