php-general Digest 7 Apr 2007 11:35:02 -0000 Issue 4720
Topics (messages 252175 through 252190):
Submitting as POST. Why?
252175 by: barophobia
252177 by: Jochem Maas
252178 by: Mike Shanley
252180 by: Robert Cummings
252182 by: Paul Novitski
252185 by: Tijnema !
252188 by: Stut
252189 by: Børge Holen
252190 by: JM Guillermin
Need a working SOAP example using PHP SOAP
252176 by: Daevid Vincent
252179 by: Jochem Maas
252181 by: Daevid Vincent
PHP has encountered an Access Violation at 01F13157?!?!?!?
252183 by: Afan Pasalic
252186 by: Tijnema !
252187 by: Tijnema !
Re: advice on sql injection/XSS prevention
252184 by: Jordan Forssman
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 ---
My Peeps,
I only know of one reason to submit a form as POST and that is because
you can submit more data in one shot.
What other reasons are there?
Chris.
--- End Message ---
--- Begin Message ---
barophobia wrote:
> My Peeps,
>
> I only know of one reason to submit a form as POST and that is because
> you can submit more data in one shot.
>
>
> What other reasons are there?
upload a file?
not have bag of cruft in the url/addressbar?
because POST and GET are semantically different ...
POST assumes that the submission may have side effects (e.g. registration, send
a email, update a page)
GET assumes no such thing, you merely 'get' a page from the server.
>
>
>
> Chris.
>
--- End Message ---
--- Begin Message ---
Chris,
When you submit via GET, all the info shows up in the URL, so people can
tamper with it however they like. Also, people can bookmark it as well.
With POST, everything stays hidden, mostly untamperable, and
unbookmarkable. POST might sound clearly better, but unless it's
important that people don't change anything, then go with GET.
barophobia wrote:
My Peeps,
I only know of one reason to submit a form as POST and that is because
you can submit more data in one shot.
What other reasons are there?
Chris.
--
Mike Shanley
~you are almost there~
"A new eye opens on March 5." -Omniversalism.com
--- End Message ---
--- Begin Message ---
On Fri, 2007-04-06 at 20:44 -0400, Mike Shanley wrote:
> Chris,
>
> When you submit via GET, all the info shows up in the URL, so people can
> tamper with it however they like. Also, people can bookmark it as well.
Quite true.
> With POST, everything stays hidden, mostly untamperable, and
Bullshit. It is VERY easy to tamper with post data.
> unbookmarkable. POST might sound clearly better, but unless it's
> important that people don't change anything, then go with GET.
I go with POST almost exclusively when doing forms. I do so because my
form engine embeds various information (non-security sensitive
information) for the form. It works using get also, but it's ugly having
stuff like that in the URL. Additionally, for longer forms, there's a
limit to which browsers must adhere to acknowledge. I believe browsers
are only required to process 1024 bytes from a URL. Obviously some
browsers will process more, but now you're counting on a non-standard
feature. For the most part, if there's stuff in the URL parameters, then
they came from a link or a redirect.
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
barophobia wrote:
I only know of one reason to submit a form as POST and that is because
you can submit more data in one shot.
At 4/6/2007 05:44 PM, Mike Shanley wrote:
When you submit via GET, all the info shows up in the URL, so people
can tamper with it however they like. Also, people can bookmark it as well.
In fact that very tamperability is one of the advantages of GET. For
certain types of service it can be a boon to the user to be able to
tweak the querystring. It enables even mildly technically-oriented
people to roll their own queries for search engines, map engines,
online resource guides, catalogs, etc.
When I deliberately expose the communication channel between a form
and a lookup engine like that, I try to choose querystring parameter
names that are simple and easy to remember such as isbn, author, and title.
Obviously you have to make sure someone can't hack your system
through the querystring, but you should already be doing this anyway
whether you're using POST or GET.
Regards,
Paul
__________________________
Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com
--- End Message ---
--- Begin Message ---
On 4/7/07, Paul Novitski <[EMAIL PROTECTED]> wrote:
>barophobia wrote:
>>I only know of one reason to submit a form as POST and that is because
>>you can submit more data in one shot.
At 4/6/2007 05:44 PM, Mike Shanley wrote:
>When you submit via GET, all the info shows up in the URL, so people
>can tamper with it however they like. Also, people can bookmark it as well.
In fact that very tamperability is one of the advantages of GET. For
certain types of service it can be a boon to the user to be able to
tweak the querystring. It enables even mildly technically-oriented
people to roll their own queries for search engines, map engines,
online resource guides, catalogs, etc.
When I deliberately expose the communication channel between a form
and a lookup engine like that, I try to choose querystring parameter
names that are simple and easy to remember such as isbn, author, and title.
Obviously you have to make sure someone can't hack your system
through the querystring, but you should already be doing this anyway
whether you're using POST or GET.
Regards,
Paul
Good point, It's nice if search machine's are using GET, as you could
make a script to search in their search machine by just going to an
url like http://www.google.com/search?q=<search>, instead of making a
form.
Tijnema
--- End Message ---
--- Begin Message ---
barophobia wrote:
I only know of one reason to submit a form as POST and that is because
you can submit more data in one shot.
What other reasons are there?
The difference between get and post is not what you *can* do, it's what
you *should* do.
Get, as the name implies, should be used when retrieving a page. The
URL, including the query string, should contain info needed to retrieve
the right page. No significant changes to either session or persistant
data should be made in response to a get request.
Post is used to send data to the server, and should be used when
modifying something. That something could be 'the logged in user' (in
the case of a login form), or 'a blog entry' (in the case of a blog
entry editor form).
Put more simply, get requests should not make significant changes to the
data or state of your website, always use post requests for that.
These implied "rules" have existed since HTTP was invented, and when you
think about it they make a lot of sense. They also get emphasized by the
existance of so-called web accelerators that simply pre-fetch URLs on
the page the user is viewing. If you have simple links (i.e. get
requests) that make changes to your websites data or state, the
accelerator will seriously screw it up.
As an illustration, consider a blog editing app. You log in and view a
list of entries in your blog. Each one has edit and delete links next to
them. These are plain URLs. The delete link uses javascript to ask the
user for confirmation. The accelerator happily goes through these links,
helpfully pre-fetching them for you. This is fine for the edit links,
but the delete links cause the website to delete your entire blog. Oops.
Hope that's made it clear.
-Stut
--- End Message ---
--- Begin Message ---
On Saturday 07 April 2007 05:56, Paul Novitski wrote:
> >barophobia wrote:
> >>I only know of one reason to submit a form as POST and that is because
> >>you can submit more data in one shot.
>
> At 4/6/2007 05:44 PM, Mike Shanley wrote:
> >When you submit via GET, all the info shows up in the URL, so people
> >can tamper with it however they like. Also, people can bookmark it as
> > well.
>
> In fact that very tamperability is one of the advantages of GET. For
> certain types of service it can be a boon to the user to be able to
> tweak the querystring. It enables even mildly technically-oriented
> people to roll their own queries for search engines, map engines,
> online resource guides, catalogs, etc.
>
> When I deliberately expose the communication channel between a form
> and a lookup engine like that, I try to choose querystring parameter
> names that are simple and easy to remember such as isbn, author, and title.
>
> Obviously you have to make sure someone can't hack your system
> through the querystring, but you should already be doing this anyway
> whether you're using POST or GET.
>
GET leaves someone with an option to easily make a frontend... take ktorrent
feks. This little bugger contains some khtml code and a search box, and
withing this search box you can add torrent tracker sites. Imho easily
downloadable and consistent when it comes to searching (well it shows the
complete site inside then browserwindow, but you don't go looking for the
search form box.)
> Regards,
>
> Paul
> __________________________
>
> Paul Novitski
> Juniper Webcraft Ltd.
> http://juniperwebcraft.com
--
---
Børge
http://www.arivene.net
---
--- End Message ---
--- Begin Message ---
Maybe this could help...
GET
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3
POST
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
URI
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.1
jm
----- Original Message -----
From: "barophobia" <[EMAIL PROTECTED]>
To: "php-general" <[email protected]>
Sent: Saturday, April 07, 2007 2:35 AM
Subject: [PHP] Submitting as POST. Why?
My Peeps,
I only know of one reason to submit a form as POST and that is because
you can submit more data in one shot.
What other reasons are there?
Chris.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
I've been searching all day (read wasting) trying to get a working SOAP
example that uses the new PHP SOAP functions.
http://us2.php.net/manual/en/ref.soap.php
I've tried this one from nearly THREE years ago (03/16/2004):
http://devzone.zend.com/node/view/id/689
And this one, which is apparently written in the future (05/01/2007):
http://www.netmag.co.uk/zine/develop/make-your-own-soap
Nothing works. Mostly I get these very unhelpful errors:
Fatal error: Uncaught SoapFault exception: [HTTP] Could not connect to host
in /home/machine/StockQuote/client3.php:6
Stack trace:
#0 [internal function]: SoapClient->__doRequest('<?xml version="...',
'http://machine....', 'urn:xmethods-de...', 1, 0)
#1 [internal function]: SoapClient->__call('getQuote', Array)
#2 /home/machine/StockQuote/client3.php(6): SoapClient->getQuote('ibm')
#3 {main}
thrown in /home/machine/StockQuote/client3.php on line 6
Now you might think, "Can you actually get to the host?". And why YES, if I
try to hit the "server1.php" page that is defined in the WDSL file, I get
this error:
SOAP-ENV:ServerBad Request. Can't find HTTP_RAW_POST_DATA
Also, I have soap.wsdl_cache_enabled = 0, yet how come I still see
wsdl-47087234058273450982734508 files in /tmp ?! (yes I've restarted apache)
Does anyone know of a current, WORKING, example, ideally in a .tar file or
something so I don't have to waste a lot more time copy/paste/format/remove
whitespace/etc.?
It's also frustrating that the PHP SOAP function section doesn't have an
example, nor even links to an example. :-\
--- End Message ---
--- Begin Message ---
not very helpful, but an apt quote from 'the man':
http://fplanque.net/Blog/devblog/2005/12/21/rasmus_i_don_t_like_soap
Daevid Vincent wrote:
> I've been searching all day (read wasting) trying to get a working SOAP
> example that uses the new PHP SOAP functions.
>
> http://us2.php.net/manual/en/ref.soap.php
>
> I've tried this one from nearly THREE years ago (03/16/2004):
> http://devzone.zend.com/node/view/id/689
>
> And this one, which is apparently written in the future (05/01/2007):
> http://www.netmag.co.uk/zine/develop/make-your-own-soap
>
> Nothing works. Mostly I get these very unhelpful errors:
a, they are helpful
b, you should catch exceptions
c, could you be having a problem related to the allow_url_fopen ini setting?
>
> Fatal error: Uncaught SoapFault exception: [HTTP] Could not connect to host
> in /home/machine/StockQuote/client3.php:6
> Stack trace:
> #0 [internal function]: SoapClient->__doRequest('<?xml version="...',
> 'http://machine....', 'urn:xmethods-de...', 1, 0)
> #1 [internal function]: SoapClient->__call('getQuote', Array)
> #2 /home/machine/StockQuote/client3.php(6): SoapClient->getQuote('ibm')
> #3 {main}
> thrown in /home/machine/StockQuote/client3.php on line 6
>
> Now you might think, "Can you actually get to the host?". And why YES, if I
> try to hit the "server1.php" page that is defined in the WDSL file, I get
> this error:
>
> SOAP-ENV:ServerBad Request. Can't find HTTP_RAW_POST_DATA
>
> Also, I have soap.wsdl_cache_enabled = 0, yet how come I still see
> wsdl-47087234058273450982734508 files in /tmp ?! (yes I've restarted apache)
probably soap uses these tmp files but because soap.wsdl_cache_enabled is Off
the files are being regenerated on each request (check the file mtimes).
alternatively you may think soap.wsdl_cache_enabled is Off but actually its
being
turned On somewhere?
>
> Does anyone know of a current, WORKING, example, ideally in a .tar file or
> something so I don't have to waste a lot more time copy/paste/format/remove
> whitespace/etc.?
>
> It's also frustrating that the PHP SOAP function section doesn't have an
> example, nor even links to an example. :-\
there is quite a bit of example code in the SOAP section if you ask me:
http://php.net/manual/en/function.soap-soapclient-construct.php
>
--- End Message ---
--- Begin Message ---
> not very helpful, but an apt quote from 'the man':
> http://fplanque.net/Blog/devblog/2005/12/21/rasmus_i_don_t_like_soap
Yeah, unfortunately, I *must* use SOAP. Not my choice, but politics and
company decree, blah blah...
> b, you should catch exceptions
These were the examples from the page. I didn't want to add extra
complexity.
> c, could you be having a problem related to the
> allow_url_fopen ini setting?
Now we're talkin!
Okay, I made sure that allow_url_fopen and allow_url_include are both "on".
Verified via phpinfo();
Still no luck. :-\
However, this sparked an idea...
I have been using my WinXP and IE to hit my Gentoo notebook running
apache2/php/etc. (samba mounting the /home/machine/... to edit the files)
When I fired up KDE and hit the EXACT same pages (which are now local), they
magically worked!
So now the question is, what setting do I have to change in my php.ini file
to get remote requests to work?
> alternatively you may think soap.wsdl_cache_enabled is Off
> but actually its being
> turned On somewhere?
It's off in the php.ini file, also specifically turned off in each
server.php file. Verified off via phpinfo();
> > It's also frustrating that the PHP SOAP function section
> doesn't have an
> > example, nor even links to an example. :-\
>
> there is quite a bit of example code in the SOAP section if
> you ask me:
>
> http://php.net/manual/en/function.soap-soapclient-construct.php
No. those are fragments of ways to call the methods.
NOT full working examples of client/server/wsdl
--- End Message ---
--- Begin Message ---
hi,
I just installed php 5.2.1-win32-installer on win box (XP). use IIS.
created index.html file and localhost/index.html is ok.
created phpinfo.php (with only phpinfo()) and was ok.
then installed Zend 5.5.0 (try) and suddenly, IE is giving me blank screen.
installed firefox 2 and got the error message from subject line.
according google and php.net, it's bug?!?
any idea?
thanks for any help.
-afan
--- End Message ---
--- Begin Message ---
On 4/7/07, Afan Pasalic <[EMAIL PROTECTED]> wrote:
hi,
I just installed php 5.2.1-win32-installer on win box (XP). use IIS.
created index.html file and localhost/index.html is ok.
created phpinfo.php (with only phpinfo()) and was ok.
then installed Zend 5.5.0 (try) and suddenly, IE is giving me blank screen.
installed firefox 2 and got the error message from subject line.
according google and php.net, it's bug?!?
any idea?
thanks for any help.
-afan
So, what are the error messages in your firefox? and do you have any
error messages in your apache error log?
Tijnema
--- End Message ---
--- Begin Message ---
On 4/7/07, Tijnema ! <[EMAIL PROTECTED]> wrote:
On 4/7/07, Afan Pasalic <[EMAIL PROTECTED]> wrote:
> hi,
> I just installed php 5.2.1-win32-installer on win box (XP). use IIS.
> created index.html file and localhost/index.html is ok.
> created phpinfo.php (with only phpinfo()) and was ok.
> then installed Zend 5.5.0 (try) and suddenly, IE is giving me blank screen.
> installed firefox 2 and got the error message from subject line.
>
> according google and php.net, it's bug?!?
>
> any idea?
>
> thanks for any help.
>
> -afan
So, what are the error messages in your firefox? and do you have any
error messages in your apache error log?
Tijnema
I'm sorry, i didn't read your title, so i didn't know what your error
was, but it is a bug. Take a look here:
http://bugs.php.net/bug.php?id=40662
There hasn't been a solution posted, because there were no backtraces
provided. If you could provide them, it might solve the bug.
Also, this bug appeared in PHP5RC3 too, there was a fix, but link is
dead, and the fix they tell is "Use CVS snapshot.", and of course that
would worked then, but that's not relevant anymore, as the thead is
from jun 2004...., anyway if you want to read it:
http://bugs.php.net/bug.php?id=29127
Tijnema
--- End Message ---
--- Begin Message ---
Actually there is a tool available for automated validation of PHP code.
It's called static source code analysis which, very simply stated, acts like
a spell checker for custom developed code. This tool is very accurate at
finding, especially SQL injection and XSS, and can be run directly against
the source code so it doesn't need the application to be up and running.
This company
http://www.armorize.com/services/securityasaservice?utm_source=jordan&utm_medium=post
is offering this kind of tool delivered as a service directly over the Web
which means you can either request that those authorized people verify thier
code security before posting, or you can do it after they have posted. The
tool shows the vulnerability as well as the tainted origin that introduces
it and provides fix suggestions, etc so everything can be fixed in a very
short time with very little effort -- no installation required.
From: Zoltán Németh <[EMAIL PROTECTED]>
To: Bing Du <[EMAIL PROTECTED]>
CC: [email protected]
Subject: Re: [PHP] advice on sql injection/XSS prevention
Date: Thu, 05 Apr 2007 16:23:23 +0200
I think it is generally a Bad Idea to allow users to submit code into
your system...
you would be better off if you would provide some pseudo-coding
possibilities which would allow them to insert certain functionalities
into their content - with you providing the real code running behind and
replacing the pseudo-codes with the process results
greets
Zoltán Németh
2007. 04. 5, csütörtök keltezéssel 09.17-kor Bing Du ezt Ãrta:
> Hi,
>
> I'm not an experienced PHP developer. We're hosting a content
management
> system that allow authorized people to add PHP contents. Their PHP
coding
> levels varies. Some are very security sensitive, but some are not. I
> want to know if PHP has any ready-to-use funtion to validate form input
to
> help prevent SQL injection/XSS? So each programmer doesn't have to
write
> their own form validation code. I'd appreciate any advice or pointers.
>
> Thanks in advance,
>
> Bing
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
_________________________________________________________________
Message offline contacts without any fire risk!
http://www.communicationevolved.com/en-za/
--- End Message ---
