This content has been marked as final. Show 4 replies
wow, didn´t know something like this exists -- scary !
However, the only halfways reliable protection IMO would be using session variables like ADDT´s native "kt_login_id" -- at least this type of variable can´t be changed by Tamper Data.
Adobe Community Expert, Dreamweaver
Tamper Data can be very devastating. In my case, I had the user level being passed as a hidden field on the registration form. And I was using a very simple way of identifying the user levels (1, 2, 3 for Super Admin). Using tamper data I had absolutely no trouble setting a new user's level to 3. Now, I've removed the level field from the registration form and I've come up with a 7-digit VARCHAR code for the user levels. Now my next project will be seeing whether I can expose the user levels, since people will not be able to guess them. Also, I'm testing ADDT against different SQL injections, but it isn't too difficult to lock down the forms, so I don't expect any surprises.
I've read many of your posts, your nomination as a Community Expert is well-deserved. I've also used the tutorials and found the one about TinyMCE to be a total relief!
As far as the future of ADDT goes, I don't have any inside info, but I think it will be impossible that I will be unable to update a database table in the next version of CS4--either with or without an add-on.
Thanks for the quick response.
Mark, removing the user level field from the registration form was a step in the right direction. Have you tried adding the user level as a transaction field? Doing so will allow you to use it in your registration transaction and more importantly it won't appear in your form.