Django静态文件系统之meida文件,Django配置文件介绍,RBAC权限系统

Ⅰ Django静态文件系统之meida文件

【一】问题引入

• 一般常用的静态文件：static
• 但是，媒体文件:图片，视频，音频……
• 会随着用户改变而改变，不应该作为静态文件来使用
• 应该是媒体资源
• 于是Django提供了另一种静态文件语法meida文件

【二】配置使用

• 在Django的settings里面 DEBUG —>开发者模式:报错会展示报错信息
• 如果要使用静态资源就需要开启debug
• 但是生产环境中应该关闭 debug模式 —>静态资源就用不了了
• 还想用静态资源 –> 有其他的技术手段可以帮助我们转发静态资源—> nginx

【三】STATIC语法

【1】开启DEBUG语法

# 开发者模式 按CTRL+s 会自动重启
# 如果报错就会提示完整的错误信息
# 如果变成FALSE 前端只会显示404
DEBUG = True

【2】在settings中进行配置

# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/5.0/howto/static-files/
# 静态文件路由地址
STATIC_URL = 'static/'


# 加一个静态文件路径 用来配置我们自己定义的静态文件资源路径的
STATICFILES_DIRS = [
    # 如果不加这句话 静态资源在加载的时候只能加载 app下面的静态文件资源
    # 加了之后，就能加载到根目录下的静态文件资源了
    os.path.join(BASE_DIR, 'static')
]

【四】MEDIA文件

【1】media文件配置

# media 资源配置
MEDIA_URL = '/media/'

# 仿照上面配置media的资源路径
MEDIA_ROOT = [
    # 如果不加这句话 静态资源在加载的时候只能加载 app下面的静态文件资源
    # 加了之后，就能加载到根目录下的静态文件资源了
    os.path.join(BASE_DIR, 'media')
]

【2】配置路由映射规则

• 固定写法 media

from django.urls import path,re_path
from django.views.static import serve

urlpatterns = [
    re_path(
        # url路径
        '^media/(?P<path>.*)', 
        
        # 使用django的服务系统
        serve, 
        
        # media 文件夹的路径
        {"document_root": settings.MEDIA_ROOT}
           ),
]

• 使用path 也能配置

from django.urls import path,re_path
from django.views.static import serve

urlpatterns = [
    path(
        # url 路径
        "media/<path:path>",
        # 使用Django的服务系统
        serve,
        # media 文件夹的路径
        {"document_root": settings.MEDIA_ROOT}
    ),
]

【3】使用

• models.py
• 重点是在媒体对象

from django.db import models
from django.contrib.auth.models import AbstractUser


class User(AbstractUser):
    permission = models.ManyToManyField(
        to="Permission"
    )

    class Meta:
        db_table = "user"



class Book(models.Model):
    title = models.CharField(
        max_length=255
    )
    price = models.IntegerField(

    )

    # 以前 文件的路径是使用  CharField
    # 存的内容是当前 这张图片的静态资源路径
    # /static/avatar/default.png/
    # ImageField 使用前先安装 Pillow 模块
    # pip install pillow
    img = models.ImageField(
        # 会自动将文件上传到 /media/book/
        upload_to="book",
        verbose_name="图书封面",
        help_text="图书封面"
    )

    del_tag = models.BooleanField(default=False)

    class Meta:
        db_table = "book"


class Permission(models.Model):
    permission_name = models.CharField(max_length=255, verbose_name="权限名称")

    class Meta:
        db_table = "permission"

Ⅱ Django配置文件介绍

【一】来自于 django.conf里面的settings

• 写每一个项目的时候肯定都要有配置文件
• 研究 django.conf有哪些特殊的地方

【二】入口

• from django.conf import settings
• 进入源码中 发现 settings 其实是 LazySettings 类的对象

settings = LazySettings()

• from django.conf import settings 从这里进去源码
• from django.conf import global_settings

# 将 全局 的global_settings 先加载到 setting 对象中
# 然后 在将自己 定义的  settings.py 文件里面的所有参数加载进去
# 最后就将所有的配置项加载到 全局的 setting 对象中了

class Settings:
    def __init__(self, settings_module):
        # 更新全局的global settings 配置
        # update this dict from global settings (but only for ALL_CAPS settings)
        # 从global_settings 遍历每一个参数项
        # dir(global_settings) dir 查看变量的属性名

        for setting in dir(global_settings):
            # 将每一个参数键 大写
            if setting.isupper():
                # setattr设置值
                setattr(self, setting, getattr(global_settings, setting))
		...
         ...
        
        # 遍历每一个参数项 来自于你自己定义的配置项参数名
        for setting in dir(mod):
            if setting.isupper():
                # 从自己的配置文件中获取到 键对应的值
                setting_value = getattr(mod, setting)

                if (setting in tuple_settings and
                        not isinstance(setting_value, (list, tuple))):
                    raise ImproperlyConfigured("The %s setting must be a list or a tuple. " % setting)
                # 向 全局的 settings 对象中设置 自己定义的属性值
                setattr(self, setting, setting_value)
                self._explicit_settings.add(setting)

【三】修改配置文件名

• 先将 settings.py 改为自己想取的名字 如：develop.py

【1】直接启动项目会报错

ModuleNotFoundError: No module named 'DjangoProjectLast.develop'

【2】第一步修改 manage.py main 下面的第一行代码

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'DjangoProjectLast.develop')

【3】原本的启动配置不生效

（1）方案一 删除原本的配置新增一个配置

（2）方案二 主动修改 settings 文件启动位置

Ⅲ RBAC权限系统

【一】什么是RBAC

【1】概念

• RBAC 是基于角色的访问控制（Role-Based Access Control ）
• 在 RBAC 中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。
• 这就极大地简化了权限的管理。
• 这样管理都是层级相互依赖的，权限赋予给角色，而把角色又赋予用户，这样的权限设计很清楚，管理起来很方便。

【2】应用

• RBAC - Role-Based Access Control
• Django的 Auth组件 采用的认证规则就是RBAC

（1）内部系统

• 专门做人员权限管理的系统（CRM系统）都是公司内部使用
  • 所以数据量都在10w一下，一般效率要求也不是很高

（2）用户分类

• 用户量极大的常规项目，会分两种用户：
  • 前台用户(三大认证)
  • 后台用户(BRAC来管理)

（3）结论

• 没有特殊要求的Django项目可以直接采用Auth组件的权限六表
• 不需要自定义六个表，也不需要断开表关系，单可能需要自定义User表

【3】前后台权限控制

• （1）后台用户对各表操作，是后台项目完成的
  • 我们可以直接借助admin后台项目（Django自带的）
• （2）后期也可以用xadmin框架来做后台用户权限管理
• （3）前台用户的权限管理如何处理
• 定义了一堆数据接口的视图类
  • 不同的登录用户是否能访问这些视图类，能就代表有权限，不能就代表无权限
• 前台用户权限用drf框架的
  • 三大认证

【二】RBAC0模型

简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。

RBAC0模型如下:

这是权限最基础也是最核心的模型，它包括用户/角色/权限,其中用户和角色是多对多的关系，角色和权限也是多对多的关系。

用户是发起操作的主体，按类型分可分为2B和2C用户，可以是后台管理系统的用户,可以是OA系统的内部员工，也可以是面向C端的用户，比如阿里云的用户。

角色起到了桥梁的作用，连接了用户和权限的关系，每个角色可以关联多个权限，同时一个用户关联多个角色，那么这个用户就有了多个角色的多个权限。有人会问了为什么用户不直接关联权限呢？

在用户基数小的系统，比如20个人的小系统,管理员可以直接把用户和权限关联，工作量并不大，选择一个用户勾选下需要的权限就完事了。

但是在实际企业系统中，用户基数比较大，其中很多人的权限都是一样的，就是个普通访问权限，如果管理员给100人甚至更多授权,工作量巨大。

这就引入了"角色(Role)"概念,一个角色可以与多个用户关联，管理员只需要把该角色赋予用户，那么用户就有了该角色下的所有权限,这样设计既提升了效率,也有很大的拓展性。

一句话概括就是：权限系统维护的是人和可进行行为的关联关系。

页面权限：即用户登录系统可以看到的页面,由菜单来控制,菜单包括一级菜单和二级菜单,只要用户有一级和二级菜单的权限,那么用户就可以访问页面

操作权限： 即页面的功能按钮，包括查看、新增、修改、删除、审核等，用户点击删除按钮时，后台会校验用户角色下的所有权限是否包含该删除权限，如果是，就可以进行下一步操作，反之提示无权限。有的系统要求"可见即可操作"，意思是如果页面上能够看到操作按钮，那么用户就可以操作，要实现此需求，这里就需要前端来配合，前端开发把用户的权限信息缓存，在页面判断用户是否包含此权限，如果有，就显示该按钮，如果没有，就隐藏该按钮。某种程度上提升了用户体验，但是在实际场景可自行选择是否需要这样做。

数据权限：数据权限就是用户在同一页面看到的数据是不同的，比如财务部只能看到其部门下的用户数据，采购部只看采购部的数据，在一些大型的公司，全国有很多城市和分公司