Thank you Andrew, very interesting. In case of using sessions, maybe it.s possilbe to create an object to serialize only the data, the same as the hidden fields do. So this way we can solve a problem, Example: form = MyForm( serialized_data ) where serialized data is a dictionary get by form.cleaned_data. In the example of the e-commerce, instead of serializing the products, we could serialize the products ids. At this time, I don't need to leave the form and return later, but sometimes I have used wizards implemented with sessions. And that's why I asked the way Form Wizard works. I don't like the hidden fields options too much because it's easy to be hacked. The data validated in the first step can easily be changed in the last one, so at the end of the process, there must be a validation process again. I do this with sessions, and if the data has been changed, I redirect the user to a Hacking attempt page.
Now I have to study if it's possible to get back to the previous steps using Form Wizard, but I think it's not quite clean, and I should create a new form with custom hidden field to return. Also I have to check if a validation is done again in the last step, in order to prevent hacks. On 7 jun, 01:40, Andrew Ingram <[EMAIL PROTECTED]> wrote: > I believe the general best practice is that sessions should be viewed as > a last resort for storing data. > > You can store data in a number of places and they each have their > benefits and drawbacks. > > The easiest place to store data is the URL, but storing user-specific > information in the URL is a huge security risk and also tends to result > in huge (and ugly) URLs. So this obviously isn't suitable for storing > form state (especially things like payment processing forms). > > The second place might think to store data is in the session, there is > nothing strictly wrong with this approach but you have to be careful > about how you'd do it. You wouldn't store a user object in the session > but rather the user id for retrieval from the database. The session is > useful but you don't want it to be too big otherwise you incur > serialization/deserialization overhead which is especially risky in > clustered server environments. > > In the case of multi-stage forms the best place (in most cases) to store > data between stages is in hidden fields that get POSTed with each stage > submission, this completely alleviates any session overhead and can even > let you go forward and backward between stages (assuming the > implementation allows it, i'm not sure if the FormWizard stuff lets you > go backwards). You do reach potential problems however if you want the > user to be able to leave the form and return to it later and continue > from where they left are. > > The solution in this case would be to use the session (or you could > write the state to the database if you want them to be able to retrieve > the state even after sessions have expired, but I'd consider this the > very last option), when you do have to use a session for this (i'm > thinking things like e-commerce order processes) you want to be careful > to ensure that the objects involved aren't too deep (you don't want to > blindly serialize a shopping basket which would in turn serialize all > the products in the basket and then all the categories for those > products etc), and you also want to ensure that you take any security > measures in the format of the session that you would be taking in the > storage of the final result of the form submission (ie encrypted credit > card numbers). > > The line is always a bit fuzzy, but basically store state in hidden > fields as a first resort unless you really need to allow the user to > leave the form in which case store state in a carefully considered > session object. > > - Andrew > > Grupo Django wrote: > > Hi! Just a simple question. > > The Form Wizard application stores the data hashed in hidden fields. > > Why not in a session? Why is it better? I just want to learn best > > practices. > > > Thank you. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
