删除多个文档,包括部署指南、链接管理功能、权限系统配置总结及上号系统需求文档,优化项目结构,提升代码整洁性

This commit is contained in:
yahaozhang
2025-10-11 16:55:58 +08:00
parent 2a45e5e6be
commit 23e2a4512b
4 changed files with 0 additions and 734 deletions

View File

@@ -1,71 +0,0 @@
# Vue SPA 部署指南
## 问题描述
当直接访问 `http://uzi1.cn/play?code=973F2YTE` 时出现404错误但其他页面正常。这是典型的单页应用(SPA)部署问题。
## 原因分析
1. **开发环境**Vite开发服务器自动处理路由回退
2. **生产环境**Web服务器尝试查找实际的 `/play` 文件,但这只是前端路由
## 解决方案
### 方案一Nginx 配置(推荐)
1. 使用项目根目录的 `nginx.conf` 文件
2. 修改其中的 `root` 路径为实际部署路径
3. 重新加载 Nginx 配置:
```bash
sudo nginx -t # 测试配置
sudo nginx -s reload # 重新加载
```
### 方案二Apache 配置
1.`apache.htaccess` 文件复制到 `dist` 目录下,重命名为 `.htaccess`
2. 确保 Apache 启用了 `mod_rewrite` 模块
### 方案三Netlify 部署
1.`_redirects` 文件复制到 `dist` 目录下
2. 重新部署到 Netlify
### 方案四:其他静态托管服务
对于其他静态托管服务,需要配置:
- 所有路由都回退到 `index.html`
- API 请求代理到 `http://192.140.164.137:18080`
## 重新构建和部署
```bash
# 1. 重新构建项目
npm run build
# 2. 将构建文件部署到服务器
# 确保 dist 目录下的所有文件都已上传
# 3. 配置 Web 服务器(选择上述方案之一)
# 4. 测试访问
# http://uzi1.cn/play?code=973F2YTE 应该能正常访问
```
## 验证步骤
1. 直接访问:`http://uzi1.cn/play?code=973F2YTE`
2. 应该能看到游戏页面而不是404错误
3. 刷新页面应该仍然正常
4. API 请求应该正常工作无CORS错误
## 常见问题
### Q: 仍然出现404错误
A: 检查Web服务器配置是否正确应用确认配置文件路径和语法
### Q: API请求失败
A: 检查代理配置,确认后端服务 `http://192.140.164.137:18080` 可访问
### Q: 静态资源加载失败
A: 检查资源路径配置,确认 `base` 配置正确

View File

@@ -1,182 +0,0 @@
# 链接管理功能
## 功能概述
链接管理页面提供了批量生成链接的功能支持设置生成次数和每次生成的链接数量。根据您提供的API接口系统会调用 `POST /api/link/generate` 接口来生成链接。
## 主要功能
### 1. 批量生成链接
- **生成次数**: 1-100次
- **每次链接数量**: 1-50个
- 支持表单验证
- 生成成功后自动刷新列表
### 2. 链接列表管理
- 分页显示已生成的链接批次
- 显示批次ID、机器编号、扣除积分、过期时间
- 支持查看、删除操作
- 根据过期时间自动判断链接状态
- 支持导出CSV数据
### 3. 二维码功能
- 根据机器编号生成对应的链接二维码
- 支持下载二维码图片
- 使用在线二维码生成服务
- 自动生成游戏链接地址
### 4. 权限控制
- 管理员:拥有所有权限(生成、查看、删除、导出)
- 代理商:只有查看权限
## API接口
### 生成链接
```http
POST /api/link/generate
Authorization: Bearer {token}
Content-Type: application/json
{
"times": 10, // 生成次数
"linkCount": 5 // 每次链接数量
}
```
**返回数据示例:**
```json
{
"batchId": 6,
"deductPoints": 50,
"expireAt": "2025-08-26T12:29:13.63955",
"codeNos": [
"X3T9ND84"
]
}
```
### 获取链接列表
```http
GET /api/link/list?page=1&pageSize=20
Authorization: Bearer {token}
```
### 删除链接
```http
DELETE /api/link/{id}
Authorization: Bearer {token}
```
## 页面路由
- **路径**: `/links`
- **名称**: `Links`
- **权限**: `LINK_VIEW`
## 文件结构
```
src/
├── api/
│ └── links.js # 链接相关API接口
├── views/links/
│ └── LinkGenerate.vue # 链接生成页面
├── utils/
│ └── links.js # 链接管理工具函数
├── config/
│ └── links.js # 链接管理配置文件
├── router/
│ └── index.js # 路由配置(已更新)
├── layouts/
│ └── AdminLayout.vue # 导航菜单(已更新)
└── utils/
└── permission.js # 权限配置(已更新)
```
## 使用说明
### 1. 生成链接
1. 在"生成次数"输入框中输入要生成的次数1-100
2. 在"每次链接数量"输入框中输入每次生成的链接数量1-50
3. 点击"开始生成"按钮
4. 系统会调用API生成链接成功后显示提示信息
### 2. 管理链接
- 查看已生成的链接列表
- 点击"查看二维码"查看链接对应的二维码
- 点击"删除"删除不需要的链接
- 使用"导出CSV"功能导出链接数据
### 3. 权限说明
- 管理员可以执行所有操作
- 代理商只能查看链接列表,无法生成或删除链接
## 注意事项
1. **API地址**: 确保后端API地址配置正确当前配置为 `http://localhost:18080`
2. **认证**: 需要有效的Bearer Token才能访问API
3. **二维码**: 使用在线二维码生成服务,确保网络连接正常
4. **批量限制**: 单次最多生成50个链接避免API压力过大
5. **链接地址**: 系统会自动根据机器编号生成游戏链接地址,格式为 `https://yourdomain.com/play?code={机器编号}`
6. **状态判断**: 链接状态根据过期时间自动判断(正常/即将过期/已过期)
7. **配置自定义**: 可以在 `src/config/links.js` 中自定义链接地址生成规则和状态配置
## 配置说明
### 链接地址配置 (`src/config/links.js`)
```javascript
export const LINK_CONFIG = {
// 基础域名
BASE_URL: 'https://yourdomain.com',
// 游戏页面路径
GAME_PATH: '/play',
// 机器编号参数名
CODE_PARAM: 'code',
// 链接地址模板
getLinkUrl: (codeNo) => {
return `${LINK_CONFIG.BASE_URL}${LINK_CONFIG.GAME_PATH}?${LINK_CONFIG.CODE_PARAM}=${codeNo}`
}
}
```
### 状态配置
```javascript
export const STATUS_CONFIG = {
// 状态标签类型
LABEL_TYPES: {
NORMAL: 'success', // 正常
EXPIRING: 'warning', // 即将过期
EXPIRED: 'danger', // 已过期
UNKNOWN: 'info' // 未知
},
// 过期时间阈值(毫秒)
EXPIRING_THRESHOLD: 24 * 60 * 60 * 1000, // 24小时
}
```
## 扩展功能
可以根据需要添加以下功能:
- 链接状态切换(启用/禁用)
- 链接过期时间设置
- 链接使用统计
- 自定义链接模板
- 批量操作(批量删除、批量导出等)
- 链接访问统计和监控
## 技术特点
- 使用Vue 3 Composition API
- Element Plus UI组件库
- 响应式设计
- 权限控制集成
- 错误处理和用户提示
- 支持CSV导出

View File

@@ -1,193 +0,0 @@
# 权限系统配置总结
## 概述
本系统采用基于角色的权限控制RBAC机制通过用户类型ADMIN/AGENT来控制用户的功能访问权限。
## 用户类型权限配置
### ADMIN管理员
- **权限范围**:拥有系统所有功能的访问权限
- **路由访问**:可以访问所有页面和路由
- **功能权限**
- 用户管理(创建、编辑、删除、启用/禁用)
- 游戏管理(查看、创建、编辑、删除)
- 订单管理(查看、管理)
- 报表分析(查看)
- 系统设置(管理)
### AGENT代理商
- **权限范围**:只能查看基础信息,无管理权限
- **路由访问**:只能访问部分页面
- **功能权限**
- 游戏查看
- 订单查看
- 报表查看
## 权限检查机制
### 1. 路由权限检查
```javascript
// 管理员可以访问所有路由
export function canAccessRoute(routeName) {
if (isAdmin()) return true
const requiredPermissions = ROUTE_PERMISSIONS[routeName] || []
if (requiredPermissions.length === 0) return true
return hasAnyPermission(requiredPermissions)
}
```
### 2. 功能权限检查
```javascript
// 检查单个权限
const canCreateUser = hasPermission('user:create')
// 检查多个权限(任一)
const canManageUsers = hasAnyPermission(['user:create', 'user:update', 'user:delete'])
// 检查多个权限(全部)
const canFullManage = hasAllPermissions(['user:create', 'user:update', 'user:delete'])
```
### 3. 权限指令使用
```vue
<!-- 单个权限 -->
<el-button v-permission="'user:create'">新增用户</el-button>
<!-- 多个权限OR逻辑 -->
<el-button v-permission="['user:create', 'user:update']">操作</el-button>
<!-- 多个权限AND逻辑 -->
<el-button v-permission="['user:create', 'user:update', 'AND']">操作</el-button>
```
## 权限配置详情
### 权限定义
```javascript
export const PERMISSIONS = {
// 用户管理权限
USER_MANAGE: 'user:manage',
USER_CREATE: 'user:create',
USER_UPDATE: 'user:update',
USER_DELETE: 'user:delete',
USER_VIEW: 'user:view',
// 游戏管理权限
GAME_MANAGE: 'game:manage',
GAME_CREATE: 'game:create',
GAME_UPDATE: 'game:update',
GAME_DELETE: 'game:delete',
GAME_VIEW: 'game:view',
// 订单管理权限
ORDER_MANAGE: 'order:manage',
ORDER_VIEW: 'order:view',
// 报表分析权限
REPORT_VIEW: 'report:view',
// 系统设置权限
SETTING_MANAGE: 'setting:manage',
}
```
### 角色权限映射
```javascript
export const ROLE_PERMISSIONS = {
ADMIN: [
// 管理员拥有所有权限
PERMISSIONS.USER_MANAGE, PERMISSIONS.USER_CREATE, PERMISSIONS.USER_UPDATE,
PERMISSIONS.USER_DELETE, PERMISSIONS.USER_VIEW,
PERMISSIONS.GAME_MANAGE, PERMISSIONS.GAME_CREATE, PERMISSIONS.GAME_UPDATE,
PERMISSIONS.GAME_DELETE, PERMISSIONS.GAME_VIEW,
PERMISSIONS.ORDER_MANAGE, PERMISSIONS.ORDER_VIEW,
PERMISSIONS.REPORT_VIEW, PERMISSIONS.SETTING_MANAGE,
],
AGENT: [
// 代理商只有查看权限
PERMISSIONS.GAME_VIEW, PERMISSIONS.ORDER_VIEW, PERMISSIONS.REPORT_VIEW,
]
}
```
### 路由权限映射
```javascript
export const ROUTE_PERMISSIONS = {
'Users': [PERMISSIONS.USER_VIEW],
'Games': [PERMISSIONS.GAME_VIEW],
'Orders': [PERMISSIONS.ORDER_VIEW],
'Reports': [PERMISSIONS.REPORT_VIEW],
'Settings': [PERMISSIONS.SETTING_MANAGE],
}
```
## 权限控制层级
### 1. 路由级权限控制
- 在路由守卫中检查用户是否有访问权限
- 管理员可以访问所有路由
- 代理商只能访问有权限的路由
- 无权限时自动跳转到仪表盘页面
### 2. 菜单级权限控制
- 根据用户权限动态显示/隐藏菜单项
- 代理商用户看不到"用户管理"和"系统设置"菜单
- 管理员可以看到所有菜单项
### 3. 页面级权限控制
- 在页面组件中检查用户权限
- 无权限时显示权限不足提示
- 提供友好的用户体验
### 4. 操作级权限控制
- 根据用户权限显示/隐藏操作按钮
- 代理商用户无法进行用户管理操作
- 使用权限指令控制按钮显示
## 安全注意事项
1. **前端权限控制仅用于用户体验**,不能作为安全依据
2. **后端必须进行权限验证**,确保数据安全
3. **敏感操作需要二次确认**,如删除用户
4. **权限变更需要重新登录**,确保权限生效
5. **定期审查权限配置**,避免权限泄露
## 测试验证
### 权限测试页面
- 访问 `/permission-test` 页面
- 查看当前用户的权限状态
- 测试各种权限检查功能
- 验证路由访问权限
### 测试建议
1. 使用不同用户类型登录,验证权限控制
2. 测试无权限访问时的跳转逻辑
3. 验证菜单和按钮的显示/隐藏
4. 测试后端接口的权限验证
5. 检查权限变更后的效果
## 扩展说明
### 添加新权限
1.`PERMISSIONS` 对象中添加新权限
2.`ROLE_PERMISSIONS` 中为不同角色分配权限
3.`ROUTE_PERMISSIONS` 中配置路由权限要求
4. 更新相关的前端权限检查逻辑
### 修改角色权限
1. 修改 `ROLE_PERMISSIONS` 中对应角色的权限数组
2. 更新相关的前端权限检查逻辑
3. 测试权限变更后的效果
## 总结
当前的权限系统配置确保了:
- **管理员拥有所有权限**,可以访问所有页面和功能
- **代理商只有查看权限**,无法进行管理操作
- **权限检查机制完善**,包括路由、菜单、页面、操作四个层级
- **用户体验友好**,无权限时提供清晰的提示和跳转
- **安全性保障**,前后端都有权限验证机制

View File

@@ -1,288 +0,0 @@
# 上号系统需求文档PRD/SRSv0.9
> 基于《安装步骤.docx》与用户确认的补充说明整理。本文作为首版“可评审草案”确认后进入详细设计与开发。
---
## 0. 版本信息
* 文档版本v0.9(草案)
* 更新时间2025-08-23
* 负责人:待定
* 评审人:待定
* 目标里程碑首版上线TBD
---
## 1. 项目概述
### 1.1 背景
提供“上号任务”的一站式系统,生成带签名与加密的用户链接,用户进入后进行选区、扫码上号、实时进度与二界面跳转;面向商家(管理员、代理商)提供链接批量生成与额度(点数)管理、退单与公告等功能。
### 1.2 目标
* 终端用户侧:通过单个加密链接完成选区 → 扫码上号 → 进入二界面。
* 商家侧:
* 管理员:创建代理商账号、为代理商添加点数(余额)、批量生成链接、退单、公告管理、数据导出。
* 代理商:查看自身额度、批量生成链接、退单、数据导出、查看公告。
### 1.3 不在范围(本期)
* 对账、统计、风控(均不做)。
* 富文本公告、多语言、公告定时上线下线。
* 数据导入(仅导出)。
---
## 2. 角色与权限
* **终端用户**:仅访问加密链接完成流程。
* **管理员**:代理商管理(创建/启停/加点)、批量生成链接、退单、公告发布、导出。
* **代理商**:批量生成链接(前提是额度充足)、退单、导出、查看公告。
### 2.1 权限矩阵(简表)
| 功能 | 终端用户 | 代理商 | 管理员 |
| ---------- | ---- | ------- | ------ |
| 访问加密链接进行上号 | ✔️ | — | — |
| 批量生成链接 | — | ✔️ | ✔️ |
| 查看/导出链接 | — | ✔️(仅自己) | ✔️(全量) |
| 退单 | — | ✔️(仅自己) | ✔️(全量) |
| 公告查看 | — | ✔️ | ✔️ |
| 公告发布 | — | — | ✔️ |
| 代理商账号管理/加点 | — | — | ✔️ |
---
## 3. 术语与规则
* **链接Link**:一次任务的入口地址,带签名与加密;默认有效期 **24 小时**(可配)。
* **编号CodeNo**:由后端自动生成,**全局唯一**、可追踪;用于日志与二界面模板替换。
* **数量Quantity**:一次执行产生的奖励数,例如 50。
* **次数Times**:重复执行次数,例如 20。
* **总点数TotalPoints**`Times × Quantity`,例如 20×50=1000。
* **批量生成**:同一组设置一次生成 N 个链接(默认 10 个,可配)。
* **二界面**:外部提供的页面或资源,系统在上号成功后 **用编号动态替换**后跳转。
* **脚本端**:运行在手机上的脚本与相关资源(例如二维码图片、进度截图、上号判断等),由系统通过适配器服务进行对接。
---
## 4. 业务流程
### 4.1 链接生命周期(简述)
1. 商家侧生成链接:校验额度 → 扣减点数(`Times×Quantity`)→ 生成编号 → 生成**加密+签名**链接 → 设置过期时间24h
2. 终端用户访问链接:若未过期,进入“选区→扫码上号”流程;成功则跳转二界面;若退单或过期则提示不可用。
3. 退单:释放机器(不回滚额度),记录日志。
### 4.2 终端用户流程(含二次识别/刷新约束)
* **首次进入**
1. 选区安卓QQ/安卓WX
2. 触发脚本端生成二维码;前端按返回的 `qrCreatedAt/qrExpireAt` 本地计算倒计时并轮询上号状态。
3. 上号成功 → 跳转二界面(按模板替换编号)。
* **未进入二界面即退出/刷新/返回**
* 规则:**必须先调用“刷新”接口** → 等待 **Y 秒(默认 10s可配** → 才允许再次选区与扫码。
### 4.3 退单流程
* 商家提交编号 → 系统释放关联机器(若有)→ 标记退单 → 记录日志;额度**不回滚**。
### 4.4 扣费时机与计算
* **生成链接时即扣费**`扣减点数 = Times × Quantity × 批量个数`
* 额度不足:拒绝生成。
### 4.5 公告
* 简单文本公告(可配置是否展示、展示位置),无定时/富文本/多语言。
### 4.6 用户端(扫码登录)规范(单链接模式 · 定稿)
> 本节**仅**描述用户访问与后端处理逻辑;不涉及商家功能。**一切界面都在同一 URL**`https://yourdomain.com/play?code={codeNo}`。前端通过该 URL 内的 `code` 调用后端查询状态并渲染对应页面(首界面/扫码界面/二界面)。
#### 4.6.1 URL 与安全
* 入口:`GET https://yourdomain.com/play?code={opaque}``code` 为**加密+签名**的**不透明**令牌(包含 linkId/iat/exp 等),不可被推断。
* 后端在**每次**接口调用时校验:解密→签名→有效期(默认 24h→状态失败返回 401/403/410过期
#### 4.6.2 状态模型(后端对前端暴露)
* `NEW`:未进入扫码流程(未选区)。
* `USING`:已进入扫码流程(已选区,二维码有效期内)。
* `LOGGED_IN`:已上号(展示二界面)。
* `REFUNDED`:已退单(不可用)。
* `EXPIRED`已过期24h
* `needRefresh: boolean`:是否必须先刷新→等待 10 秒→再允许选区与扫码(只要进入过扫码但未到二界面时生效)。
#### 4.6.3 用户端 API仅用户用
> 路径示例以 `/api/link/*` 说明;实际以最终路由为准。
1. **获取状态**
`GET /api/link/status?code={code}`
```json
{
"status": "NEW | USING | LOGGED_IN | REFUNDED | EXPIRED",
"needRefresh": false,
"region": "Q | V | null",
"qr": { "url": "http://ip:12345/{编号}/二维码.png", "createdAt": 1730000000000, "expireAt": 1730000060000 },
"view": "FIRST | SCAN | SECOND",
"assets": {
"base": "http://ip:12345/{编号}/",
"firstHome": "首次主页.png",
"firstBonus": "首次赏金.png",
"midBonus": "中途赏金.png",
"endBonus": "结束赏金.png"
}
}
```
* 说明:
* `qr` 仅在 `status=USING` 时返回;若脚本端无 TTL后端以默认 **60s** 回填。
* `view` 是前端渲染建议:`FIRST(选区) / SCAN(扫码) / SECOND(二界面)`;实际以 `status/needRefresh` 为准。
* `assets` 为二界面所需的静态资源信息(路径中需要自动替换编号)。
2. **选区**
`POST /api/link/select-region`
Body: `{ code: string, region: "Q" | "V" }` → 返回:
```json
{
"status": "USING",
"needRefresh": false,
"qr": { "url": "http://ip:12345/{编号}/二维码.png", "createdAt": 1730000000000, "expireAt": 1730000060000 }
}
```
* 后端行为:按需分配机器、下发任务参数、请求脚本端生成二维码;将状态置为 `USING`
3. **刷新**
`POST /api/link/refresh`
Body: `{ code: string }` → 返回:
```json
{ "needRefresh": true, "waitSeconds": 10 }
```
* 规则:**未到二界面前**,再次尝试必须先刷新并在前端**等待 10 秒**后才允许重新选区与扫码。
4. **轮询上号**
`GET /api/link/poll-login?code={code}`
* 未上号:`{ "success": false, "status": "USING" }`
* 已上号:
```json
{ "success": true, "status": "LOGGED_IN", "view": "SECOND", "assets": { "base": "http://ip:12345/{编号}/", "endBonus": "结束赏金.png" } }
```
* 前端据返回改为渲染**二界面**(同一个 URL不跳转
> 可选:`GET /api/link/qr.png?code={code}` 由后端代理二维码,确保整链路 HTTPS避免浏览器混合内容拦截。
#### 4.6.4 前端渲染流程(同一路由)
1. **首访**:调用 `/api/link/status` 渲染:
* `NEW` → 显示选区页(两个按钮 Q/V
* `USING` → 显示扫码页(二维码+倒计时),并开始轮询 `/poll-login`(每 1s
* `LOGGED_IN` → 显示二界面(依 `assets` 取图/信息)。
* `REFUNDED/EXPIRED` → 显示不可用页。
2. **选区**`POST /select-region` 成功后进入扫码页,开始轮询。
3. **二维码过期**:倒计时到 0 或轮询返回需刷新 → 显示“请刷新”按钮;调用 `/refresh` 并禁用按钮 **10s**,倒计时结束后恢复“选区”按钮。
4. **上号成功**:轮询返回 `LOGGED_IN` → 在**同一 URL** 切换到二界面视图;前端可停止所有轮询与倒计时。
#### 4.6.5 后端内部处理要点
* **校验**:对所有接口按 `code` 做鉴权(签名/解密/过期/撤销/退单)。
* **状态流转**
* `NEW → USING`:选区成功并生成二维码。
* `USING → LOGGED_IN`:脚本端返回“已上号”。
* `NEW/USING → REFUNDED | EXPIRED`:退单或超时达 24h。
* **刷新约束**:对进入过扫码但未上号的会话,标记 `needRefresh=true``/refresh` 后写入“刷新时间”,后续 **10s** 内拒绝 `select-region`
* **脚本端适配**:分配/释放机器、生成二维码、查询“是否上号”、可选的分数读取;超时重试与错误兜底(不把脚本端错误直接暴露给前端)。
* **幂等**`select-region`/`refresh`/`poll-login``code` 幂等处理,避免重复侧效应。
* **日志**:记录编号、选区、二维码下发/失效、上号结果、刷新与错误(保留 90 天)。
#### 4.6.6 错误与前端文案(示例)
* 401/403链接无效或已篡改 → “链接无效,请联系商家”。
* 410链接已过期 → “链接已过期,请联系商家重新获取”。
* 423需刷新等待 → “请先刷新并等待 10 秒后再试”。
* 504脚本端超时 → “当前排队人数较多,请稍后重试”。
> 以上约束确保“同一链接承载首界面/扫码/二界面”的产品体验,前端仅根据后端状态渲染视图,无需路由跳转。
次数链接
http://36.138.184.60:1234/yijianwan_netfile/saveMsg?文件名=总次数&编号=次数
后台操作流程: 后台管理员在后台输入框里面填写了一个次数5, 然后点击了生成, 平台会自动生成一个链接,格式如同:域名/加密
批量生成可以搞成下载文件或者复制粘贴都可以
后台功能:
1.后台可以直接单生成链接或者批量生成链接给用户使用如图
2.代理系统, 代理也可单独生成链接或批量生成, 后台可帮他设置金额, 代理使用多少,自动扣除多少
3.退单: 后台只需填写正确的编号运行退单链接,即可直接退单
4.用户选区之后等待几秒 出现二维码到期时间 刷新时间 用户使用有效期 设置
5.次数等于数量 设置
6.可以设置公告弹窗, 代理也可以自己生成自己的, 不会互通! 只有确定和取消按钮,点确定会跳转某网页
退单链接()
http://36.138.184.60:1234/yijianwan_netfile/saveMsg?文件名=判断退单&编号=T
第一步;用户界面 1和2
2
判断空的设备链接
http://36.138.184.60:1234/yijianwan_netfile/readAllMsg?文件名=判断分数
选区链接
http://36.138.184.60:1234/yijianwan_netfile/saveMsg?文件名=判断系统&编号=Q或V
刷新链接
http://36.138.184.60:1234/yijianwan_netfile/saveMsg?文件名=判断刷新&编号=刷新
二维码的http://36.138.184.60:12345/编号/二维码.png
判断是否上号
http://36.138.184.60:1234/yijianwan_netfile/readMsg?文件名=判断上号&对象名=编号 状态: 未上号 已上号 【已上号跳转第二个界面】
讲解:后台生成了一个链接,填写了次数, 用户拿到链接之后,在浏览器运行, 后台会自动获取一个空的编号, 然后用户可以自己选QQ区或微信区, 如果用户选择QQ区那么直接执行选区链接执行QQ的, 微信也一样, 根据后台设置的等待,几秒后获取二维码链接 如同第三张图, 点击之后你可以观看第三张图,有一个倒数时间,也可在后台设置时间, 如果用户在我设置的60秒内没扫码自动会跳出扫码超时,如第二张图, 用户可以继续选区, 后台会首先执行刷新链接, 然后根据后台设置的刷新时间等待多少秒后再执行选择QQ区或微信区的链接, 根据用户选择, 作者可以写一个日志或者其他把把这个些链接的使用流程记录下来,方便第二次识别,
假如:用户他第一次已经选过了区,但是他直接第二次刷新了浏览器, 导致没办法确认我后台对接的脚本是否在首页, 所以作者必须写个记录, 来判断这个链接是否被使用过一次,如果被使用过一次, 那么用户不管是刷新浏览器,还是等待超时扫码, 都判定为第二次! 所以必须先执行刷新根据后台设计的时间等待 再选区!
用户只要选区了,出现了二维码,那么后台只需要一直识别判断它是否上号那条链接,如果出现已上号,那么直接跳转第二个界面,未上号就一直在第一个界面!
用户扫码后跳转的:第二个界面
②http://36.138.184.60:12345/编号/首次主页.png
③http://36.138.184.60:12345/编号/首次赏金.png
④http://36.138.184.60:12345/编号/中途赏金.png
⑤http://36.138.184.60:12345/编号/结束赏金.png
讲解:
1.选择大厅这个就是用户自己选的区域显示
2.状态=已打完 空闲, 只要显示这两个状态,余地都是已打完,其他都是代练中
3.目标点数0/1000如图1000就是后台设置的次数x次数等于数量=1000 [假如后台设置的次数等于总量为50,那么必须设置20次才等于1000
使用过的所有链接总有效期为24小时 可设置
目标点数
http://36.138.184.60:1234/yijianwan_netfile/readMsg?文件名=判断分数&对象名=编号