Ok I'll work on making the change then.
On Dec 4, 4:15 pm, Jonathan Lundell <jlund...@pobox.com> wrote:
> On Dec 4, 2010, at 1:52 PM, Brian M wrote:
>
>
>
> > OK, so make it so that if desired some subset of the URL vars could be
> > signed while still allowing other vars to be changed. That is
> > certainly doable and would be nice for securing only the important
> > parts.
>
> Right. Not so much the important parts as the invariant ones--the ones that
> the form can't alter.
>
>
>
> > Are you assuming that *all* the args *always* get hashed though - that
> > seems reasonable to me anyway since a form or ajax call shouldn't need
> > to manipulate them right?
>
> That's what I'm assuming, yes. I think it'd be best to avoid that
> complication for now, and if it turns out to be desirable down the road, we
> could add a hash_args=True default that would retain compatibility.
>
>
>
>
>
>
>
>
>
> > If this sounds like a better implementation to you Jonathan (and
> > anyone else) then I can look at getting a patch to Massimo.
>
> > ~Brian
>
> > On Dec 4, 1:07 pm, Jonathan Lundell <jlund...@pobox.com> wrote:
> >> On Dec 4, 2010, at 10:29 AM, Brian M wrote:
>
> >>> Jonathan,
>
> >>> How would you like to see this behave? Perhaps URL('index',args=[],
> >>> vars={}, hash_key='xxx', hash=['args','vars']) and then
> >>> URL.verify(hmac_key='xxx', hash=['args', 'vars]) so that you could
> >>> choose which portions of the URL to sign and/or verify with hash=None
> >>> triggering the original behavior of hashing both? Since this hasn't
> >>> made it into a stable release yet I assume changes can be made still
> >>> without worrying about breaking backwards compatibility.
>
> >> That would work. I'm not sure if it needs to be that general; is there a
> >> use case for hashing vars but not args? If not, then a boolean would be
> >> adequate (hash_vars=True by default; the caller sets it False if desired).
>
> >> Another generalization would be to pass a set of var keys to be included
> >> in the hash: hash_vars=set('name1', 'name2'). The use case would be a
> >> form, again (or Ajax, perhaps), where the included vars would be page
> >> state kept in hidden or read-only elements of the form.
>
> >> So: hash_vars=True (default; hash all vars)
> >> hash_vars=False (don't hash any vars)
> >> hash_vars=set(...) (hash only the vars named in the set)
>
> >> The set needn't be a set per se, I suppose. Any iterable (well, not a
> >> string) would suffice.
>
> >>> ~Brian
>
> >>> On Dec 3, 11:13 am, Jonathan Lundell <jlund...@pobox.com> wrote:
> >>>> On Dec 3, 2010, at 9:01 AM, mdipierro wrote:
>
> >>>>> New feature in trunk:
>
> >>>>> URL('index',args=[],vars={},hash_key='xxx')
>
> >>>>> the URL will have a _signature attached. The associated controller can
> >>>>> check for the signature with
>
> >>>>> def index():
> >>>>> if not URL.verify(hmac_key='xxx'): ......
> >>>>> ...
>
> >>>>> Please test it. In particular we need to test the workflow and see if
> >>>>> we are missing something useful or doing something wrong.
>
> >>>> Perhaps there should be an option to exclude the query string from the
> >>>> hash calculation. Otherwise we can't sign URLs that are form actions (or
> >>>> that are similarly used with Ajax).
