CommonMiddleware DISALLOWED_USER_AGENTS logic

[michael....@gmail.com]

Dear, folks!

I wonder is there some architecture rule that doesn't allow CommonMiddleware raise PermissionDenied exception?

Right now if django-developer wants to use DISALLOWED_USER_AGENTS setting than all disallowed clients get empty page with simple header "Forbidden".
And there is no way to change this behavior (except wright your own middleware class of cause).

Thanks!

--
Mikhail Nacharov

[François Schiettecatte]

What about the 403 handler ?

https://docs.djangoproject.com/en/1.8/ref/urls/#handler403

François

> --
> You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/f43d50ac-8d79-4a14-a71b-d468902779ec%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Tim Graham]

I don't think there's an "architecture rule" that would prevent that design. It looks like DISALLOWED_USER_AGENTS has been around since 2005, but handler403 wasn't added until 1.4. Since the docs for the setting say "Use this for bad robots/crawlers." I guess it's implied that customizing the response isn't particularly useful. You could try writing a patch with your suggested approach and see if you run into any issues. I guess it might be a bit slower performance-wise.

[Aymeric Augustin]

DISALLOWED_USER_AGENTS predates the addition of the 403 handler and wasn't updated to take advantage of it.

I believe it would make sense to raise Http403 there. Would you mind filing a ticket on https://code.djangoproject.com/?

Thanks!

-- 

Aymeric.

PS: perhaps we should audit the code base for other hardcoded responses.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/BBF5D8AA-BD06-47AC-BFD6-01281A392A44%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Aymeric.

[François Schiettecatte]

Aymeric

Sure, I will do that later today, I’ll also take a look at the code to see what needs to be done.

François

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANE-7mU8POKp6n%2BUc7Chtvxw8st9z%3DbBzA_ocpOEoeY2p6gSEw%40mail.gmail.com.

[François Schiettecatte]

Aymeric

I have created the ticket https://code.djangoproject.com/ticket/25017 with suggested fix.

Let me know if you need more input/information from me.

Best regards

François

> On Jun 23, 2015, at 9:15 AM, Aymeric Augustin <aymeric....@polytechnique.org> wrote:
>

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANE-7mU8POKp6n%2BUc7Chtvxw8st9z%3DbBzA_ocpOEoeY2p6gSEw%40mail.gmail.com.

[Shai Berger]

On Tuesday 23 June 2015 15:50:14 Tim Graham wrote:
> I don't think there's an "architecture rule" that would prevent that
> design. It looks like DISALLOWED_USER_AGENTS has been around since 2005,
> but handler403 wasn't added until 1.4. Since the docs for the setting say
> "Use this for bad robots/crawlers." I guess it's implied that customizing
> the response isn't particularly useful.

Actually, I suspect it would be harmful. I've seen too many cases of people
writing their site to reject browsers they don't like. I don't want Django to
support this malpractice; even IE6 deserves a chance to try to cope with the
site, rather than a "forbidden, go away".

Could any of the supporters elaborate on the use-case?

Thanks,
Shai.

[Aymeric Augustin]

2015-06-24 1:56 GMT+02:00 Shai Berger <sh...@platonix.com>:

Could any of the supporters elaborate  on the use-case?

Just to clear a possible confusion -- this feature already exists, it was added in 2005 to filter out unwanted crawlers by blacklisting their user-agent.

The proposal here is to use the custom 403 error view defined by handler403, which may be useful e.g. for custom logging.

-- 

Aymeric.

[Shai Berger]

To clarify, I don't object to logging or other custom actions, and it was clear to me that the feature of DISALLOWED_USER_AGENTS already exists; my concern is that the OP's motivation seems to have been to control the design of the error page, which indicates an intention to show it to humans using browsers.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[François Schiettecatte]

Shai

Sounds right, but you can do that already with handler403. The change proposed changes the handling of the user agent to raising PermissionDenied exception rather than returning a HttpResponseForbidden().

François

> --
> You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/746ABFB5-093F-4C73-BDD4-D547C1FB8F58%40platonix.com.

[Shai Berger]

On Wednesday 24 June 2015 15:15:35 François Schiettecatte wrote:
>
> Sounds right, but you can do that already with handler403. The change
> proposed changes the handling of the user agent to raising
> PermissionDenied exception rather than returning a
> HttpResponseForbidden().
>

That is exactly the point: Before the proposed change, you *cannot* control
the page returned for disallowed user agent via handler403(), because that
handler is called when the PermissionDenied exception is raised, not when a
Response object is returned.

Shai.

[Nacharov Mikhail]

Well, I know that block specific browsers is a bad idea, but sometimes it's necessary to do.
For example, creating modern "single-page" web application for restricted number of users. I would prefer show in old browsers something like "Sorry, your browser is too old to use this site, please install one of them {{ modern browsers }}" than page with wrong layout and js errors.
I don't know is it right to do with DISALLOWED_USER_AGENTS setting, may be this logic must be shown at application or page level.

среда, 24 июня 2015 г., 15:22:26 UTC+5 пользователь Shai Berger написал:

To clarify, I don't object to logging or other custom actions, and it was clear to me that the feature of DISALLOWED_USER_AGENTS already exists; my concern is that the OP's motivation seems to have been to control the design of the error page, which indicates an intention to show it to humans using browsers.

[Aymeric Augustin]

2015-06-24 23:48 GMT+02:00 Shai Berger <sh...@platonix.com>:

That is exactly the point: Before the proposed change, you *cannot* control
the page returned for disallowed user agent via handler403(), because that
handler is called when the PermissionDenied exception is raised, not when a
Response object is returned.

I agree with that.

However handler403 can do other things in addition to returning a custom error

page e.g. logging. I would find it more consistent that, whenever Django needs

to return a 403, it does so by raising Http403.

--

Aymeric.