Define middleware per app?

[Robert Stepanek]

I am new to Django and my project consists of two apps: a typical blog-style web site app and an API app. For the latter, I do not need the majority of middleware that is configured by default. Yet, I can't figure out what's the best approach to use the default middleware stack for the web site app, but not for the other.

If I understand correctly, the Django middleware layer does not take into account which app a view belongs to.

Approaches that come to my mind are: 

1. Define only the common subset of middleware that's used by both apps in the project settings. And define a custom middleware class (e.g. WebPageMiddleware) that combines the bunch of web-site related middleware functions. Then decorate each view in the web site app with this aggregate middleware. The problem I see with this approach is that I would have to replicate the middleware stacking logic that's already handled somewhere in the Django codebase? And it just takes one time to forget adding the decorator to miss a bunch of critical protection middleware.

2. Use two Django projects, one for the web site and one for the API app. That would cleanly separate the settings but it would mean I have to take care of two deployments (probably even a good thing).

Most probably there is a simple solution, but being a Django noob I must just not be able to see it?

Thanks!

Robert

[Jani Tiainen]

Hi,

What is the problem that your’e trying to resolve with middlewares and why you think that you can’t use defaults as is?

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/3a1724c4-d24d-410f-9cc3-2675f7f0acb7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Stepanek]

Hi,

On Wednesday, August 2, 2017 at 8:31:14 PM UTC+2, Jani Tiainen wrote:

Hi,

What is the problem that your’e trying to resolve with middlewares and why you think that you can’t use defaults as is?

For example: the default middleware stack includes session management, CSRF protection and the message middleware. None of this is relevant for my API, but I definitely want to use it for the web site app. Plus: I want separate authentication mechanisms for the two apps.

Meanwhile, I came to the conclusion that using two separate Django projects fits my requirements best. There are other reasons for this, but it has the side benefit that I don't have to figure out how separate the middleware layer.

Cheers,

Robert

[Jani Tiainen]

Well of course you can just have two set of settings (derive common stuff).

So you don't need fully separated projects. If you don't want to.

--

You received this message because you are subscribed to the Google Groups "Django users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/6f3edcea-5c48-4308-83bf-eade199046bf%40googlegroups.com.

[Robert Stepanek]

Ah, I knew I had just overseen a simple solution, being a Django noob!

Thanks for this.

On Thursday, August 3, 2017 at 11:14:58 AM UTC+2, Jani Tiainen wrote:

Well of course you can just have two set of settings (derive common stuff).

So you don't need fully separated projects. If you don't want to.

3.8.2017 11.27 "Robert Stepanek" <robert....@gmail.com> kirjoitti:

Hi,

On Wednesday, August 2, 2017 at 8:31:14 PM UTC+2, Jani Tiainen wrote:

Hi,

What is the problem that your’e trying to resolve with middlewares and why you think that you can’t use defaults as is?

For example: the default middleware stack includes session management, CSRF protection and the message middleware. None of this is relevant for my API, but I definitely want to use it for the web site app. Plus: I want separate authentication mechanisms for the two apps.

Meanwhile, I came to the conclusion that using two separate Django projects fits my requirements best. There are other reasons for this, but it has the side benefit that I don't have to figure out how separate the middleware layer.

Cheers,

Robert

--
You received this message because you are subscribed to the Google Groups "Django users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.