CSRF EXEMPT Not working when unfriendly url used

[ranjithsinghu]

If i use csrf_exempt in unfriendly urls its working fine or i have to disable CsrfViewMiddleware. Using csrf_exempt in APP views throwing error "Forbidden (CSRF token missing or incorrect.)"

[tomatohater]

Hi @ranjithsinghu

Would you provide some more details about the issue you are experiencing? Perhaps some code examples? Also, specify which versions of Python, Django and django-unfriendly.

The CSRF token is passed as a field within a form POST and is untouched by unfriendly encryption.

<form action="{{ "/form-handler/"|obfuscate }}" method="post">
    {% csrf_token %}
    <input type="submit" />
 </form>

The above form works the same with or without the obfuscate filter.

Please let me know if you are still having this issue and I will investigate further.

[tomatohater]

Hi @ranjithsinghu

I did some more digging and I was able to replicate this issue. I'm currently investigating a solution.

Thanks for reporting it!

[tomatohater]

@ranjithsinghu I've got a decent solution. I'm working on integrating the solution and then will need to perform thorough regression testing. Give me a few days to push a new release.

Some background... All unfriendly urls point to a single view (deobfusate()), of course, it has no notion of whether or not the target view is csrf_exempt. Since the deobfuscate view is called without csrf_exempt, the CSRFMiddleware fails when posting. So the solution involved checking whether the CSRF middleware is enabled, then re-running process_view() on the target view which will enforce things properly.

[ranjithsinghu]

@tomatohater Thank you for the quick response. As of now, I have wrapped the unfriendly urlpatterns with csrf_exempt, I know it's not the best practice to do. I have used unfriendly for generating payment gateway success and failure URL, the post method get initiated from the gateway so if have to use csrf_except to allow cross-domain request.

[tomatohater]

Great. I have a build that fixes this and I'll push it up tonight.

One another note... you got me thinking about some other scenarios that might be problematic... I'm still thinking about an elegant solution to them all. For example, if a view is protected by @login_required, it properly redirects, but exposes the original URL as the next parameter. Not your issue today, but might be someone else's down the road.

Thanks!

[jmansilla]

Hi!

Was this fix integrated on any released version?

[tomatohater]

Hi @jmansilla Thanks for asking. This is not available in a released version... I did write that fix a while back but never pushed it anywhere. I will check into that again and get it released. Maybe this weekend.

[jmansilla]

Awesome.

As soon as you make such release let me know and I can help with some user testing at least :)

Thanks

On Mon, Feb 5, 2018 at 5:00 PM, Drew Engelson [email protected] wrote:

Hi @jmansilla https://github.com/jmansilla Thanks for asking. This is not available in a released version... I did write that fix a while back but never pushed it anywhere. I will check into that again and get it released. Maybe this weekend.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tomatohater/django-unfriendly/issues/19#issuecomment-363203543, or mute the thread https://github.com/notifications/unsubscribe-auth/AAd044-hKvT544E-3xwNRLTyRALYjhkCks5tR13KgaJpZM4K8415 .

-- Javier Mansilla - CTO www.machinalis.com