apragacz/django-rest-registration

To be able to return a custom response on successful password reset using data from request.

codehia opened this issue · 2 comments

Checklist

The problem I am trying to solve

I am trying to return serialized details of the user who has successfully reset the password. After going through the documentation, I tried to implement a method with SUCCESS_RESPONSE_BUILDER but this method doesn't have access to the request object or the request.data.

Solution I propose

There should be a way to be able to respond with a custom response, using the request object. The solution could be to simply be able to accept the request object in the build_default_success_response method. or being able to use a custom serializer, just like SEND_RESET_PASSWORD_LINK_SERIALIZER_CLASS

Hi @codehia,

Thank you for proposing this feature.

I see few comments/issues with this solution:

  • SEND_RESET_PASSWORD_LINK_SERIALIZER_CLASS is used only for input validation (not for output - get_ok_response/SUCCESS_RESPONSE_BUILDER is used instead there)
  • request object will not contain the user in case of reset password (it is being obtained later via SEND_RESET_PASSWORD_LINK_USER_FINDER)
  • Even if we would replace that one with user (which would be optional as not always it can be provided, see RESET_PASSWORD_FAIL_WHEN_USER_NOT_FOUND setting) this would mean that get_ok_response semantics changes a lot; it is something which would need to be redesigned to match your purpose (more about that below).

Therefore my proposal would be to:

  • add extra_data builder/processor for reset password (SEND_RESET_PASSWORD_SUCCESS_EXTRA_DATA_BUILDER?), which would get both request and user. With that, one can provide custom builder to generate auxiliary custom message containing info about the user and put it in extra_data, which will be passed into SUCCESS_RESPONSE_BUILDER.
  • and then (optionally) one can use SUCCESS_RESPONSE_BUILDER which would use that message from extra_data (if set) and replace the default static message with that one.

The alternative would be to completely rethink how get_ok_response/SUCCESS_RESPONSE_BUILDER should work and IMO the value/cost is too low to engage in that. Obviously, if you have an brilliant idea how to do it (with a transition path from the old behavior) I'm happy to hear about it.

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.