Re: #14770: Set cookies from request: Design decision needed
On Wed, Nov 24, 2010 at 4:20 PM, Jacob Kaplan-Moss wrote:
> Okay, I think we're narrowing in on things. Just so I'm clear, you've
> got a view that sets a message towards the beginning and then displays
> that message in the template *on the very same request*, yes?
Basically, yes.
> So in essence you're doing something like::
>
> def my_view(request):
> set_some_messages(request)
> response = render_to_response(...)
> set_some_cookies(response)
> return resp
>
> But you'd like to collapse `set_some_messages()` and
> `set_some_cookies()` into a single function, so something like::
>
> def my_view(request):
> response = render_to_response(...)
> set_some_cookies_and_messages(request, response)
> return response
>
> Does that about some it up?
It's a simplification, but yes.
> Because if so, the problem has nothing to do with cookies. It's
> happening because the messages are being fetched in the template,
> which you're rendering into a response "too early". This in fact has
> nothing to do with the request/response cycle or anything, but just
> with the fact that you're fetching messages from a template into a
> response. But remember: you can get a response without rendering a
> template, so you could do something like this::
>
> def my_view(request):
> response = HttpResponse()
> set_some_cookies_and_messages(request, response)
> response.write(render_to_string(...))
> return response
>
> render_to_response is a shortcut that collapses a bunch of steps for
> the common case, but does so at the expense of inflexibility.
Right. I do know that, but as I said before, this example is a
simplification. Just for completeness, I'll lay it all out for you.
I'm sure it won't change your mind, but hopefully it'll more clearly
demonstrate the dilema.
I have a set of views that I'd like to potentially show one or more
messages to the user. These messages will be created by one or more
functions that are registered into a module I wrote that finds these
special functions and provides a decorator. The decorator is applied
to the views where the messages should be displayed. These messages
are things like, "Your account will expire soon", and since they'll
keep displaying until the user renews, I provide a link for them to
hide the message. That hiding is accomplished by setting a cookie. I'm
also using a cookie to basically cache the fact that the user has
passed the test with no message and therefore doesn't need the check
for the remainder of their browser session. So, this decorator looks
something like:
def check_alerts(func):
def decor(request):
for alert in registered_alerts:
alert(request)
return func(request)
return decor
An example alert function might be:
def account_expiring(request):
if request.COOKIES.get('account_expiring') == 'no':
return
if request.user.get_profile().is_about_to_expire():
message.warning(request, "Your account will expire soon, yo")
else:
request.set_cookie('account_expiring', 'no')
That's obviously not exactly the code, but that's the idea. It works
great, and is the least convoluted thing I could come up with. I
thought of creating an empty response in the decorator, passing it to
the alert functions, then passing it to my decorated views and making
them use it instead of what they're already doing. But some are
generic views and some are not my code, so it'd be very difficult to
hack them all into accepting another argument, or using the decorator
to capture the response given by the view, then transfer cookies from
my fake response to the real one before returning it. All of that is
possible, but seemed more hacky to me than having the ability to set a
cookie from the request. I just thought that if I could get myself
into this situation then I'm sure many others have even more complex
systems, and since there'd already been a couple of solutions proposed
in the community, that perhaps it'd be useful for the framework to
have an easy solution.
> PS: Oh, and BTW, the reason you're seeing this problem with messages,
> specifically, is that messages really aren't designed to be produced
> and consumed in the same view. The canonical use case for messages is
> for use in the redirect-after-POST pattern::
>
> def my_view(request):
> form = MyForm(request.POST or None)
> if form.is_valid():
> form.save()
> messages.add_message("It worked!")
> return redirect('success')
> ...
>
> If you're producing and consuming messages in the same request you
> might want a different tool, or you'll need to work around the
> assumptions that the messages framework makes.
Yeah. Some of these follow that pattern, and some produce and consume
in the same view. The messages framework seems to handle all of this
just fine. Perhaps I'm missing something, but my tests are passing and
th
Re: #14770: Set cookies from request: Design decision needed
Thanks for that example Ian. That's exactly it. I'm doing it from a view decorator, but in effect it's the same. I need to call a function from a view that needs to be able to set messages and potentially set other cookies. I need the request object to set the messages, and the response to set the cookies. This is already confusing in my opinion as the messages framework potentially uses cookies, but that's beside the point. If I get the response then pass it to my function, any messages it sets will not be shown to the user on that response, but would instead be saved and shown to the user on the subsequent request. So I need a way to be able to cause cookies to be set from such a function but before rendering the response. I thought about having said function return some crazy list of dicts that I'd then pass to response.set_cookie later, but that seemed even more hacky. Jacob: I'm willing to accept that this situation is rare and that your objections are valid. I can accomplish this via a middleware, and will continue to do so. But I do still wish for a more simple and supported way to deal with this situation. I can see Ian's delayed execution pattern working just fine, but it's less readable in my opinion. Thanks again, Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #14770: Set cookies from request: Design decision needed
On Wed, Nov 24, 2010 at 2:23 PM, Jacob Kaplan-Moss wrote: > Ugh, I'm -1 on this. It confuses requests and responses, and abstracts > away a *very* important aspect of how HTTP actually works. Doing this > is semantically unclean and binds together two parts of the > request/response cycle that are separate by design. I don't at all > like the idea of obscuring the truth about how HTTP actually works. > > There's a tiny chance I might be able to be convinced to change my > mind, but you'll have to back up and explain exactly what it is you're > trying to do that's impossible without this hack. There are just situations where you need to have the ability to cause a cookie to be set, but can't yet create the response object. In my case I was creating a small framework for registering functions that would check for and set messages via the messages framework. If I called the view and passed the request and response to these functions, the messages they'd set wouldn't show until the next response because the page would already have been rendered. If I could stick to only passing in a request then I could put off getting the response object until later, my functions could set cookies, and the messages would show up at the right time. In David Cramer's post on the subject[0] he mentions needing this when building an authentication service. I'm sure there are many other use cases and at least as many hacks that have been put into place to get around this limitation. I'm certainly not married to this implementation. It made sense to me to offer methods with the exact same signature on the request as the response, but I can see you point about confusion. Since they accomplish the same outcome, I don't think any confusion would result in bugs, but it could, so I understand. Would you be more open to a completely separate cookie handling component that the HttResponse.set_cookie and HttResponse.delete_cookie called for backward compatibility? I have no idea how such a thing would work or maintain state through a request-response cycle, but if an alternate new API were created through which one always interacted with cookies, perhaps that would assuage some confusion concerns. I mainly just need to be able to set a cookie from anywhere in a view, or in any decorator or function that deals with the view process. The only way I've found to do that is to use a middleware that monkeypatches the request and then copies whatever was added there to the resopnse on its way out. If there's another way, I'm very happy to hear it. The thing I like most about attempting contributions like this to Django is the learning experience. Thanks for the feedback! Paul [0] http://www.davidcramer.net/code/62/set-cookies-without-a-response-in-django.html -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
#14770: Set cookies from request: Design decision needed
Hi all, I created ticket #14770 (http://code.djangoproject.com/ticket/14770) because I ran into a situation this week where I only had access to the request, but needed to set a cookie. As the ticket says, I did solve this problem with a middleware, but I couldn't think of a reason not to include this ability in core. So, I wrote up a patch complete with docs and tests. Any feedback you might have would be very much appreciated. Thanks, Paul McLanahan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Feedback for #13849 (csrf referer checking)
On Wed, Jun 30, 2010 at 12:16 PM, Luke Plant wrote: > With Django's sessions and login method, you *do* have a session on the > login page itself i.e. before the actual login step. So you need to > worry about session fixation etc. Even if not, and you are using your > own login method, there is still "login CSRF" to worry about [1]. > > Without the check for a HTTPS referer, you are wide open to a MITM > attacker doing CSRF on your HTTPS connections. The check isn't "erring > on the side of caution" — that was what I *previously* thought it was, > having not thought through the possible attacks, but in fact it is > *absolutely essential*. Without it, you should consider your site as > having the same level of protection as an HTTP site. > > Yes, there are still some benefits to HTTPS (passwords not sent in > plaintext), but you certainly don't have the kind of protection that > would be expected in HTTPS, and in the general case you might find that > all benefits are destroyed by what a successful attacker might be able > to achieve (setting passwords etc.) unless you are extremely careful and > have closed every possible loophole. For these reasons, changing this > behaviour — or even allowing it as an option — would be craziness for a > general purpose framework. An option is a bad idea in general, because > it is global — and we certainly do *not* want this hole punched in the > admin site. > > If you can really live with the security holes you want to make, that is > absolutely up to you. You can write your own middleware, and ensure its > suitability for your needs. But I cannot see an argument for supporting > this as an option out of the box. Fair enough. If the situation is potentially really this dire, as you've convinced me that it is, then leaving it alone is the way to go. Thanks again for your time. Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Feedback for #13849 (csrf referer checking)
Hi Luke, Thanks for the reply. See my comments below. On Wed, Jun 30, 2010 at 7:45 AM, Luke Plant wrote: > In addition, having looked at the links that Tino sent, I now think > there is a very big advantage to not allowing HTTP -> HTTPS POST > requests by default, even ignoring the CSRF issue. I agree that not allowing them by default is good, but I think that having the option to allow them is also good. I like the default behavior as it is, as it's inline with our "secure by default" philosophy. But in our situation, I'm just not as concerned with this because our only other alternative is to turn off CSRF checking for these views, which I think is an even worse idea. I will say that I'm not sure our situation even benefits from CSRF protection. We're doing this on a login page (so they shouldn't have a session at all yet), and on other pages on which we ask users to submit their password (password change, username change, etc.). The later all result in confirmation emails, which should prevent fraud. We're still hesitant to remove CSRF protection from these views though just in case we've done something else that may open a hole that the CSRF mechanism will close. Like you said, we're trying to "err on the side of caution." > BTW, if you are using Django's sessions over HTTPS, then you need to > have SESSION_COOKIE_SECURE = True, otherwise you are wide open to an > HTTP-snooper hijacking HTTPS sessions. However, with > SESSION_COOKIE_SECURE = True, sessions will not work over HTTP. This > means you need to serve your whole site over HTTPS. I only just > realised this for one of my own sites. We probably need to document > that more clearly, but I'm not sure how. I can appreciate this as well, but we definitely don't need for the whole site to be secure. No personal or sensitive data is transmitted beyond the user's email address and password. So we'd really like to only secure the transmission of that info. If an attacker were to hijack one of our user's sessions, secure or otherwise, they'd just be able to use our site w/o paying for a few hours. If they tried to change the username or password, a confirmation email system would prevent the change. As with most web security techniques, we're just trying to be as secure as we can be without being overly inconvenient to our users, while not being low-hanging fruit for would-be attackers. If you're all vehemently opposed to allowing the possibility of using the CSRF middleware and submitting over SSL from a non-SSL page, then we'll be fine. I just still think that this is a valid thing for a web app to want to do, and thus would be a good option for a user of the CSRF system to have. Thanks again, Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Feedback for #13849 (csrf referer checking)
On Tue, Jun 29, 2010 at 11:40 AM, TiNo wrote: > This is supposedly potentially insecure, see: > http://samsclass.info/defcon.html (bottom of the page) > or http://vimeo.com/7618090 from 2:45' > Just my 2 cents, > Tino Thanks for the reply. I realize that this attack is an outside possibility. Were I running Facebook I would be concerned. If this is a larger threat than it seems then this should definitely stay in Django to discourage people like us. However, poisoning an arp cache to insert an attacker machine as a proxy which can then rewrite "https" to "http" in our page code isn't trivial, and if someone is doing it, I'd imagine they've got a larger and more lucrative target in mind. That said, we'll definitely keep it in mind and look at securing the pages containing the forms as well. For now though, I think the option of submitting a form over SSL from a non-SSL page would be nice to have. Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Feedback for #13849 (csrf referer checking)
Hi, We ran into an issue with the django.middleware.csrf.CsrfViewMiddleware handling of secure posts. We'd like to be able to display a form on an insecure page, but have the form post occur over an SSL protected connection. This is currently impossible with the CSRF middleware enabled due to strict referer checking for secure posts. I filed ticket #13849[0] about this, but have not yet provided a patch as I'd rather wait to hear what you all have to say. Our current solution (to avoid patching our Django) is to subclass the middleware, override the process_view method, and temporarily replace "http://"; with "https://"; in the referer in request.META if it's a secure post [1]. This allows the hostname check to proceed, but not deny the post merely because it came from an insecure page, and not force us to remove CSRF protection from all such views. This solution, while it's working for now, is obviously not optimal. We'd like for Django to possibly provide an option (setting) to allow for the less strict check, or back off on checking for secure posts coming from secure referers at all. The check for same domain is good, but the check that the referer specifically start with "https://"; seems excessive. The comments in the code above said check[2] suggests that the original developer thought it may be too strict as well. If it's decided that this is worth addressing and a preferred solution is determined, I'd be more than happy to provide a patch. I just didn't want to go to the trouble of updating the middleware, writing tests, creating a new setting, and writing docs for that setting, before I heard from you guys whether this was even a good idea. Thanks, Paul [0] http://code.djangoproject.com/ticket/13849 [1] http://dpaste.com/hold/212803/ [2] http://code.djangoproject.com/browser/django/trunk/django/middleware/csrf.py#L134 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Feedback requested: Multi-db database routing
On Wed, Jan 20, 2010 at 11:06 AM, Russell Keith-Magee wrote: > I've just uploaded a new patch improving the multi-db interface. This > patch introduces a way to easily configure the database selection > process, and enables you to assign a database selection mechanism to > models not under your control (e.g., changing database usage for the > contrib.auth app). Brilliant! Thanks Russell. +1 Paul McLanahan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: preventing brute forcing passwords
On Thu, Dec 17, 2009 at 2:30 PM, Tom wrote: > Hello Everyone, > > I noticed that Django's contrib.auth doesn't provide a mechanism for > detecting a password brute force attack. This is necessary for a > couple projects I'm working so I have to implement some kind of > solution and would really like to do it in such a way that it could > get contributed back to the community. I'd like to propose possible > two variants to the way that system works and would appreciate > feedback. Have you taken a look at Simon's work on the subject? http://github.com/simonw/ratelimitcache/ I'm using it with much success on some of my projects. It's definitely worth considering before doing a lot of extra work in another direction. hth, Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Multiple database support: Request for feedback and testing
On Fri, Dec 4, 2009 at 5:51 PM, Yuri Baburov wrote:
> #Isn't it django.contrib.auth? I'm not sure if collision with
> 'my.superstuff.auth' might happen or not.
It is, but the app registry mechanism in the
'django.db.models.loading' module only uses the "app label", which is
the part of the app module name after the last '.'. So, when using
django.db.models.get_model, you would pass it 'auth'. So if you named
your app 'my.superstuff.auth', the app used when calling
get_model('auth', 'user') might not be the one you'd expect.
That's my understanding anyway. I agree that it seems potentially fragile.
Paul
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Multiple database support: Request for feedback and testing
On Fri, Dec 4, 2009 at 2:34 PM, Tobias McNulty wrote:
> What would this look like? I'm picturing another setting (bleh) that
> maps apps and/or models to specific databases. Name choices aside,
> this might look something like:
>
> DATABASE_USING = {
> 'django.contrib.auth': 'default',
> 'myapp': 'database1',
> 'myapp2': {
> 'Model1': 'database2',
> 'Model2': 'database3',
> }
> }
I like this. I think it could be made even more simple by using the
"app_label.model_name" pattern in use by other settings (e.g.
ABSOLUTE_URL_OVERRIDES) for the dict keys. This makes the
implementation easier using django.db.models.get_model and
django.db.models.get_models.
DATABASE_USING = {
'auth' : 'default',
'myapp' : 'database1',
'myapp2.model1' : 'database2',
'myapp2.model2' : 'database3',
}
Any model not specifically mentioned could assume that it should use "default".
Paul
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Multiple database support: Request for feedback and testing
On Fri, Dec 4, 2009 at 2:48 PM, Alex Gaynor wrote: > We will not be adding a setting to pin an application/model to a > specific database. We have already removed the Meta.using option. If > you want to pin an application to a specific database it's fairly > trivial to add a manager and override the save() method to use a > specific DB. Our goal is to design a good long term API for having a > flexible way to define exactly what DB any query goes to, and I > personally have no interest in seeing short term stopgap APIs > implemented. That's fine for apps under my control, but this leaves us without a way of dealing with 3rd party apps outside of an unfortunate amount of monkey patching. I certainly don't want the API to be "sort term" or "stopgap", but I do want this ability. I don't see any other way to accomplish a heterogeneous admin or partitioning of 3rd party apps. I know and agree with the reasons that the Meta.using option was removed, but it wouldn't have solved these issues either. Adding a key to the DB configs may not be the right way, but I'm sure there is a good way to accomplish this. Thanks, Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Multiple database support: Request for feedback and testing
What will be the default action of manage.py syncdb (without the
--database option)? Will it create all tables on all DBs, or just use
"default"? The former would be useful for the simple replication use
case, but wasteful for partitioning, and the latter could get tiresome
unless there is a "--database all" option of which I'm unaware.
I also don't see anywhere in the proposed docs where one could specify
"app -> db" or "app.model -> db" mappings. Without some mechanism for
such mapping, I'm afraid the partitioning case will become error prone
and verbose, both with manage.py commands, and in app code. I'd hate
to have to refactor all of my app's views if I moved some tables to a
new server. Not having such mappings will also require a refactor of
many of the views in existing distributed apps to become "multi-db
enabled" if they don't already accept a QuerySet as an argument (isn't
necessarily a bad thing, but could delay multi-db usefulness). Moving
this problem to settings should (operative word) keep multi-db app
related modification to a minimum, and thus not split all available
apps into supporting and non-supporting categories. It could also
greatly ease deployment if one didn't partition in dev, but did in
staging and production. And this would go a long way toward fixing the
Admin issue for the partitioning case, and for replication most will
only need the admin on the default db anyway.
The mappings could be as simple as a new key on the DATABASES dict:
DATABASES = {
'default': {
'BACKEND': 'django.db.backends.sqlite3',
'NAME': 'mydatabase',
},
'stuff': {
'BACKEND': 'django.db.backends.sqlite3',
'NAME': 'myotherdatabase',
'PINNED': ['myapp', 'someapp.model'],
},
}
I thought I saw some discussion of this type of thing a while back.
Was a mechanism for this delayed, removed, undocumented, or am I just
missing something?
Thanks,
Paul
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Session/cookie based messages (#4604)
Could we not also provide the convenience request.messages.* functions in the middleware that simply wrap the "real" functions? While I understand the need for the others, and agree with their use throughout the Django codebase, I also agree with Alex that they just read better, and I'd prefer to use that API in my new projects. Thanks, Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Regularly-scheduled Django sprints, first December 11 - 13
I'd be willing to help organize one in the Triangle area of North Carolina (Raleigh, Durham, Chapel Hill). We're just getting a Django Users Group setup (TriDjUG) and there is already a thriving Python Users Group (TriZPUG) in the area. I'm sure we could get a decent turn out. Thanks for kicking this off! Paul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: The this-needs-to-be-in-django angst
On Wed, Oct 21, 2009 at 8:57 PM, Russell Keith-Magee wrote: > > On Thu, Oct 22, 2009 at 8:48 AM, James Bennett wrote: >> >> On Wed, Oct 21, 2009 at 7:36 PM, Russell Keith-Magee >> wrote: >>> Let me tell you a store about three people named Everybody, Anybody, >>> Somebody and Nobody. >> >> Four! The four people in this story are... > > erm... ahh... Nobody isn't a person? Somebody should really get on that then. Everything would be done if Nobody was Somebody after all :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: lazy auth context processor
On Wed, Oct 14, 2009 at 10:34 AM, Jacob Kaplan-Moss wrote: > Eh, I don't think it's a big deal. I just grepped through a *lot* of > Django code and can't find that use anywhere. So now I know I'm an edge case :) I do use that, but only because I'm using a proxy model for User and I've overridden __unicode__ to output what I want for convenience. I'm sure I could work around it, but since it sounds easy to keep the current functionality, I for one would appreciate it. Paul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Tue, Oct 13, 2009 at 9:48 AM, Jacob Kaplan-Moss wrote: > The best solution, I think, would be to implement user messages > (user.message_set, get_and_delete_messages, etc) in terms of the new > framework, and then gradually deprecate and remove the old APIs. On Tue, Oct 13, 2009 at 10:30 PM, Tobias McNulty wrote: > I'm not sure exactly what you mean by implement user messages in terms > of the new framework. It is completely possible to implement a > storage engine in several of the proposed solutions that would use > user.message_set to store data, though I'm not sure what the advantage > would be over any of the other options. Furthermore, the fact that > user.message_set is just a related manager on a model and not an > independent API per se makes it a difficult one to remove while > simultaneously keeping user message functionality. I took what Jacob said to be the opposite. It sounded to me like he was suggesting that we keep the existing user messaging api, but change the internals of it to use the new notifications framework for storage. In my head it goes something like: 1. Remove the relation from the User to the Message model. 2. Add a message_set property that mimics the related manager, but which stores the messages via the new notifications app. 3. Modify the get_and_delete_messages method to retrieve messages from the new app. 4. Gradually remove the messaging stuff from contrib.auth all together. This has the advantage of removing the need to modify core.context_managers.auth since that just uses User.get_and_delete_messages. I think this method is nice and clean, backward compatible as far as the API goes, and moves all messaging into a single backend w/o disrupting existing view or template code. It may break things if people are directly querying the Message model, but that has to be extremely rare. Paul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Tue, Oct 13, 2009 at 3:27 AM, Russell Keith-Magee wrote: > Secondly, I share Chris' concern about overloading 'messages'. This > overlaps with the bikeshed issue of what to call the new contrib > package - whatever name is picked for the contrib package should > probably be reflected in the context variable, etc. > > Lastly, one issue that seems unaddressed is the transition plan for > replacing user.message_set. The preamble to the wiki page makes a > compelling argument for ditching message_set, but remains silent on a > proposal for how Django (as a project) should be treating this new > alternative. > > The solution might well be "use it if you want, ignore it if you > don't", but given the problems with user.message_set, it might be > worth giving some thought to a deprecation/transition plan. This may be adding undue complexity, but I wanted to throw it out and see what you thought anyway. I think a possible solution to Russ' last two points may indeed be overloading the "messages" template variable. What I'm thinking is that we keep the message_set (of course) and add the new "request.messages.*" API, but completely remove the messages part of the auth context_processor and have the default backend for the new system pull both for the first release (purely for backward comparability). Messages from the old message_set system could get a default level in the new system. This shouldn't be an issue since the people using it will likely be existing projects where they won't be using any level information in their templates. We couple this combined backend with settings that will allow you to easily disable the DB part of the backend (or make it clear how to and strongly suggest switching backends), and provide a setting for the default message level that defaults to INFO. I think this could ease transition as the two systems could live together for the first release. The subsequent releases could switch the default backend to the existing fallback one, and then eventually remove the message_set part of the auth app all together. I do recognize that this may create more confusion than is necessary. It may also be an unacceptable performance drain on the new system to support the old at all. I just think as someone who has projects that still use the message_set, and especially considering the 3rd party apps out there which may use it as well, it might be a nice balance to be able to mix in the new and better while having as little impact on the templates as possible. Technically, this may be more of a challenge than it's worth however. The current auth context_processor is in core, and it just really feels wrong to me to couple this new app to either core or contrib.auth. We could just remove the "messages" part of the auth context_processor and add a new processor from the new app to the list of defaults that will provide all of the "messages". And actually, we'll need to at least override that part of the auth context_processor anyway, or else we'll still get a db hit for every request with a logged in user due to the call to user.get_and_delete_messages. Sorry about throwing my brainstorm at you. Perhaps it'll spark someone else's solution. Thanks, Paul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Mon, Oct 12, 2009 at 2:32 PM, Tobias McNulty wrote: > For the record I have no personal need for this feature (and hence > strong feelings about it), but nor do I see why adding it would be a > bad thing IF the need is actually there. Right now it sounds like > regroup will work fine for its original proponent, so, in the interest > of keeping things simple, let's assume it will not be included unless > someone brings up a compelling case. That's fair enough. Simple is good, and if someone really needs different message retrieval methods, I'm sure a custom middleware could provide anything they'd need. Tobias: Are you planning on coding up a proposal app? It doesn't sound like there's far to go from a branch or fork of django-notify. I should have some time to contribute to the code or testing if you need it. Thanks for your work on this (and on django-notify), Paul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Mon, Oct 12, 2009 at 12:11 PM, Tobias McNulty wrote:
> I have no particular issue with allowing messages to be iterated in
> full and/or by type. We could also just sort the messages and let you
> use {% regroup messages by tag %}, but I suppose you want the ability
> to pull out a particular type of error and that could get tedious with
> {% regroup %}.
I think regroup would be fine. My thought was that with iteration by
type you'd be able to easily highlight just one type if you so choose,
and even have any of the types displayed in a completely different
area of the markup if you needed. Having both abilities would be the
best-of-all-possible-worlds in my opinion, but this is starting to
smell like scope-creep. I'll just say that the backends and API are
the most important things, and having individually iterable lists is
just a "nice to have." I'd definitely be happy to help with the
implementation though if the group thinks it a worthy feature.
Paul
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
For the potential API...
http://code.djangoproject.com/wiki/SessionMessages#PotentialAPI
It would be really nice if one could optionally iterate over the
message lists separately. For example:
{% if request.messages.error %}
{% for message in request.messages.error %}
{{ message }}
{% endfor %}
{% endif %}
And then get the rest normally...
{% if request.messages %}
{% for message in request.messages %}
{{ message }}
{% endfor %}
{% endif %}
This would allow for much more flexibility from a design perspective.
Paul
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Sat, Oct 10, 2009 at 2:05 PM, David Cramer wrote: > The proposal per your email is more or less how django-notices works. For me, the best solution would be a combination of django-notify and django-notices. django-notify for their fallback backend and the interchangeable backend support in general, and django-notices for the logger-like API. I especially like the NOTICE_LEVEL setting which could easily be controlled via your DEBUG setting. I agree that custom levels should be easy and encouraged, and the strings used even for the built-in levels should be configurable. Paul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Brand new projects should pass their tests (the django.contrib.auth thing from #7611)
On Thu, Oct 8, 2009 at 5:52 AM, Simon Willison wrote:
> If we were to ship default templates, simply using {% extends base %}
> and providing an argument to the generic views that allows the user to
> specify their own base template would be enough to ensure easy
> integration with a custom design (and hence work around what I assume
> is the reason we didn't ship default templates in the first place).
I like default templates. Even if they're only ever directly rendered
by the tests, they're a great way to provide an example of how to use
the app's context, and a nice jumping off point for people to copy
into their project's templates dir and modify. I certainly don't want
to see Django core start coming with a default design or set of
templates, but I do like the idea of a minimal set for the contrib
apps where appropriate and required for testing.
IIRC, the reason I've most often heard for not including default
templates is the fear (I believe well founded) that there would be a
flood of tickets from people who will want them to "just work" with
their design, and will beg for all sorts of bizarre options. Perhaps
we could assuage this by making it clear that these are purely for
testing, but may be copied as a jumping-off point or viewed as an
example. This could be accomplished by putting them in a "test" folder
in the app's templates directory, and passing that as the custom
template argument in the tests. That way there still wouldn't be an
"official" default template that people would expect to "just work",
but the tests would still pass.
Thanks,
Paul
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
