OpenListTeam / OpenListTeam/OpenList
[Feature] 增加带有时效的可刷新token
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 24.7k
- Forks
- 2.3k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 36
Description
请确认以下事项
-
我已确认阅读并同意 AGPL-3.0 第15条 。
本程序不提供任何明示或暗示的担保,使用风险由您自行承担。 -
我已确认阅读并同意 AGPL-3.0 第16条 。
无论何种情况,版权持有人或其他分发者均不对使用本程序所造成的任何损失承担责任。 -
我确认我的描述清晰,语法礼貌,能帮助开发者快速定位问题,并符合社区规则。
-
我已确认阅读了OpenList文档。
-
我已确认没有重复的问题或讨论。
-
我认为此问题必须由
OpenList处理,而非第三方。 -
我已确认此功能尚未被实现。
-
我已确认此功能是合理的,且有普遍需求,并非我个人需要。
需求描述
增加带有时效的可刷新token
实现思路
新增两个API,类似于网盘,可以获取初始API和刷新API。
其中获取API的token应当获取一个与请求用户拥有相同权限的token,有一个较短时间的时限。
另一个刷新API的接口可以通过上一个token请求新的token,在获取过新的token后,旧的token失效,新的token刷新有效期。
附加信息
前端为了方便管理也可以在用户管理界面加入token管理的相关内容,同时加入用户级别的在前端获取API的功能,方便调用。避免全局令牌被滥用。
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names no files, tests, or entry points; begin by reading the existing authentication and global-token implementation and the OpenList documentation. Define the API and token lifecycle before coding: short-lived user-scoped tokens, refresh-token rotation that invalidates the old token, and matching user permissions. Treat token management and user-facing issuance as additional scope to clarify.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api, authentication, backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100