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).