flask token

  • jwt pyjwt会导致jwt.encode()方法报错

  •   pip install pyjwt
    
  •   def generate_jwt(payload: dict, expiry: datetime, secret=None) -> str:
          """
          生成jwt
          :param payload: dict, 载荷
          :param expiry: datetime 有效期
          :param secret: 密钥
          :return: jwt
          """
      
          # 将过期时间加入payload
          _payload = {"exp": expiry}
          _payload.update(payload)
      
          if not secret:
              secret = current_app.config['JWT_SECRET']
      
          token = jwt.encode(_payload, secret, algorithm='HS256')
          return token
    

    生成jwt,三个部分组成:载荷、密钥、加密方法

    载荷中可以包含用户的信息以及exp有效期

  •   def verify_jwt(token: str, secret=None) -> dict:
          """
          检验token
          :param token: jwt
          :param secret: 密钥
          :return: payload
          """
      
          if not secret:
              secret = current_app.config["JWT_SECRET"]
      
          try:
              payload = jwt.decode(token, secret, algorithms=['HS256'])
          except jwt.PyJWTError as e:
              current_app.logger.error(e)
              payload = None
      
          return payload
    

    检验jwt,就是decode之前生成的jwt,然后验证其中的载荷部分的用户信息

  •   def generate_token(user_id: int, refresh=True) -> tuple:
          """
          生成token和refresh_token
          :param user_id: 用户id
          :param refresh:
          :return:
          """
          secret = current_app.config["JWT_SECRET"]
      
          expiry = datetime.utcnow() + timedelta(hours=current_app.config["JWT_EXPIRY_HOURS"])
      
          token = generate_jwt({"user_id": user_id}, expiry, secret)
      
          if refresh:
              expiry = datetime.utcnow() + timedelta(days=current_app.config["JWT_REFRESH_DAYS"])
              refresh_token = generate_jwt({"user_id": user_id, "is_refresh": True}, expiry, secret)
          else:
              refresh_token = None
      
          return token, refresh_token
    

    生成token的函数,token和refresh_token就是调用generate_jwt而生成的

  •   def jwt_authentication():
          """
          获取请求头中的token
          :return:
          """
          # 对于进入的请求先设定g中的user_id,is_refresh 来判定是否登录过
          g.user_id = None
          g.is_refresh = False
      
          token = request.headers.get("Authorization")
          current_app.logger.info(f"token is {token}")
      
          if token is not None and token.startswith("Bearer "):
              token = token[7:]
      
              # 验证token
              payload = verify_jwt(token)
              current_app.logger.info(f"payload is {payload}")
              if payload is not None:
                  g.user_id = payload.get("user_id")
                  g.is_refresh = payload.get("is_refresh", False)
    
    app.before_request(jwt_authentication)
    

    给flask添加钩子函数,当请求中包含token时,设定g中的user_id 和 is_refresh

  •   def login_required(func):
          @wraps(func)
          def wrapper(*args, **kwargs):
              if g.user_id is not None and g.is_refresh is False:
                  return func(*args, **kwargs)
              else:
                  current_app.logger.warn("Invalid token")
                  return {
                             "msg": "Invalid token"
                         }, 401
      
          return wrapper
    

    使用装饰器,如果g中已有user_id说明用户已登录

<think>嗯,用户这次聚焦在Gemini模型的token长度限制上,看来ta正在规划一个需要长上下文支持的项目。结合历史对话,用户之前已经了解过Gemini的基础特性和token计数功能,现在明显进入了技术落地阶段。用户引用的两段材料很有价值:第一段展示了Node.js计算token的具体方案,说明用户可能正在开发集成Gemini的应用;第二段提到Gemini1.5Pro支持千万级token,这正是问题的关键答案。不过技术报告缺乏细节这点需要提醒用户,避免ta产生不切实际的预期。注意到用户特别标注"参考站内引用",说明ta需要精确的技术参数。当前最权威的数据源应该是Google官方文档,但用户提供的引用[2]中Gemini1.5Pro的1000万token已经远超常规模型,这个数字需要重点强调。同时要区分不同版本的差异——比如用户引用的countTokens示例用的是gemini-2.0-flash,这个轻量版肯定达不到百万级token。用户没问但可能关心的是:token计算是否包含多模态内容?上下文超限的报错机制是什么?这些在回答的注意事项里补充会很有用。另外ta上次对应用场景感兴趣,这次可以顺势推荐长文本处理的具体案例。技术细节上要特别注意:1.5Pro虽然支持超长上下文,但实际输入可能受API限制;SMoE架构的稀疏激活特性让长上下文成为可能,这点在回答中简要提及即可。最后补充的128K模型是给需要平衡性能和成本的用户准备的,毕竟千万级token的调用成本可能很高。</think>根据技术报告和官方信息,Gemini 模型支持的 Token 长度因版本不同而有显著差异: ### 🔢 各版本 Token 长度上限 1. **Gemini 1.0 系列** - **Gemini Pro 1.0**:标准上下文长度为 **32K tokens** - **Gemini Ultra 1.0**:支持约 **32K tokens**(未明确公开扩展上限) 2. **💥 突破性版本:Gemini 1.5 Pro** - **标准模式**:支持 **128K tokens** - **实验模式**:通过 **稀疏混合专家(SMoE)架构** 实现 **1000万 tokens(10M)** 的超长上下文处理能力[^2][^3] - *技术特点*:稀疏激活机制,仅激活相关专家模块,显著降低计算负载。 3. **Gemini 1.5 Flash** - 轻量级模型,优化响应速度 - 上下文长度 **最高支持 128K tokens** ### ⚠️ 注意事项 1. **实际输入限制** - API 调用时需遵守具体模型的文档限制(如 `gemini-1.5-pro-latest` 默认 128K,需申请权限才能使用 1M+ 模式)。 2. **多模态成本** - 图像/视频等非文本内容会显著增加 Token 计数(例如一张图片可能等价于数百至数千 Token)[^1]。 3. **性能权衡** - 超长上下文可能影响响应速度和计算成本,需按需选择模型。 ### 📊 各版本对比表 | 模型版本 | 标准 Token 上限 | 可扩展上限 | 适用场景 | |------------------|-----------------|------------|-------------------------| | Gemini Pro 1.0 | 32K | - | 常规任务 | | Gemini 1.5 Pro | 128K | **10M** | 长文档/代码/多模态分析 | | Gemini 1.5 Flash | 128K | - | 低延迟交互 | ### 📝 操作建议 - **精确计算 Token**:使用 SDK 的 `countTokens()` 方法预判消耗(参考[^1]的 Node.js 示例)。 - **模型选择策略**: ```mermaid graph LR A[需求分析] --> B{是否需要 >128K?} B -->|是| C[申请 Gemini 1.5 Pro 10M 权限] B -->|否| D[选用 Gemini 1.5 Pro 128K] ``` ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值