Support for integration with drf-spectacular

[DvaMishkiLapa]

I've seen a lot of references to drf-spectacular:

• We might want to change this to drf_spectacular in a future release. #118;
• issue with drf-spectacular #108.

But, using the latest version of drf-spectacular in my project, in conjunction with django-trench, I get a lot of warnings about lack of serializers:

/usr/local/lib/python3.11/site-packages/trench/views/base.py: Error [MFAMethodActivationView]: unable to guess serializer. This is graceful fallback handling for APIViews. Consider using GenericAPIView as view base class, if view is under your control. Either way you may want to add a serializer_class (or method). Ignoring view for now.
/usr/local/lib/python3.11/site-packages/trench/views/base.py: Error [MFAMethodConfirmActivationView]: unable to guess serializer. This is graceful fallback handling for APIViews. Consider using GenericAPIView as view base class, if view is under your control. Either way you may want to add a serializer_class (or method). Ignoring view for now.
/usr/local/lib/python3.11/site-packages/trench/views/base.py: Error [MFAMethodBackupCodesRegenerationView]: unable to guess serializer. This is graceful fallback handling for APIViews. Consider using GenericAPIView as view base class, if view is under your control. Either way you may want to add a serializer_class (or method). Ignoring view for now.
/usr/local/lib/python3.11/site-packages/trench/views/base.py: Error [MFAMethodDeactivationView]: unable to guess serializer. This is graceful fallback handling for APIViews. Consider using GenericAPIView as view base class, if view is under your control. Either way you may want to add a serializer_class (or method). Ignoring view for now.
/usr/local/lib/python3.11/site-packages/trench/views/base.py: Error [MFAMethodRequestCodeView]: unable to guess serializer. This is graceful fallback handling for APIViews. Consider using GenericAPIView as view base class, if view is under your control. Either way you may want to add a serializer_class (or method). Ignoring view for now.
/usr/local/lib/python3.11/site-packages/trench/views/jwt.py: Error [MFAFirstStepJWTView]: unable to guess serializer. This is graceful fallback handling for APIViews. Consider using GenericAPIView as view base class, if view is under your control. Either way you may want to add a serializer_class (or method). Ignoring view for now.
/usr/local/lib/python3.11/site-packages/trench/views/jwt.py: Error [MFASecondStepJWTView]: unable to guess serializer. This is graceful fallback handling for APIViews. Consider using GenericAPIView as view base class, if view is under your control. Either way you may want to add a serializer_class (or method). Ignoring view for now.
/usr/local/lib/python3.11/site-packages/trench/views/base.py: Error [MFAPrimaryMethodChangeView]: unable to guess serializer. This is graceful fallback handling for APIViews. Consider using GenericAPIView as view base class, if view is under your control. Either way you may want to add a serializer_class (or method). Ignoring view for now.
/usr/local/lib/python3.11/site-packages/trench/views/base.py: Error [MFAConfigView]: unable to guess serializer. This is graceful fallback handling for APIViews. Consider using GenericAPIView as view base class, if view is under your control. Either way you may want to add a serializer_class (or method). Ignoring view for now.

I see the needed changes in Swagger UI, but they are not fully customized - missing request bodies, any description.
How much drf-spectacular support is there now? Are there any solutions to the problem I've encountered?

My approximate environment, to understand the situation:

dj-rest-auth==5.0.0
Django==4.2.5
django-allauth==0.55.2
django-cors-headers==4.2.0
django-extensions==3.2.3
django-otp==1.2.2
django-trench==0.3.1
djangorestframework==3.14.0
djangorestframework-simplejwt==5.3.0
drf-spectacular==0.26.4
jsonschema==4.19.0
jsonschema-specifications==2023.7.1

[DvaMishkiLapa]

So far, nothing better than making peculiar hooks of the necessary Views does not come to mind. It works, but it doesn't seem to be the right approach to the situation.

 # views.py

from trench.views.base import MFAMethodActivationView
from drf_spectacular.utils import extend_schema

class TOTPMethodActivationView(MFAMethodActivationView):
    @extend_schema(
        summary="TOTP MFA method activation",
        description="Request a new TOTP activation and get an authentication code",
        request=None,
        responses={
            200: TOTPMethodActivationSuccSerializer,
            400: TrenchErrSerializer
        }
    )
    def post(self, request, *args, **kwargs):
        return super().post(request, method='app', *args, **kwargs)

# urls.py

urlpatterns = [
    ...
    path('auth/app/activate/', TOTPMethodActivationView.as_view(), name='totp-activate'),
    ...
]

[shanx]

Running into the same issue I've found that spectacular provides the possibility to define extensions to provide metadata needed to generate correct schema for libraries not under your control.

There is also a page with extension blueprints which contain extensions already made for often used libraries. Unfortunately trench not being one of them. Tried searching on github also for anyone who might have done this work already, but to no avail.