Michael

I'm sorry, I should have removed this code for the post, but this code is 
part of a "honey pot".  There is no 'address' input visible, it is used so 
if a spam bot enters information into this field, it kills the form.  Humans 
cannot enter anything into this field.

  if ($_POST['address'] != '' ) {


die("Changed field");

   }

""Again, I see no reason you could not call last_insert_id() after the
first insert and use that value explicitly in the second.
""

I'm not sure I undertand this, could you explain a little further for me.

Again, thank you for your help.

Gary


"Michael Dykman" <mdyk...@gmail.com> wrote in message 
news:banlktimeyexp3lxozvgoz0fedrrf69r...@mail.gmail.com...
The first thing I notice browsing your code is this block stuck
immediately between your 2 insert statements:

  if ($_POST['address'] != '' ) {


die("Changed field");

   }

This guarantees that your 2 auto_increment sequences will fall out of
sync any time any client POSTs (and perhaps all gets?) to this script
without an 'address' parameter.

Again, I see no reason you could not call last_insert_id() after the
first insert and use that value explicitly in the second.

 - michael dykman

On Fri, Apr 15, 2011 at 12:16 PM, Reindl Harald <h.rei...@thelounge.net> 
wrote:
>
>
> Am 15.04.2011 17:59, schrieb Gary:
>> Michael, thank you for your reply
>>
>> ""Might I suggest, instead of the 2 part juggling act, you drop the
>> auto-increment property on your second table, and just use the value
>> derived from the first as the joining key in the second. Then there
>> is only one sequence to worry about with nothing to sync against
>> ""
>>
>> There is only one AI into the main page. This is the insert code, I have
>> probably left more in than you need to see.
>>
>> What I also did was to add some duplicate columns in the two tables 
>> (email,
>> ip, timestamp) so in the event I need to manually to in I would be able 
>> to
>> decifer who goes where.
>>
>> On second look, it would appear I am NOT using a join, but two 
>> inserts.... I
>> don't recall why I did it that way
>
> this code is unreadable for me because of its coding-style and if i see
> "addslashes" for database inserts i start to fear and run away
>
> you are using two inserts so what do you do there and where can be 
> anything
> out of sync on the database-level? where is the magic in your code without
> using mysql_insert_id() or LAST_INSERT_ID() - what should this code do?
>
> * insert in main table
> * fetch mysql_insert_id() what is thread-safe
> * use that value in the second table
> ____________
>
> and please do not use such ugly hacks as in the begin of your code
> addslashes() has no useable security for user-input
>
> even mysql_escape_string() has not -> mysql_real_escape_string()
>
>
>



-- 
- michael dykman
- mdyk...@gmail.com

May the Source be with you.

__________ Information from ESET Smart Security, version of virus signature 
database 6044 (20110415) __________

The message was checked by ESET Smart Security.

http://www.eset.com





__________ Information from ESET Smart Security, version of virus signature 
database 6044 (20110415) __________

The message was checked by ESET Smart Security.

http://www.eset.com





-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/mysql?unsub=arch...@jab.org

Reply via email to