2009/3/26 Reed O'Brien <r...@reedobrien.com>: > I still think you need to use a second form specific header/cookie. So you > can be sure that the form being submitted isn't stale. I don't think it wise > to use an already existing session; as an instance of a form can be > submitted repeatedly.
That's policy though; google search for instance, does not have such a policy. > If it is tied to a specific header/cookie at form generation time then only > the id==token is valid for that particular submission. If there is a field > validation error in the form (empty required field e.g.) then the form is > re-rendered to the agent with a new header/cookie == form token. Right you could have a ticket system, but is it really necessary for the general site? Perhaps for online banking or airline ticket booking. > Perhaps we are saying the same thing and I am being obtuse. But *only* > validating that an agent is participating in a valid session doesn't prevent > a malicious JS from submitting a form on that valid sessions behalf. No, but you *never* want mailicious JS served up from your own domain. That's a serious vulnerability that can easily expose all your users credentials. So that scenario should not be considered. \malthe _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
