基于Django/GraphQL/Apollo/Vue的角色授权实现方案咨询

Hey there! Let's break down your role-based authorization options for your Django + Graphene + Vue + Apollo stack—each approach has its place, so I'll walk you through them with practical examples and pros/cons to help you decide:

Django's native authentication system (Users, Groups, Permissions) is rock-solid, and Graphene plays nicely with it right out of the box. This is usually the most straightforward starting point.

You can add permission checks directly in your Graphene resolvers using Django's built-in decorators or manual group/permission checks:

from graphene_django import DjangoObjectType
from django.contrib.auth.decorators import permission_required
from django.utils.decorators import method_decorator
from myapp.models import Post

class PostType(DjangoObjectType):
    class Meta:
        model = Post

class Query(graphene.ObjectType):
    all_posts = graphene.List(PostType)
    post_by_id = graphene.Field(PostType, id=graphene.ID())

    @method_decorator(permission_required('myapp.view_post'))
    def resolve_all_posts(self, info, **kwargs):
        user = info.context.user
        # Add role-specific filtering
        if user.groups.filter(name='Editors').exists():
            return Post.objects.all()
        # Regular users only see their own posts
        return Post.objects.filter(author=user)

    def resolve_post_by_id(self, info, id):
        user = info.context.user
        try:
            post = Post.objects.get(pk=id)
        except Post.DoesNotExist:
            raise Exception("Post not found")
        
        # Enforce ownership or editor access
        if user.is_superuser or post.author == user or user.groups.filter(name='Editors').exists():
            return post
        raise Exception("You don't have permission to view this post")

• Pros: No extra dependencies, leverages Django's battle-tested auth ecosystem, easy to maintain.
• Cons: Permission logic can get repetitive across resolvers in large projects (you can mitigate this with custom decorators or mixins).

If you're familiar with Django REST Framework's permission system, you can reuse it with Graphene by wrapping the GraphQL view with DRF's auth classes. This works great for view-level permissions, and you can still add resolver-level checks for finer control.

Here's how to set it up:

from graphene_django.views import GraphQLView
from rest_framework.permissions import IsAuthenticated, DjangoModelPermissions
from rest_framework.authentication import SessionAuthentication, TokenAuthentication

class DRFAuthenticatedGraphQLView(GraphQLView):
    authentication_classes = [SessionAuthentication, TokenAuthentication]
    permission_classes = [IsAuthenticated, DjangoModelPermissions]

# Update your urls.py to use this custom view
urlpatterns = [
    path('graphql/', DRFAuthenticatedGraphQLView.as_view(graphiql=True)),
]

• Pros: Reuses DRF's mature permission system (including custom permission classes you might already have).
• Cons: DRF's permissions are primarily view-level—you'll still need resolver checks for per-object or field-level access.

If your project uses Graphene Relay, you can enforce permissions directly in Relay nodes, which is perfect for granular object-level access. On the frontend, Apollo Client makes it easy to pass authentication tokens in every request.

Backend (Relay Node Permission Check) #

from graphene_django import DjangoObjectType
from graphene import Node
from myapp.models import Post

class PostNode(DjangoObjectType):
    class Meta:
        model = Post
        interfaces = (Node,)

    @classmethod
    def get_node(cls, info, id):
        try:
            post = cls._meta.model.objects.get(pk=id)
        except cls._meta.model.DoesNotExist:
            raise Exception("Post not found")
        
        user = info.context.user
        # Enforce role-based access to the node
        if user.is_superuser or post.author == user or user.groups.filter(name='Editors').exists():
            return post
        raise Exception("You don't have permission to view this post")

Frontend (Apollo Client Auth Setup) #

import { ApolloClient, InMemoryCache, createHttpLink } from '@apollo/client';
import { setContext } from '@apollo/client/link/context';

const httpLink = createHttpLink({
  uri: '/graphql/',
});

// Attach auth token to every request
const authLink = setContext((_, { headers }) => {
  const token = localStorage.getItem('authToken');
  return {
    headers: {
      ...headers,
      authorization: token ? `Bearer ${token}` : "",
    }
  };
});

const client = new ApolloClient({
  link: authLink.concat(httpLink),
  cache: new InMemoryCache(),
});

• Pros: Clean, granular permission control for Relay nodes; Apollo's auth link handles token passing uniformly.
• Cons: Relay has a steeper learning curve—only worth it if you're already using Relay's other features (like pagination, mutations).

Tools like vue-kindergarten help you control UI visibility and route access on the Vue side, but they should never replace backend authorization (users can easily bypass frontend checks). Think of this as a user experience enhancement, not a security measure.

Example usage in Vue:

import { Kindergarten, Child, permission } from 'vue-kindergarten';

// Define user permissions based on data fetched from the backend
const child = new Child({
  can: {
    viewAdminPanel: (child) => child.user.is_superuser,
    editPosts: (child) => child.user.groups.includes('Editors') || child.user.is_superuser,
  },
  user: currentUser, // User data from your auth store
});

Vue.use(Kindergarten, { child });

In your component:

<template>
  <div>
    <button v-if="$kindergarten.can('editPosts')" @click="openEditModal">Edit Post</button>
    <router-link v-if="$kindergarten.can('viewAdminPanel')" to="/admin">Admin Panel</router-link>
  </div>
</template>

• Pros: Quick to implement frontend UI restrictions, improves user experience by hiding unavailable actions.
• Cons: No security value on its own—always pair with backend permission checks.

• Start with Django's built-in auth + Graphene resolver checks: It's the most low-effort, secure option for your stack.
• Add DRF permissions if you need view-level guards: Great for enforcing authentication or broad model permissions across all GraphQL queries/mutations.
• Use Relay auth only if you're already using Relay: It's a clean fit but overkill otherwise.
• Pair with vue-kindergarten for frontend UI control: But never rely on it as your only authorization layer.

内容的提问来源于stack exchange，提问作者Taylor