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 essen
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
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
clude 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 t
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
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.
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. Wer
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 stri
ls 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-d
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 li
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 mo
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',
>
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
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 "--dat
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 u
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
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
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
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,
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 co
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
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
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 %}
{{ messag
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 g
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 desig
25 matches
Mail list logo
