Re: Design and code review requested for Django string signing / signed cookies

[Daniel Pope]

The timestamp is necessary to limit replay attacks, and so it should
probably be more than optional - always issued, and checked by
default. The danger is that users might think "signing" is a
bulletproof guarantee that the cookie as received is exactly the
latest cookie issued to that unique user and use them where a replay
attack would be unacceptable for security. There is still a max_age
window for replay attacks, which I don't know of any way to close.

Encrypting the cookies as well would make replay attacks a little
trickier, forcing the attacker to use trial-and-error rather than
identifying targets by inspection. Security through obscurity only,
though cookies being opaque to the user can be useful in its own
right.

The API could accept a user-supplied "check" string so that if the
user can supply some other details - maybe an IP - and have the API
verify this for them (thus preventing replay attacks for different
IPs).

> unsigned_value = signer.unsign(signed_value)

On an API level, 'unsign' isn't an obvious choice. The operation you
are doing is verifying and stripping a signature, so I'd expect
'verify' in the name. You also might want access to the signature
data.

So for example, something like this:

>>> s = SignedString(signed_value)
>>> s
'Hello world'
>>> s.timestamp
1262612904
>>> s.is_key_current()
True
>>> s = SignedString(old_signed_value, max_age=3600)
...
SignatureExpired: signature older than max_age

Dan

--

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: Long-term direction for shortcuts

[Daniel Pope]

2009/8/3 Jacob Kaplan-Moss :
> 1. Propose a new shortcut function. Bonus points for a patch.

In all my projects I use a file of my own shortcuts:

http://dpaste.com/hold/75120/

NB. I knew as I wrote the MAGICTEMPLATE shortcut that I would never
actually use it. The idea was to eliminate ALL of the boilerplate, as
an exercise in Python stack hacking magic. Passing locals() would
achieve the same thing, but in practice it's more useful to see
explicitly what I'm passing to each template.

Dan

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Feature request: admin notifications

[Daniel Pope]

I wondered if it might be time to consider new features for Django 1.2.

My suggestion is a system for administrators to be notified about
specific model instances about which they need to take action. At
present administrators have to identify where to make changes by
browsing the site. Some example use cases:

1. Comments - a list of new comments requiring moderation.
2. Stock level low - a list of SKUs with fewer than say, 5 items left in stock.
3. Draft articles - a list of unpublished articles, for the
convenience of administrators.
4. Data inconsistencies - while model validation should do for any
really functional inconsistencies, I often come across situations
where I want to warn admins rather than outright forbid the model to
be saved. Case in point: I want to warn if the number of products in a
category would require me to paginate them onto 2 pages as this is
undesirable for usability.

I would propose a way to register notification querysets in the admin.
If a non-zero number of results present, a message appears in the
admin, including the number of items to administer, and a link to a
changelist that displays only matching models. I'd ideally like to
select an icon too, so that I can differentiate between alerts,
warnings and mere information.

Dan

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---