php-general Digest 12 Feb 2010 09:17:55 -0000 Issue 6586
php-general Digest 12 Feb 2010 09:17:55 - Issue 6586 Topics (messages 302012 through 302035): Re: PHP will NOT display this on my dev machine: Warning: session_start()... 302012 by: Adam Richardson 302013 by: Ashley Sheridan 302015 by: John Black Re: Persistent flag in memory 302014 by: Jochem Maas Mysql statement works in phpmyadmin but not in php page 302016 by: james stojan 302017 by: Joseph Thayne 302018 by: Kim Madsen 302019 by: Mari Masuda 302020 by: james stojan 302021 by: Joseph Thayne 302022 by: James McLean 302023 by: Joseph Thayne 302024 by: Jochem Maas 302025 by: James McLean 302026 by: James McLean 302027 by: Joseph Thayne 302030 by: Paul M Foster 302032 by: Joseph Thayne 302034 by: Paul M Foster Re: PHP Manual problems 302028 by: clancy_1.cybec.com.au 302031 by: Paul M Foster the limitation of upload_max_filesize, post_max_size 302029 by: pinate Checking correct usage of fopen(), stream_set_timeout() and fread() [newbie] 302033 by: Mark White expression engine 302035 by: Sudhakar 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 -- ---BeginMessage--- Do you have output buffering turned on? On Thu, Feb 11, 2010 at 1:19 PM, John Black s...@network-technologies.orgwrote: I am running into a strange problem and I hope someone might have an idea why this is happening. My installation of PHP will *NOT* display the warning message below on my development machine where it should display it (sample code at the bottom). Warning: session_start() [function.session-start]: Cannot send session cache limiter After receiving a bug report from a customer I tested my code on a XAMPP setup and, sure enough, it displayed the warning message. But on my machine, I can't find a message in my php log, it is as if this problem does not even exist (on my dev machine). My dev setup is: OS: ARCH 64bit (about a month out of date) PHP Dev stuff: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k DAV/2 SVN/1.6.6 PHP/5.3.1 with Suhosin-Patch xdebug-2.0.5-2-x86_64 php.ini error_reporting = E_ALL | E_STRICT display_errors = On display_startup_errors = On log_errors = On html_errors = On phpinfo() confirms that these settings are in effect display_errors On On error_reporting 32767 32767 So does anybody have any clue as to what could be causing this problem of not getting a warning message? Here is sample code: pThe warning should be below this line/p ?PHP session_start(); ? pThe warning should be above this line/p Which should produce the message below between the lines: Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent ( output started at file_name on line 2 ) but on my machine all I get is this in html source of the output: pThe warning should be below this line/p pThe warning should be above this line/p thx -- John Staat heißt das kälteste aller kalten Ungeheuer. Kalt lügt es auch; und diese Lüge kriecht aus seinem Munde: 'Ich, der Staat, bin das Volk.' [Friedrich Nietzsche] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Nephtali: PHP web framework that functions beautifully http://nephtaliproject.com ---End Message--- ---BeginMessage--- On Thu, 2010-02-11 at 19:19 +0100, John Black wrote: I am running into a strange problem and I hope someone might have an idea why this is happening. My installation of PHP will *NOT* display the warning message below on my development machine where it should display it (sample code at the bottom). Warning: session_start() [function.session-start]: Cannot send session cache limiter After receiving a bug report from a customer I tested my code on a XAMPP setup and, sure enough, it displayed the warning message. But on my machine, I can't find a message in my php log, it is as if this problem does not even exist (on my dev machine). My dev setup is: OS: ARCH 64bit (about a month out of date) PHP Dev stuff: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k DAV/2 SVN/1.6.6 PHP/5.3.1 with Suhosin-Patch xdebug-2.0.5-2-x86_64 php.ini error_reporting = E_ALL | E_STRICT display_errors = On display_startup_errors = On log_errors = On html_errors = On phpinfo() confirms that these settings are in effect display_errors On On error_reporting 32767 32767 So does anybody have any clue as to what could be
php-general Digest 12 Feb 2010 21:19:30 -0000 Issue 6587
php-general Digest 12 Feb 2010 21:19:30 - Issue 6587 Topics (messages 302036 through 302047): Re: PHP Manual problems 302036 by: Ashley Sheridan 302043 by: Nathan Rixham 302045 by: Andrew Ballard 302047 by: Ashley Sheridan Re: SOAP connect error 302037 by: Richard Quadling JQuery issue 302038 by: Devendra Jadhav 302039 by: Ashley Sheridan 302040 by: Jay Blanchard 302041 by: Devendra Jadhav Re: expression engine 302042 by: Nathan Rixham How to secure this 302044 by: John Allsopp 302046 by: Robert Cummings 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 -- ---BeginMessage--- On Thu, 2010-02-11 at 22:38 -0500, Paul M Foster wrote: On Fri, Feb 12, 2010 at 12:13:11PM +1100, clanc...@cybec.com.au wrote: On Thu, 11 Feb 2010 10:18:18 +, a...@ashleysheridan.co.uk (Ashley Sheridan) wrote: On Thu, 2010-02-11 at 10:16 +1100, Ross McKay wrote: ... There's a good reason for OpenOffice having some difficulties with MS Office documents. Back when MS rushed through getting their document standard ratified by ISO (which itself is a whole other story) they didn't explain all the details quite as well as they might have. Later on, MS found they were having some difficulty following their own 'standard' and so altered it in various ways in Office2007. Needless to say, ISO weren't too happy when MS asked if they could just 'change the specs' for their file format, and quite rightly refused to do so. In short, this means that there is a MS ISO standard that MS is the only one not trying to follow, and software like OpenOffice is left to reverse engineering the format again. When the first Word Macro virus appeared in the early 90s, the AV industry approached Microsoft for the specifications of the internal structure of the Word documents. After some discussion Microsoft agreed to make these available to firms who signed an NDA. Several large firms did so, but when they got the specifications they immediately discovered that they bore very little relation to the actual documents. When Microsoft was approached about this their reply was Well, that's all we've got! The industry had to run a joint program to reverse engineer the specifications before they could work out how to remove the virus. The story that went around was that with each update Microsoft hired a new batch of young graduates asidethey don't have preconceived notions (a.k.a. experience), and they don't have extravagant ideas of their own worth/aside, told them vaguely what they wanted, and left them to it. Then, as soon as they had something that sort of worked, they let them go again. So there was no continuity, no documentation, no hope of bug fixes, and very little likelihood that the next update would be improved in any meaningful sense. I have seen nothing to suggest that anything has changed. I suspect any lack of continuity was more due to the shifting of personnel internally to differing projects, rather than the hiring of all new coders each time. But more importantly, I suspect MS coders just coded without writing any docs. Coders usually suck at documentation and will avoid it unless forced. And if forced to write docs, the docs were just a toss-off no one ever actually looked at. Microsoft's attitude, I'm sure was, Why should we care about other players in the market? Just buy our crap and you won't have to worry about our formats. (Except until the next upgrade.) I think ISO's policy should be that if you're a company forwarding a standard, your off-the-shelf software should verifiably duplicate that standard. Otherwise, go pound sand. Same if you're a community proposing a standard. Produce some software which adheres to that standard or shut up. Paul -- Paul M. Foster Microsofts XML format should never have been made an ISO standard anyway. There's a bit of a conspiracy behind how they managed it, including large amounts of money and trade agreements trading hands, as well as secret voting... Thanks, Ash http://www.ashleysheridan.co.uk ---End Message--- ---BeginMessage--- Ashley Sheridan wrote: On Thu, 2010-02-11 at 22:38 -0500, Paul M Foster wrote: On Fri, Feb 12, 2010 at 12:13:11PM +1100, clanc...@cybec.com.au wrote: On Thu, 11 Feb 2010 10:18:18 +, a...@ashleysheridan.co.uk (Ashley Sheridan) wrote: On Thu, 2010-02-11 at 10:16 +1100, Ross McKay wrote: ... There's a good reason for OpenOffice having some difficulties with MS Office documents. Back when MS rushed through getting their
[PHP] expression engine
hi i am from auckland new zealand, has anyone worked on expression engine cms please advice thanks
Re: [PHP] PHP Manual problems
On Thu, 2010-02-11 at 22:38 -0500, Paul M Foster wrote: On Fri, Feb 12, 2010 at 12:13:11PM +1100, clanc...@cybec.com.au wrote: On Thu, 11 Feb 2010 10:18:18 +, a...@ashleysheridan.co.uk (Ashley Sheridan) wrote: On Thu, 2010-02-11 at 10:16 +1100, Ross McKay wrote: ... There's a good reason for OpenOffice having some difficulties with MS Office documents. Back when MS rushed through getting their document standard ratified by ISO (which itself is a whole other story) they didn't explain all the details quite as well as they might have. Later on, MS found they were having some difficulty following their own 'standard' and so altered it in various ways in Office2007. Needless to say, ISO weren't too happy when MS asked if they could just 'change the specs' for their file format, and quite rightly refused to do so. In short, this means that there is a MS ISO standard that MS is the only one not trying to follow, and software like OpenOffice is left to reverse engineering the format again. When the first Word Macro virus appeared in the early 90s, the AV industry approached Microsoft for the specifications of the internal structure of the Word documents. After some discussion Microsoft agreed to make these available to firms who signed an NDA. Several large firms did so, but when they got the specifications they immediately discovered that they bore very little relation to the actual documents. When Microsoft was approached about this their reply was Well, that's all we've got! The industry had to run a joint program to reverse engineer the specifications before they could work out how to remove the virus. The story that went around was that with each update Microsoft hired a new batch of young graduates asidethey don't have preconceived notions (a.k.a. experience), and they don't have extravagant ideas of their own worth/aside, told them vaguely what they wanted, and left them to it. Then, as soon as they had something that sort of worked, they let them go again. So there was no continuity, no documentation, no hope of bug fixes, and very little likelihood that the next update would be improved in any meaningful sense. I have seen nothing to suggest that anything has changed. I suspect any lack of continuity was more due to the shifting of personnel internally to differing projects, rather than the hiring of all new coders each time. But more importantly, I suspect MS coders just coded without writing any docs. Coders usually suck at documentation and will avoid it unless forced. And if forced to write docs, the docs were just a toss-off no one ever actually looked at. Microsoft's attitude, I'm sure was, Why should we care about other players in the market? Just buy our crap and you won't have to worry about our formats. (Except until the next upgrade.) I think ISO's policy should be that if you're a company forwarding a standard, your off-the-shelf software should verifiably duplicate that standard. Otherwise, go pound sand. Same if you're a community proposing a standard. Produce some software which adheres to that standard or shut up. Paul -- Paul M. Foster Microsofts XML format should never have been made an ISO standard anyway. There's a bit of a conspiracy behind how they managed it, including large amounts of money and trade agreements trading hands, as well as secret voting... Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] RE: SOAP connect error
On 11 February 2010 16:04, Eric Lommatsch er...@micronix.com wrote:
Are you using wsdl? If so, does the WSDL file contain the information that
the port to use for the requests is on port 8080?
--
-
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=ZEND002498r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
First, I am sorry for not getting back to this yesterday. I had some other
things come up.
As far as I know this website is using WSDL. I know that one of the early
issues I ran into in trying to get this to work was not having the wsdl.php
file in the path.
That having been said are you talking about the wsdl file on the server that
is providing the service or are you talking about the wsdl file on the system
hosting the webpage.
I can get everything to work correctly when I am working from our internal
development server. But when I attempt to put the file on the hosted site our
clients would ultimately be using I am getting the connect error.
I have compared the wsdl.php files on these two servers and neither of them
have specific information about the port in them.
Here is the code that I am using to connect to the webservice:
$webservices_uri =
http://xx.xx.xx.xx:8080/jasperserver/services/repository;;
Here is the code where I am trying to connect:
function ws_checkUsername($username, $password)
{
$connection_params = array(user = $username, pass =
$password);
$info = new SOAP_client($GLOBALS[webservices_uri], false,
false, $connection_params);
$op_xml = request
operationName=\list\resourceDescriptor name=\\ wsType=\folder\
uriString=\\ isNew=\false\.
label/label/resourceDescriptor/request;
$params = array(request = $op_xml );
$response = $info-call(list,$params,array('namespace' =
$GLOBALS[namespace]));
return $response;
}
This is working when I use the IP address of the server behind the firewall,
but when I try to use the address that is open through the firewall it is not
connecting. I can connect to the external IP address by entering it into the
browser and it does ask for the username and password.
Thank you
Eric H. Lommatsch
Programmer
360 Business
2087 South Grant Street
Denver, CO 80210
Tel 303-777-8939 Ext 23
Fax 888-282-9927
er...@360b.com
Run this at the command line ...
php -r echo file_get_contents('http://www.google.com');
Do you get the google home page?
I suspect your browser is using a proxy, but your default gateway is
set to something different
There should only be 1 WSDL url. That is the URL of the WSDL file
associated with the service you are using.
It may be cached to a physical file.
Either way, it probably doesn't know that YOU are behind a firewall.
So. You need to proxy the calls.
You can use the default stream context.
Take a look at my user note on
http://www.php.net/manual/en/function.stream-context-get-default.php.
The site it relates to is probably dead now.
You may be able to assign the proxy details to the SOAPClient.
For HTTP authentication, the login and password options can be used
to supply credentials. For making an HTTP connection through a proxy
server, the options proxy_host, proxy_port, proxy_login and
proxy_password are also available. For HTTPS client certificate
authentication use local_cert and passphrase options. An
authentication may be supplied in the authentication option. The
authentication method may be either SOAP_AUTHENTICATION_BASIC
(default) or SOAP_AUTHENTICATION_DIGEST.
(http://www.php.net/manual/en/soapclient.soapclient.php#soapclient.soapclient.parameters)
Does any of that help?
--
-
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=ZEND002498r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] JQuery issue
Hi All,
Sorry for asking question at wrong place.. (Please tell me where to as
questions about JQuery)
I am using JQuery Validate plugin.
I am validating form which contains two items Name phone number
Phone number contains three text boxes.
Now the default behavior of JQuery Validate put error message in front of
text boxes. It is ok for Name but,
for phone number i have placed three text boxes in a row. So i want single
message for this after the third text box.
So i did following thing
var form = $(#frm_something)
form.validate({
submitHandler: function() {
alert(Valid date range!)
},
groups: {
dateRange: phone1 phone2 phone3
},
errorPlacement: function(error, element) {
form.find(.error_container).append(error);
}
});
with above it is showing all errors in error_container span.
I want only date error should come in error_container everything else should
be as it is before (in-front of text boxes)
Please help..
--
Devendra Jadhav
Re: [PHP] JQuery issue
On Fri, 2010-02-12 at 17:09 +0530, Devendra Jadhav wrote:
Hi All,
Sorry for asking question at wrong place.. (Please tell me where to as
questions about JQuery)
I am using JQuery Validate plugin.
I am validating form which contains two items Name phone number
Phone number contains three text boxes.
Now the default behavior of JQuery Validate put error message in front of
text boxes. It is ok for Name but,
for phone number i have placed three text boxes in a row. So i want single
message for this after the third text box.
So i did following thing
var form = $(#frm_something)
form.validate({
submitHandler: function() {
alert(Valid date range!)
},
groups: {
dateRange: phone1 phone2 phone3
},
errorPlacement: function(error, element) {
form.find(.error_container).append(error);
}
});
with above it is showing all errors in error_container span.
I want only date error should come in error_container everything else should
be as it is before (in-front of text boxes)
Please help..
As JQuery is Javascript, you're better off asking on a Javascript list
if you can't find a dedicated JQuery one.
Thanks,
Ash
http://www.ashleysheridan.co.uk
RE: [PHP] JQuery issue
[snip] Sorry for asking question at wrong place.. (Please tell me where to as questions about JQuery) [/snip] Google is your friend http://docs.jquery.com/Discussion#Official_Forums -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] JQuery issue
thank you all On Fri, Feb 12, 2010 at 5:54 PM, Jay Blanchard jblanch...@pocket.comwrote: [snip] Sorry for asking question at wrong place.. (Please tell me where to as questions about JQuery) [/snip] Google is your friend http://docs.jquery.com/Discussion#Official_Forums -- Devendra Jadhav देवेंद्र जाधव
[PHP] Re: expression engine
Sudhakar wrote: hi i am from auckland new zealand, has anyone worked on expression engine cms please advice thanks no but a very high percentage of the good graphic designers I know will use nothing but; all of them really like it. from a programmers point of view, i just don't know :) regards! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Manual problems
Ashley Sheridan wrote: On Thu, 2010-02-11 at 22:38 -0500, Paul M Foster wrote: On Fri, Feb 12, 2010 at 12:13:11PM +1100, clanc...@cybec.com.au wrote: On Thu, 11 Feb 2010 10:18:18 +, a...@ashleysheridan.co.uk (Ashley Sheridan) wrote: On Thu, 2010-02-11 at 10:16 +1100, Ross McKay wrote: ... There's a good reason for OpenOffice having some difficulties with MS Office documents. Back when MS rushed through getting their document standard ratified by ISO (which itself is a whole other story) they didn't explain all the details quite as well as they might have. Later on, MS found they were having some difficulty following their own 'standard' and so altered it in various ways in Office2007. Needless to say, ISO weren't too happy when MS asked if they could just 'change the specs' for their file format, and quite rightly refused to do so. In short, this means that there is a MS ISO standard that MS is the only one not trying to follow, and software like OpenOffice is left to reverse engineering the format again. When the first Word Macro virus appeared in the early 90s, the AV industry approached Microsoft for the specifications of the internal structure of the Word documents. After some discussion Microsoft agreed to make these available to firms who signed an NDA. Several large firms did so, but when they got the specifications they immediately discovered that they bore very little relation to the actual documents. When Microsoft was approached about this their reply was Well, that's all we've got! The industry had to run a joint program to reverse engineer the specifications before they could work out how to remove the virus. The story that went around was that with each update Microsoft hired a new batch of young graduates asidethey don't have preconceived notions (a.k.a. experience), and they don't have extravagant ideas of their own worth/aside, told them vaguely what they wanted, and left them to it. Then, as soon as they had something that sort of worked, they let them go again. So there was no continuity, no documentation, no hope of bug fixes, and very little likelihood that the next update would be improved in any meaningful sense. I have seen nothing to suggest that anything has changed. I suspect any lack of continuity was more due to the shifting of personnel internally to differing projects, rather than the hiring of all new coders each time. But more importantly, I suspect MS coders just coded without writing any docs. Coders usually suck at documentation and will avoid it unless forced. And if forced to write docs, the docs were just a toss-off no one ever actually looked at. Microsoft's attitude, I'm sure was, Why should we care about other players in the market? Just buy our crap and you won't have to worry about our formats. (Except until the next upgrade.) I think ISO's policy should be that if you're a company forwarding a standard, your off-the-shelf software should verifiably duplicate that standard. Otherwise, go pound sand. Same if you're a community proposing a standard. Produce some software which adheres to that standard or shut up. Paul -- Paul M. Foster Microsofts XML format should never have been made an ISO standard anyway. There's a bit of a conspiracy behind how they managed it, including large amounts of money and trade agreements trading hands, as well as secret voting... There was a great article in the NYT about microsoft from Dick Brass (a former Vice President) that's well worth a read: http://www.nytimes.com/2010/02/04/opinion/04brass.html regards :) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] How to secure this
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=300w=250username=namepassword=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? Thanks in advance :-) Cheers J -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Manual problems
On Thu, Feb 11, 2010 at 5:18 AM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: There's a good reason for OpenOffice having some difficulties with MS Office documents. Back when MS rushed through getting their document standard ratified by ISO (which itself is a whole other story) they didn't explain all the details quite as well as they might have. Later on, MS found they were having some difficulty following their own 'standard' and so altered it in various ways in Office2007. Needless to say, ISO weren't too happy when MS asked if they could just 'change the specs' for their file format, and quite rightly refused to do so. In short, this means that there is a MS ISO standard that MS is the only one not trying to follow, and software like OpenOffice is left to reverse engineering the format again. Thanks, Ash http://www.ashleysheridan.co.uk You may be right as far as standards of the file format are concerned, but IMO OpenOffice.org just isn't quite where I'd like it compared to Microsoft Office, at least up through 2003. (I really dislike the whole reorganized interface they created for 2007.) Particularly there are differences between Excel and Calc that really annoy me. I would like to like OpenOffice.org, but I spend too much of the time I use it being frustrated by it. (Wow, has this thread digressed!) Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How to secure this
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=300w=250username=namepassword=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=$heightw=$widthusername=$usernamekey=$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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Manual problems
On Fri, 2010-02-12 at 16:03 -0500, Andrew Ballard wrote: On Thu, Feb 11, 2010 at 5:18 AM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: There's a good reason for OpenOffice having some difficulties with MS Office documents. Back when MS rushed through getting their document standard ratified by ISO (which itself is a whole other story) they didn't explain all the details quite as well as they might have. Later on, MS found they were having some difficulty following their own 'standard' and so altered it in various ways in Office2007. Needless to say, ISO weren't too happy when MS asked if they could just 'change the specs' for their file format, and quite rightly refused to do so. In short, this means that there is a MS ISO standard that MS is the only one not trying to follow, and software like OpenOffice is left to reverse engineering the format again. Thanks, Ash http://www.ashleysheridan.co.uk You may be right as far as standards of the file format are concerned, but IMO OpenOffice.org just isn't quite where I'd like it compared to Microsoft Office, at least up through 2003. (I really dislike the whole reorganized interface they created for 2007.) Particularly there are differences between Excel and Calc that really annoy me. I would like to like OpenOffice.org, but I spend too much of the time I use it being frustrated by it. (Wow, has this thread digressed!) Andrew I must admit that Calc doesn't seem quite as fully featured, particularly with respect to macros. It does have other good features though that make it better, like native external database connectivity. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] How to secure this
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=300w=250username=namepassword=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=$heightw=$widthusername=$usernamekey=$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
Re: [PHP] How to secure this
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=300w=250username=namepassword=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=$heightw=$widthusername=$usernamekey=$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
Re: [PHP] How to secure this
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=300w=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 rob...@interjinn.com 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=300w=250username=namepassword=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=$heightw=$widthusername=$usernamekey=$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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] How to secure this
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=300w=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 rob...@interjinn.com 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=300w=250username=namepassword=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=$heightw=$widthusername=$usernamekey=$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
Re: [PHP] How to secure this
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 a...@ashleysheridan.co.ukwrote: 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=300w=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 rob...@interjinn.com 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=300w=250username=namepassword=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=$heightw=$widthusername=$usernamekey=$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
Re: [PHP] How to secure this
On Sat, Feb 13, 2010 at 7:33 AM, Ryan Sun ryansu...@gmail.com 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 a...@ashleysheridan.co.ukwrote: 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=300w=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 rob...@interjinn.com 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=300w=250username=namepassword=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=$heightw=$widthusername=$usernamekey=$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
Re: [PHP] HTML plain text in Outlook 2007
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTML plain text in Outlook 2007
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
Re: [PHP] HTML plain text in Outlook 2007
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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTML plain text in Outlook 2007
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[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
