php-general Digest 13 Feb 2010 09:34:31 -0000 Issue 6588
Topics (messages 302048 through 302060):
Re: How to secure this
302048 by: Ashley Sheridan
302049 by: Robert Cummings
302050 by: Ryan Sun
302051 by: Ashley Sheridan
302052 by: Ryan Sun
302053 by: Eric Lee
Re: HTML & plain text in Outlook 2007
302054 by: Skip Evans
302055 by: Ashley Sheridan
302056 by: Michael A. Peters
302057 by: Robert Cummings
SQL insert () values (),(),(); how to get auto_increments properly?
302058 by: Rene Veerman
302060 by: Eric Lee
optional object arguments to a function
302059 by: Michael A. Peters
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
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?
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
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.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
authenticate by remote domain name or remote ip
$_SERVER['HTTP_REFERER']
then your clients will not have to put their username/password in clear text
http://www.mydomain.com?h=300&w=250
and you will just check if you have their domain on your list
I'm not sure if there is better one but
" 'HTTP_REFERER'
The address of the page (if any) which referred the user agent to
the current page. This is set by the user agent. Not all user agents
will set this, and some provide the ability to modify HTTP_REFERER as
a feature. In short, it cannot really be trusted. "
On Fri, Feb 12, 2010 at 4:26 PM, Robert Cummings <[email protected]> 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.
> --
> http://www.interjinn.com
> Application and Templating Framework for PHP
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
On Fri, 2010-02-12 at 18:25 -0500, Ryan Sun wrote:
> authenticate by remote domain name or remote ip
>
> $_SERVER['HTTP_REFERER']
>
> then your clients will not have to put their username/password in clear text
> http://www.mydomain.com?h=300&w=250
> and you will just check if you have their domain on your list
>
> I'm not sure if there is better one but
> " 'HTTP_REFERER'
> The address of the page (if any) which referred the user agent to
> the current page. This is set by the user agent. Not all user agents
> will set this, and some provide the ability to modify HTTP_REFERER as
> a feature. In short, it cannot really be trusted. "
>
>
> On Fri, Feb 12, 2010 at 4:26 PM, Robert Cummings <[email protected]> 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.
> > --
> > http://www.interjinn.com
> > Application and Templating Framework for PHP
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
I think Google does both the referrer check coupled with an id passed in
the URL. At least, this is what it did the last time I embedded one of
their maps.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
In that case, referer is for authentication, and id is for authorization, I
think
On Fri, Feb 12, 2010 at 6:23 PM, Ashley Sheridan
<[email protected]>wrote:
> On Fri, 2010-02-12 at 18:25 -0500, Ryan Sun wrote:
>
> authenticate by remote domain name or remote ip
>
> $_SERVER['HTTP_REFERER']
>
> then your clients will not have to put their username/password in clear
> texthttp://www.mydomain.com?h=300&w=250
> and you will just check if you have their domain on your list
>
> I'm not sure if there is better one but
> " 'HTTP_REFERER'
> The address of the page (if any) which referred the user agent to
> the current page. This is set by the user agent. Not all user agents
> will set this, and some provide the ability to modify HTTP_REFERER as
> a feature. In short, it cannot really be trusted. "
>
>
> On Fri, Feb 12, 2010 at 4:26 PM, Robert Cummings <[email protected]> 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.
> > --
> > http://www.interjinn.com
> > Application and Templating Framework for PHP
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
>
> I think Google does both the referrer check coupled with an id passed in
> the URL. At least, this is what it did the last time I embedded one of their
> maps.
>
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
--- End Message ---
--- Begin Message ---
On Sat, Feb 13, 2010 at 7:33 AM, Ryan Sun <[email protected]> wrote:
> In that case, referer is for authentication, and id is for authorization, I
> think
>
> On Fri, Feb 12, 2010 at 6:23 PM, Ashley Sheridan
> <[email protected]>wrote:
>
> > On Fri, 2010-02-12 at 18:25 -0500, Ryan Sun wrote:
> >
> > authenticate by remote domain name or remote ip
> >
> > $_SERVER['HTTP_REFERER']
> >
> > then your clients will not have to put their username/password in clear
> texthttp://www.mydomain.com?h=300&w=250
> > and you will just check if you have their domain on your list
> >
> > I'm not sure if there is better one but
> > " 'HTTP_REFERER'
> > The address of the page (if any) which referred the user agent to
> > the current page. This is set by the user agent. Not all user agents
> > will set this, and some provide the ability to modify HTTP_REFERER as
> > a feature. In short, it cannot really be trusted. "
> >
> >
> > On Fri, Feb 12, 2010 at 4:26 PM, Robert Cummings <[email protected]>
> 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?
>
How about RESTful like checking ?
It is much like what Rob said already.
but join all params by order and md5 it altogether
Regards,
Eric,
> > >>>
> > >>> 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.
> > > --
> > > http://www.interjinn.com
> > > Application and Templating Framework for PHP
> > >
> > > --
> > > PHP General Mailing List (http://www.php.net/)
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> >
> >
> >
> > I think Google does both the referrer check coupled with an id passed in
> > the URL. At least, this is what it did the last time I embedded one of
> their
> > maps.
> >
> >
> > Thanks,
> > Ash
> > http://www.ashleysheridan.co.uk
> >
> >
> >
>
--- End Message ---
--- Begin Message ---
Hey Guys,
Thanks for all the info on this. Sorry for the late reply, but
I got sidetracked writing the module that will send out all
these nasty emails.
I do have the text going on top, and I think I said, looks
perfect in Evolution and Thunderbird in both text and HTML.
I also read about MS ripping out the IE renderer and going
back in time basically.
I thought the solution of converting a Word document into HTML
with open office is interesting. I'll run that by the client
and test it out.
Bottom line is, HTML is just a total pain, and yes, the email
the client created in HTML using the most update to date CSS
and HTML!
Thanks!
Skip
Robert Cummings wrote:
Ashley Sheridan wrote:
On Thu, 2010-02-04 at 13:44 -0500, Robert Cummings wrote:
What about signing yourself up to some newsletters to see how they do
it?
Looking at the ones I get from Facebook as an example, they use the
boundary codes you mentioned, and I can't see anything particularly
special that's been added. What order are you sending the two message
parts by the way? I think the traditional way is to send the plain/text
part first, so that UA's that don't understand or support multipart
messages only use the first one. As you mentioned that you're seeing
HTML code at the top, I'd hazard a guess that you're sending the HTML
first?
The problem is most likely NOT his email structure, but the fact that
Microsoft in all their lock-in, make things difficult, non standard,
monopolistic philosophy chose to switch out the IE HTML renderer
(which was getting pretty decent with IE7 and IE8) with the Office
HTML renderer... so now basic things like CSS padding of something as
simple as a <p> tag is not possible. You now need to use margins
instead. The full list of supported attributes / CSS can be found here:
http://msdn.microsoft.com/en-us/library/aa338201.aspx
Obviously creating HTML emails was getting too easy (like it is with
Thunderbird). Of course... I guess it could be as bad as Google
stripping out the stylesheets entirely when viewing HTML content
which forces you to put the styles on the tags themselves.
... actually I'm not sure what's worse... at least you can use
standard styles with Google's gmail. Either way... making nice
looking HTML emails that work across Outlook, Thunderbird, Gmail,
Yahoo, and Hotmail is a pain in the ass.
Cheers,
Rob.
If he's getting HTML output at the top of the email, I would think that
did suggest that MS Word didn't like the structure. Making HTML emails
is now such a difficult job, as the email clients rendering engines tend
to not get updated as often as browsers, and there doesn't seem to be
any effort in bringing the rendering of the email clients together.
Whenever I create these emails I try to make sure I try no to get too
creative in the design, and use not only CSS styles, but properties of
the HTML tags themselves. It means I end up writing the CSS essentially
twice and backing it up with old deprecated HTML attributes, but it
usually does the trick.
Is there any effort by some standards group that email clients could
benefit from?
I think I skipped over some relevant information in the original post :)
Still... as you've said... email HTML sucks... and MS made it worse.
Cheers,
Rob.
--
====================================
Skip Evans
PenguinSites.com, LLC
503 S Baldwin St, #1
Madison WI 53703
608.250.2720
http://penguinsites.com
------------------------------------
Those of you who believe in
telekinesis, raise my hand.
-- Kurt Vonnegut
--- End Message ---
--- Begin Message ---
On Fri, 2010-02-12 at 19:03 -0600, Skip Evans wrote:
> Hey Guys,
>
> Thanks for all the info on this. Sorry for the late reply, but
> I got sidetracked writing the module that will send out all
> these nasty emails.
>
> I do have the text going on top, and I think I said, looks
> perfect in Evolution and Thunderbird in both text and HTML.
>
> I also read about MS ripping out the IE renderer and going
> back in time basically.
>
> I thought the solution of converting a Word document into HTML
> with open office is interesting. I'll run that by the client
> and test it out.
>
> Bottom line is, HTML is just a total pain, and yes, the email
> the client created in HTML using the most update to date CSS
> and HTML!
>
> Thanks!
>
> Skip
>
> Robert Cummings wrote:
> > Ashley Sheridan wrote:
> >> On Thu, 2010-02-04 at 13:44 -0500, Robert Cummings wrote:
> >>>>
> >>>> What about signing yourself up to some newsletters to see how they do
> >>>> it?
> >>>>
> >>>> Looking at the ones I get from Facebook as an example, they use the
> >>>> boundary codes you mentioned, and I can't see anything particularly
> >>>> special that's been added. What order are you sending the two message
> >>>> parts by the way? I think the traditional way is to send the plain/text
> >>>> part first, so that UA's that don't understand or support multipart
> >>>> messages only use the first one. As you mentioned that you're seeing
> >>>> HTML code at the top, I'd hazard a guess that you're sending the HTML
> >>>> first?
> >>> The problem is most likely NOT his email structure, but the fact that
> >>> Microsoft in all their lock-in, make things difficult, non standard,
> >>> monopolistic philosophy chose to switch out the IE HTML renderer
> >>> (which was getting pretty decent with IE7 and IE8) with the Office
> >>> HTML renderer... so now basic things like CSS padding of something as
> >>> simple as a <p> tag is not possible. You now need to use margins
> >>> instead. The full list of supported attributes / CSS can be found here:
> >>>
> >>> http://msdn.microsoft.com/en-us/library/aa338201.aspx
> >>>
> >>> Obviously creating HTML emails was getting too easy (like it is with
> >>> Thunderbird). Of course... I guess it could be as bad as Google
> >>> stripping out the stylesheets entirely when viewing HTML content
> >>> which forces you to put the styles on the tags themselves.
> >>>
> >>> ... actually I'm not sure what's worse... at least you can use
> >>> standard styles with Google's gmail. Either way... making nice
> >>> looking HTML emails that work across Outlook, Thunderbird, Gmail,
> >>> Yahoo, and Hotmail is a pain in the ass.
> >>>
> >>> Cheers,
> >>> Rob.
> >>
> >>
> >> If he's getting HTML output at the top of the email, I would think that
> >> did suggest that MS Word didn't like the structure. Making HTML emails
> >> is now such a difficult job, as the email clients rendering engines tend
> >> to not get updated as often as browsers, and there doesn't seem to be
> >> any effort in bringing the rendering of the email clients together.
> >>
> >> Whenever I create these emails I try to make sure I try no to get too
> >> creative in the design, and use not only CSS styles, but properties of
> >> the HTML tags themselves. It means I end up writing the CSS essentially
> >> twice and backing it up with old deprecated HTML attributes, but it
> >> usually does the trick.
> >>
> >> Is there any effort by some standards group that email clients could
> >> benefit from?
> >
> > I think I skipped over some relevant information in the original post :)
> >
> > Still... as you've said... email HTML sucks... and MS made it worse.
> >
> > Cheers,
> > Rob.
>
> --
> ====================================
> Skip Evans
> PenguinSites.com, LLC
> 503 S Baldwin St, #1
> Madison WI 53703
> 608.250.2720
> http://penguinsites.com
> ------------------------------------
> Those of you who believe in
> telekinesis, raise my hand.
> -- Kurt Vonnegut
>
That last reason could be why your email is failing! HTML email is the
one place where it is actually better to code "the old way" with tables
for markup, <font> tags, and very little (if any) CSS. If you do use any
CSS, it's best left inline as well, as some email clients strip out
anything within the <head> tags of your email.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
Ashley Sheridan wrote:
That last reason could be why your email is failing! HTML email is the
one place where it is actually better to code "the old way" with tables
for markup, <font> tags, and very little (if any) CSS. If you do use any
CSS, it's best left inline as well, as some email clients strip out
anything within the <head> tags of your email.
Do e-mail clients handle RTF?
That would seem a better way to do fancy styled e-mail to me than to use
html tags in an e-mail.
--- End Message ---
--- Begin Message ---
Michael A. Peters wrote:
Ashley Sheridan wrote:
That last reason could be why your email is failing! HTML email is the
one place where it is actually better to code "the old way" with tables
for markup, <font> tags, and very little (if any) CSS. If you do use any
CSS, it's best left inline as well, as some email clients strip out
anything within the <head> tags of your email.
Do e-mail clients handle RTF?
That would seem a better way to do fancy styled e-mail to me than to use
html tags in an e-mail.
<aside>
<em>*tongue in cheek*</em> I do HTML emails for the semantic tags!!
</aside>
:B
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
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.
--- End Message ---
--- Begin Message ---
On Sat, Feb 13, 2010 at 2:07 PM, Rene Veerman <[email protected]> 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.
>
> 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.
>
>
Rene
I have not been worked with mysql multi-insert before.
But just did a simple test on my mysql 5.0 copy.
I assume that you are using MyISAM table and will lock its read, writel
when inserting data.
When multi-insert was done, and did a select last_insert_id(). I saw that
only
the first inserted id was returned. Please take a look the following steps:
mysql> select * from temp;
Empty set (0.00 sec)
mysql> insert into temp (firstname, price) values ('dd', 10), ('cc', 3),
('bb', 99);
Query OK, 3 rows affected (0.00 sec)
Records: 3 Duplicates: 0 Warnings: 0
mysql> select last_insert_id();
+------------------+
| last_insert_id() |
+------------------+
| 1 |
+------------------+
1 row in set (0.00 sec)
mysql> insert into temp (firstname, price) values ('dd', 10), ('cc', 3),
('bb', 99);
Query OK, 3 rows affected (0.00 sec)
Records: 3 Duplicates: 0 Warnings: 0
mysql> select last_insert_id();
+------------------+
| last_insert_id() |
+------------------+
| 4 |
+------------------+
1 row in set (0.00 sec)
So, let's say three records was inserted, and the first inserted id was 1.
You get id from 1 to 3.
! This will not work on transaction-based insert !
Just a thought and tested on mysql but not on php.
Regards,
Eric
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
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?
--- End Message ---
