php-general Digest 14 Feb 2010 00:45:05 -0000 Issue 6589

[php-general-digest-help]

php-general Digest 14 Feb 2010 00:45:05 -0000 Issue 6589

Topics (messages 302061 through 302076):

Re: optional object arguments to a function
        302061 by: Jochem Maas
        302074 by: Richard Quadling

Re: SQL insert () values (),(),(); how to get auto_increments properly?
        302062 by: Lester Caine
        302063 by: Jochem Maas
        302064 by: Eric Lee
        302065 by: Jochem Maas
        302068 by: tedd
        302069 by: Joseph Thayne
        302070 by: Ashley Sheridan
        302072 by: Lester Caine

Re: How to secure this
        302066 by: John Allsopp
        302067 by: tedd
        302071 by: Robert Cummings
        302073 by: Michael A. Peters
        302075 by: Michael A. Peters

Report generators: experience, recommendations?
        302076 by: Jonathan Sachs

Administrivia:

To subscribe to the digest, e-mail:
        php-general-digest-subscr...@lists.php.net

To unsubscribe from the digest, e-mail:
        php-general-digest-unsubscr...@lists.php.net

To post to the list, e-mail:
        php-gene...@lists.php.net


----------------------------------------------------------------------

--- Begin Message ---

Op 2/13/10 8:05 AM, Michael A. Peters schreef:
> I've started working on a class using DOMDocument to assemble MathML in
> php. The class, assuming I actually succeed, will eventually be used for
> parsing LaTeX math equations to MathML without the need to have TeX
> installed. I probably won't be able to support all the possibilities for
> equations that LaTeX does w/o a TeX install (and definitely not user
> defined macros) but I suspect I can (hopefully) cover most of the common
> stuff.
> 
> One thing I don't know how to do, though, is write a function where
> arguments are optional object.
> 
> IE for a function to generate an integral, the limits are optional but
> if specified must be an object (since they may be an equation
> themselves). I want the default to be some kind of a null object so I
> know to do nothing with it if it is null.
> 
> With string/integer you just do
> 
> function foo($a='',$b='',$c=false) {
>   }
> 
> How do I specify a default null object, or otherwise make the argument
> argument optional?

this first one doesn't work:

<?

class Foo
{
        function dobar(stdObject $o = null) { /* ... */ }
}

$e = new Foo;
$f = new Foo;

$f->dobar();                    // works
$f->dobar($e);                  // catchable fatal
$f->dobar((object)array());     // catchable fatal - check the error msg!?!?

?>

... but if you're able/willing to specify a user defined class then you
have this option:

<?php

class Bar {}

class Foo
{
        function dobar(Bar $o = null) { /* ... */ }
}

$b = new Bar;
$f = new Foo;

$f->dobar($b);
$f->dobar();

?>

> 

--- End Message ---

--- Begin Message ---

On 13 February 2010 10:07, Jochem Maas <joc...@iamjochem.com> wrote:
> Op 2/13/10 8:05 AM, Michael A. Peters schreef:
>> I've started working on a class using DOMDocument to assemble MathML in
>> php. The class, assuming I actually succeed, will eventually be used for
>> parsing LaTeX math equations to MathML without the need to have TeX
>> installed. I probably won't be able to support all the possibilities for
>> equations that LaTeX does w/o a TeX install (and definitely not user
>> defined macros) but I suspect I can (hopefully) cover most of the common
>> stuff.
>>
>> One thing I don't know how to do, though, is write a function where
>> arguments are optional object.
>>
>> IE for a function to generate an integral, the limits are optional but
>> if specified must be an object (since they may be an equation
>> themselves). I want the default to be some kind of a null object so I
>> know to do nothing with it if it is null.
>>
>> With string/integer you just do
>>
>> function foo($a='',$b='',$c=false) {
>>   }
>>
>> How do I specify a default null object, or otherwise make the argument
>> argument optional?
>
> this first one doesn't work:
>
> <?
>
> class Foo
> {
>        function dobar(stdObject $o = null) { /* ... */ }
> }
>
> $e = new Foo;
> $f = new Foo;
>
> $f->dobar();                    // works
> $f->dobar($e);                  // catchable fatal
> $f->dobar((object)array());     // catchable fatal - check the error msg!?!?
>
> ?>
>
> ... but if you're able/willing to specify a user defined class then you
> have this option:
>
> <?php
>
> class Bar {}
>
> class Foo
> {
>        function dobar(Bar $o = null) { /* ... */ }
> }
>
> $b = new Bar;
> $f = new Foo;
>
> $f->dobar($b);
> $f->dobar();
>
> ?>
>
>>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Try stdClass.

If you know the class type, then that can be the type hint.

You can also use func_get_args() to read all the parameters and type
check them if there are MANY optional parameters.

-- 
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

--- End Message ---

--- Begin Message ---

Rene Veerman wrote:

Hi.

I'm looking for the most efficient way to insert several records and
retrieve the auto_increment values for the inserted rows, while
avoiding crippling concurrency problems caused by multiple php threads
doing this on the same table at potentially the same time.

Any clues are greatly appreciated..
I'm looking for the most sql server independent way to do this.

Rene

The 'correct' way of doing this is to use a 'sequence' which is something introduced in newer versions of the SQL standard. Firebird(Interbase) has had 'generators' since the early days (20+ years) and these provide a unique number which can then be inserted into the table.

ADOdb emulates sequences in MySQL by creating a separate table for the insert value, so you can get the next value and work with it, without any worries. The only 'problem' is in situations were an insert is rolled back, a number is lost, but that is ACTUALLY the correct result, since there is no way of knowing that a previous insert WILL commit when several people are adding records in parallel.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--- End Message ---

--- Begin Message ---

Op 2/13/10 10:08 AM, Lester Caine schreef:
> Rene Veerman wrote:
>> Hi.
>>
>> I'm looking for the most efficient way to insert several records and
>> retrieve the auto_increment values for the inserted rows, while
>> avoiding crippling concurrency problems caused by multiple php threads
>> doing this on the same table at potentially the same time.
> 
>> Any clues are greatly appreciated..
>> I'm looking for the most sql server independent way to do this.
> 
> Rene
> The 'correct' way of doing this is to use a 'sequence' which is
> something introduced in newer versions of the SQL standard.
> Firebird(Interbase) has had 'generators' since the early days (20+
> years) and these provide a unique number which can then be inserted into
> the table.
> 
> ADOdb emulates sequences in MySQL by creating a separate table for the
> insert value, so you can get the next value and work with it, without
> any worries. The only 'problem' is in situations were an insert is
> rolled back, a number is lost, but that is ACTUALLY the correct result,
> since there is no way of knowing that a previous insert WILL commit when
> several people are adding records in parallel.

this is all true and correct ...

but that doesn't answer the problem. how do you get the IDs of all the records
that we're actually inserted in a multi-insert statement, even if you generate 
the
IDs beforehand you have to check them to see if any one of the set INSERT 
VALUEs failed.

@Rene:

I don't think there is a really simple way of doing this in a RDBMS agnostic
way, each RDBMS has it's own implementation - although many are alike ... and 
MySQL is
pretty much the odd one out in that respect.

it might require a reevaluation of the problem, to either determine that 
inserting
several records at once is not actually important in terms of performance (this 
would depend
on how critical the speed is to you and exactly how many records you're likely 
to be inserting
in a given run) and whether you can rework the logic to do away with the 
requirement to
get at the id's of the newly inserted records ... possibly by indentifying a 
unique
indentifier in the data that you already have.

one way to get round the issue might be to use a generated GUID and have an 
extra field which
you populate with that value for all records inserted with a single query, as 
such it could
function as kind of transaction indentifier which you could use to retrieve the 
newly
inserted id's with one extra query:

        $sql = "SELECT id FROM foo WHERE insert_id = '{$insertGUID}'";

... just an idea.

> 

--- End Message ---

--- Begin Message ---

On Sat, Feb 13, 2010 at 6:55 PM, Jochem Maas <joc...@iamjochem.com> wrote:

> Op 2/13/10 10:08 AM, Lester Caine schreef:
> > Rene Veerman wrote:
> >> Hi.
> >>
> >> I'm looking for the most efficient way to insert several records and
> >> retrieve the auto_increment values for the inserted rows, while
> >> avoiding crippling concurrency problems caused by multiple php threads
> >> doing this on the same table at potentially the same time.
> >
> >> Any clues are greatly appreciated..
> >> I'm looking for the most sql server independent way to do this.
> >
> > Rene
> > The 'correct' way of doing this is to use a 'sequence' which is
> > something introduced in newer versions of the SQL standard.
> > Firebird(Interbase) has had 'generators' since the early days (20+
> > years) and these provide a unique number which can then be inserted into
> > the table.
> >
> > ADOdb emulates sequences in MySQL by creating a separate table for the
> > insert value, so you can get the next value and work with it, without
> > any worries. The only 'problem' is in situations were an insert is
> > rolled back, a number is lost, but that is ACTUALLY the correct result,
> > since there is no way of knowing that a previous insert WILL commit when
> > several people are adding records in parallel.
>
> this is all true and correct ...
>
> but that doesn't answer the problem. how do you get the IDs of all the
> records
> that we're actually inserted in a multi-insert statement, even if you
> generate the
> IDs beforehand you have to check them to see if any one of the set INSERT
> VALUEs failed.
>
> @Rene:
>
> I don't think there is a really simple way of doing this in a RDBMS
> agnostic
> way, each RDBMS has it's own implementation - although many are alike ...
> and MySQL is
> pretty much the odd one out in that respect.
>
> it might require a reevaluation of the problem, to either determine that
> inserting
> several records at once is not actually important in terms of performance
> (this would depend
> on how critical the speed is to you and exactly how many records you're
> likely to be inserting
> in a given run) and whether you can rework the logic to do away with the
> requirement to
> get at the id's of the newly inserted records ... possibly by indentifying
> a unique
> indentifier in the data that you already have.
>
> one way to get round the issue might be to use a generated GUID and have an
> extra field which
> you populate with that value for all records inserted with a single query,
> as such it could
> function as kind of transaction indentifier which you could use to retrieve
> the newly
> inserted id's with one extra query:
>
>        $sql = "SELECT id FROM foo WHERE insert_id = '{$insertGUID}'";
>
> ... just an idea.
>
> >
>
>
>
Hi

I would like to learn more correct  way from both of you.
May I ask what is a sequences ?


Thanks !


Regards,
Eric

> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--- End Message ---

--- Begin Message ---

Op 2/13/10 11:36 AM, Eric Lee schreef:
> 
> 
> On Sat, Feb 13, 2010 at 6:55 PM, Jochem Maas <joc...@iamjochem.com
> <mailto:joc...@iamjochem.com>> wrote:
> 
>     Op 2/13/10 10:08 AM, Lester Caine schreef:
>     > Rene Veerman wrote:
>     >> Hi.
>     >>
>     >> I'm looking for the most efficient way to insert several records and
>     >> retrieve the auto_increment values for the inserted rows, while
>     >> avoiding crippling concurrency problems caused by multiple php
>     threads
>     >> doing this on the same table at potentially the same time.
>     >
>     >> Any clues are greatly appreciated..
>     >> I'm looking for the most sql server independent way to do this.
>     >
>     > Rene
>     > The 'correct' way of doing this is to use a 'sequence' which is
>     > something introduced in newer versions of the SQL standard.
>     > Firebird(Interbase) has had 'generators' since the early days (20+
>     > years) and these provide a unique number which can then be
>     inserted into
>     > the table.
>     >
>     > ADOdb emulates sequences in MySQL by creating a separate table for the
>     > insert value, so you can get the next value and work with it, without
>     > any worries. The only 'problem' is in situations were an insert is
>     > rolled back, a number is lost, but that is ACTUALLY the correct
>     result,
>     > since there is no way of knowing that a previous insert WILL
>     commit when
>     > several people are adding records in parallel.
> 
>     this is all true and correct ...
> 
>     but that doesn't answer the problem. how do you get the IDs of all
>     the records
>     that we're actually inserted in a multi-insert statement, even if
>     you generate the
>     IDs beforehand you have to check them to see if any one of the set
>     INSERT VALUEs failed.
> 
>     @Rene:
> 
>     I don't think there is a really simple way of doing this in a RDBMS
>     agnostic
>     way, each RDBMS has it's own implementation - although many are
>     alike ... and MySQL is
>     pretty much the odd one out in that respect.
> 
>     it might require a reevaluation of the problem, to either determine
>     that inserting
>     several records at once is not actually important in terms of
>     performance (this would depend
>     on how critical the speed is to you and exactly how many records
>     you're likely to be inserting
>     in a given run) and whether you can rework the logic to do away with
>     the requirement to
>     get at the id's of the newly inserted records ... possibly by
>     indentifying a unique
>     indentifier in the data that you already have.
> 
>     one way to get round the issue might be to use a generated GUID and
>     have an extra field which
>     you populate with that value for all records inserted with a single
>     query, as such it could
>     function as kind of transaction indentifier which you could use to
>     retrieve the newly
>     inserted id's with one extra query:
> 
>            $sql = "SELECT id FROM foo WHERE insert_id = '{$insertGUID}'";
> 
>     ... just an idea.
> 
>     >
> 
> 
> 
> Hi
> 
> I would like to learn more correct  way from both of you.
> May I ask what is a sequences ?

it an RDBMS feature that offers a race-condition free method of
retrieving a new unique identifier for a record you wish to enter,
the firebird RDBMS that Lester mentions refers to this as 'generators'.

to learn more I would suggest STW:

        http://lmgtfy.com/?q=sql+sequence

> 
> 
> Thanks !
> 
> 
> Regards,
> Eric
> 
>     --
>     PHP General Mailing List (http://www.php.net/)
>     To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 

--- End Message ---

--- Begin Message ---

At 7:07 AM +0100 2/13/10, Rene Veerman wrote:

Hi.

I'm looking for the most efficient way to insert several records and
retrieve the auto_increment values for the inserted rows, while
avoiding crippling concurrency problems caused by multiple php threads
doing this on the same table at potentially the same time.

-snip-

Any clues are greatly appreciated..
I'm looking for the most sql server independent way to do this.

Rene:

I'm not sure what would be the most efficient way to solve the race problems presented here, but you might want to not confront the race problem at all and solve this a bit more straight forward -- for example:

Three steps for each record:

1. Generate a unique value (i.e., date/time).

2. Insert the record with the unique value in a field and the auto_increment ID will be automatically created. 3. Then search for the record with that unique value and retrieve the auto_incremented ID value.

While this might take a few more cycles, it would work.

If you want your auto_increment ID's to be in sequence, then that's a different problem and if so, maybe you should rethink the problem. I've never seen a problem where the ID's were required to be anything other than unique.

Cheers,

tedd

--
-------
http://sperling.com  http://ancientstones.com  http://earthstones.com

--- End Message ---

--- Begin Message ---

In order to make this as "sql server independent" as possible, the first
thing you need to do is not use extended inserts as that is a MySQL
capability.  If you are insistent on using the extended inserts, then look
at the mysql_info() function.  That will return the number of rows inserted,
etc. on the last query.

-----Original Message-----
From: Rene Veerman [mailto:rene7...@gmail.com] 
Sent: Saturday, February 13, 2010 12:08 AM
To: php-general
Subject: [PHP] SQL insert () values (),(),(); how to get auto_increments
properly?

Hi.

I'm looking for the most efficient way to insert several records and
retrieve the auto_increment values for the inserted rows, while
avoiding crippling concurrency problems caused by multiple php threads
doing this on the same table at potentially the same time.

I'm using mysql atm, so i thought "stored procedures!"..
But alas, mysql docs are very basic.

I got the gist of how to setup a stored proc, but how to retrieve a
list of auto_increment ids still eludes me; last_insert_id() only
returns for the last row i believe.
So building an INSERT (...) VALUES (...),(...) at the php end, is
probably not the way to go then.

But the mysql docs don't show how to pass an array to a stored
procedure, so i can't just have the stored proc loop over an array,
insert per row, retrieve last_insert_id() into temp table, and return
the temp table contents for a list of auto_increment ids for inserted
rows.

Any clues are greatly appreciated..
I'm looking for the most sql server independent way to do this.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

--- End Message ---

--- Begin Message ---

On Sat, 2010-02-13 at 08:46 -0600, Joseph Thayne wrote:

> In order to make this as "sql server independent" as possible, the first
> thing you need to do is not use extended inserts as that is a MySQL
> capability.  If you are insistent on using the extended inserts, then look
> at the mysql_info() function.  That will return the number of rows inserted,
> etc. on the last query.
> 
> -----Original Message-----
> From: Rene Veerman [mailto:rene7...@gmail.com] 
> Sent: Saturday, February 13, 2010 12:08 AM
> To: php-general
> Subject: [PHP] SQL insert () values (),(),(); how to get auto_increments
> properly?
> 
> Hi.
> 
> I'm looking for the most efficient way to insert several records and
> retrieve the auto_increment values for the inserted rows, while
> avoiding crippling concurrency problems caused by multiple php threads
> doing this on the same table at potentially the same time.
> 
> I'm using mysql atm, so i thought "stored procedures!"..
> But alas, mysql docs are very basic.
> 
> I got the gist of how to setup a stored proc, but how to retrieve a
> list of auto_increment ids still eludes me; last_insert_id() only
> returns for the last row i believe.
> So building an INSERT (...) VALUES (...),(...) at the php end, is
> probably not the way to go then.
> 
> But the mysql docs don't show how to pass an array to a stored
> procedure, so i can't just have the stored proc loop over an array,
> insert per row, retrieve last_insert_id() into temp table, and return
> the temp table contents for a list of auto_increment ids for inserted
> rows.
> 
> Any clues are greatly appreciated..
> I'm looking for the most sql server independent way to do this.
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 


But getting the number of rows isn't really all that useful, as it won't
tell you what the auto increment id values are, and if any inserts fail,
it won't tell you which ones.

Thanks,
Ash
http://www.ashleysheridan.co.uk

--- End Message ---

--- Begin Message ---

Ashley Sheridan wrote:

But getting the number of rows isn't really all that useful, as it won't
tell you what the auto increment id values are, and if any inserts fail,
it won't tell you which ones.

Which is one of the reasons that MySQL still has problems with consistency ;)

Auto-increment only has limited use, you need to have a mechanism outside of the transaction to manage the values, and handle those insertions on a one by one basis. A transaction can only ALL be rolled back or committed. If some part fails, then the whole should fail ..... If you need to detect failures, they need to be done one at a time.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--- End Message ---

--- Begin Message ---

Robert Cummings wrote:

Ashley Sheridan wrote:

On Fri, 2010-02-12 at 16:12 -0500, Robert Cummings wrote:

John Allsopp wrote:

Hi everyone

There may be blinding bits of total ignorance in this so don't ignore the obvious.

This is a security question, but a sentence of background: I'm writing software for a mapping/location website and I want to be able to provide something others can plug into their website that would display their map.

So I'm providing a URL like http://www.mydomain.com?h=300&w=250&username=name&password=password

The idea is they can define their own height and width and it plugs in as an iframe.

That takes the username and password and throws it over web services to get back the data from which we can create the map.

My question (and it might be the wrong question) is how can I not give away the password to all and sundry yet still provide a self-contained URL?

MD5() (or SHA()) hash the information and supply that along with the settings. Then you know it was generated by your site. So you can do the following:

<?php

$height = 300;
$width = 250;
$username = 'username';
$key = md5( "SECRET_SALT-$heigh-$width-$username" );

$url = "http://www.mydomain.com?h=$height&w=$width&username=$username&key=$key";;

?>

Then when you get this URL via the iframe, you re-compute the expected key and then compare it against the given key. Since only you know the SECRET_SALT value then nobody should be able to forge the key.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

What about requiring them to sign in the first time to use your service,
and then give them a unique id which i tied to their details. You could
then get them to pass across this id in the url. You could link their
account maybe to some sorts of limits with regards to what they can
access maybe?

Presumably they ARE logged in when you create this URL for them... otherwise someone else could generate it :)

Cheers,
Rob.

Well no they are not logged in, it's just an embedded iframe so that's my main issue with my method, anyone could look at the web page source, pinch the URL of the iframe and they'd have the username and password.

I'd got as far as MD5, but not the Secret Salt bit.

The thing that warped my head was .. if the URL then becomes

http://www.mydomain.com?h=$height&w=$width&username=$username&key=$key that's the same thing isn't it .. a URL anyone could use anywhere? In a sense, we would have simply created another password, the MD5 key, which was a valid way to get into the system.

So then validating the domain from a list stops anyone using it anywhere and means we can switch it off by domain if we need to.

And .. we're not passing the password, right? We're not mixing that into the MD5? We are just saying, if you have the right username, if we know you've come via our code (secret salt), and you're from an approved domain, we'll let you in.

Sorted, I think .. unless you spot any faulty reasoning in the above. Thanks very much guys :-)

J

--- End Message ---

--- Begin Message ---

At 12:36 PM +0000 2/13/10, John Allsopp wrote:

Sorted, I think .. unless you spot any faulty reasoning in the above. Thanks very much guys :-)

The faulty reasoning is that you want to provide something to a select group of people but are exposing it to the world. That's not going to work.

You must devise a way to identify your group of people before you provide something to them -- else, what you provide is going to be public.

Cheers,

tedd
--
-------
http://sperling.com  http://ancientstones.com  http://earthstones.com

--- End Message ---

--- Begin Message ---

John Allsopp wrote:

Robert Cummings wrote:

Ashley Sheridan wrote:

On Fri, 2010-02-12 at 16:12 -0500, Robert Cummings wrote:

John Allsopp wrote:

Hi everyone

There may be blinding bits of total ignorance in this so don't ignore the obvious.

This is a security question, but a sentence of background: I'm writing software for a mapping/location website and I want to be able to provide something others can plug into their website that would display their map.

So I'm providing a URL like http://www.mydomain.com?h=300&w=250&username=name&password=password

The idea is they can define their own height and width and it plugs in as an iframe.

That takes the username and password and throws it over web services to get back the data from which we can create the map.

My question (and it might be the wrong question) is how can I not give away the password to all and sundry yet still provide a self-contained URL?

MD5() (or SHA()) hash the information and supply that along with the settings. Then you know it was generated by your site. So you can do the following:

<?php

$height = 300;
$width = 250;
$username = 'username';
$key = md5( "SECRET_SALT-$heigh-$width-$username" );

$url = "http://www.mydomain.com?h=$height&w=$width&username=$username&key=$key";;

?>

Then when you get this URL via the iframe, you re-compute the expected key and then compare it against the given key. Since only you know the SECRET_SALT value then nobody should be able to forge the key.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

What about requiring them to sign in the first time to use your service,
and then give them a unique id which i tied to their details. You could
then get them to pass across this id in the url. You could link their
account maybe to some sorts of limits with regards to what they can
access maybe?

Presumably they ARE logged in when you create this URL for them... otherwise someone else could generate it :)

Cheers,
Rob.

Well no they are not logged in, it's just an embedded iframe so that's my main issue with my method, anyone could look at the web page source, pinch the URL of the iframe and they'd have the username and password.

I'd got as far as MD5, but not the Secret Salt bit.

The thing that warped my head was .. if the URL then becomes

http://www.mydomain.com?h=$height&w=$width&username=$username&key=$key that's the same thing isn't it .. a URL anyone could use anywhere? In a sense, we would have simply created another password, the MD5 key, which was a valid way to get into the system.

So then validating the domain from a list stops anyone using it anywhere and means we can switch it off by domain if we need to.

And .. we're not passing the password, right? We're not mixing that into the MD5? We are just saying, if you have the right username, if we know you've come via our code (secret salt), and you're from an approved domain, we'll let you in.

Sorted, I think .. unless you spot any faulty reasoning in the above. Thanks very much guys :-)

I should have been clearer... the $key part means they don't need to be logged in, only that the URL was generated from a trusted location. Presumably that location gained the trust of the person requesting the URL in some manner... whether it be that they logged in, or that it automatically generated the URL for them based on some other criteria. The $key just embodies that relationship. The salt is necessary so that not just anyone can generate the key since then anyone can generate the URL and thus anyone can set the parameters as they please. This may not be important in your case, but you seemed to think it was important enough to originally consider their password :) This technique is also good for displaying images on your site that you don't want other sites linking to. You would hash in a timestamp and then if the requested time exceeds the timestamp and duration you can serve up a "Sorry that image is only available at www.my-awesome-site.com".

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--- End Message ---

--- Begin Message ---

John Allsopp wrote:

Well no they are not logged in, it's just an embedded iframe so that's my main issue with my method, anyone could look at the web page source, pinch the URL of the iframe and they'd have the username and password.

I think the only way to do it is to make a key per referring url and use the key as a get variable.

Either the referring url matches the key or it doesn't.

That should work with an object/iframe embedding of a resource, browsers by default send the referrer header.

A user may turn that off in a browser, but if a user turns that off, the user is denied the resource because they changed a default setting. Kind of like how I don't get some resources when I turn JavaScript off.
--- End Message ---

--- Begin Message ---

Michael A. Peters wrote:

John Allsopp wrote:

Well no they are not logged in, it's just an embedded iframe so that's my main issue with my method, anyone could look at the web page source, pinch the URL of the iframe and they'd have the username and password.

I think the only way to do it is to make a key per referring url and use the key as a get variable.

Either the referring url matches the key or it doesn't.

That should work with an object/iframe embedding of a resource, browsers by default send the referrer header.

Except when the object is handled by a plugin, they are notorious for not sending that header (and thus IMHO are broken). But it sounds like the resource you are providing is not requested by a plugin.
--- End Message ---

--- Begin Message ---

I'm looking for a report generator which will be used to create
management reports for my client from a MySQL database. The web site
is implemented in PHP.

Some characteristics that would be nice to have, roughly in order of
importance:

* It is moderately priced (a few hundred dollars at most) or free.

* A developer can easily learn to create moderately complex reports.

* A developer can easily add code to provide functionality not
supported by the generator.

* The generator can be installed on a shared server (it doesn't
require any unusual extensions or changes to php.ino or the server
configuration.

* A non-technical user can easily learn to create simple reports
without help.

A client-server solution is OK. The client has to run on Windows.

I've found one PHP product so far, phpreports. There are many other
reporting tools that might be suitable, but most of them seem to be
written in Java, or else they're black boxes.

Has anyone had experience with report generators that meet these
criteria? What would you recommend; what would you stay away from?

--- End Message ---