Re: [PHP] Re: posting variables to parent frame
Tijnema ! wrote: I guess the same can be done with div... But the main problem is that there's no real standard for resolution. I see people having resolution set at 800x600, and 1600x200, how is it ever possible to make a page look good at both? Resizing it to 1600x1200 would give you an enormous page, while keeping it at 800 width makes it so damn small. So lets say you re size it to 1024 width, then you still have such damn borders on both sides. That doesn't look nice either. And how would you do deal with pages that have a layout based on pictures? Should you create a header that is 1600 width, and resize it down until 800 when a user with 800x600 visits? and all images used at borders and corners? That's the biggest problem in dynamic layouts. Atm, i repeat small images around the borders, but that's a real pain in the ass. For now, i mostly design static pages, that are best viewable with 1024x768, and resolutions higher then that have those damn borders... If sombody has a better way, i'd like to hear :) Tijnema I posted something in response to Ed by the damn list filters blocked it as O.T. Anyhow, essentially I said my layout conventions will expand as much as necessary as the user expands their window size. Once there is no more text being wrapped, no further expansion is possible. (And it wouldn't make sense to do so anyhow, even if it were possible.) At that point, it just centers the *block* of page content, while still keeping the actual text left-justified within that block. I think that's a hell of a lot better than site designs fixed for a width of 800px or 1024px or whatever, because if more space becomes available (like say 1600px), they still wrap the text within a tiny tunnel-vision 800px (or whatever) fixed-width block. That's unnecessary and gross. An intuitive site designer should be able to identify what parts of their layout _can_ expand without looking stupid, and what parts have to stay at a specific size. Then design it accordingly so those sections that can expand, will expand (given the opportunity to do so... ie. being viewed in a large window.) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: posting variables to parent frame
Tijnema ! wrote: [snip] Should you create a header that is 1600 width, and resize it down until 800 when a user with 800x600 visits? and all images used at borders and corners? That's the biggest problem in dynamic layouts. Atm, i repeat small images around the borders, but that's a real pain in the ass. For now, i mostly design static pages, that are best viewable with 1024x768, and resolutions higher then that have those damn borders... If sombody has a better way, i'd like to hear :) Oh yeah, forgot to mention. I usually headers and footers outside of my centered expandable block, so they stretch the whole width of the screen even if the centered block doesn't. Again, using the hated tables for layout approach, I create a table with width=100%, and as many columns as I need for the header or footer content. Then I use a tiled background image in the table for making the prettyness stretching across the width page. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Server side speech
tedd wrote: However, I did run my audio captcha by a couple dozen _visually impaired_ testers... ..snip... ...it's interesting to see what _they see_. nothing? ;-) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP Text Messaging
Richard Lynch wrote: [snip] Relying on Sprint, however, to honor any kind of oral agreement, is a big fat *NOT* I'm sorry, but we just don't have any reocrd of that conversation. You're now 2 weeks overdue, because that extension you claim we gave you doesn't exist. It was like a parody of the White House Watergate tapes -- Anything they didn't feel like honoring was just not there; Something that had been said that they LIKED, they had a perfect record of that though. [snip] A good old O.T. thread. :-) A few months back I was trying to weed some information out of Rogers and Fido, but several times I was told conflicting information each time I called. Finally I made an audio patch cable to connect my MP3 player/recorder to the phone and then proceeded to call Rogers again. The conversation went something like this: -Voice mail system: Thank you for calling Rogers Wireless. Please stay on the line and our next available agent will help you. Note that your call may be monitored and recorded for quality assurance and training purposes... music-on-hold... -Customer support: Thank you for calling Rogers, my name is Bob, may I have your phone number starting with the area code? -Me: I'm just letting you know that this call will be monitored and recorded for quality assurance purposes *click* MP3 recorder starts recording -Customer support: Umm okay The patch cable was designed so I could also play back audio into the phone, just in case they tried pulling a we never said that denial. Fortunately, in that conversation where I announced it was being recorded, the customer service guy never lied to me even once. Funny how that works out. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: posting variables to parent frame
tedd wrote: At 5:06 PM +0200 4/26/07, Tijnema ! wrote: It's not XHTML 1.0 Strict valid .. :P You're page is HTML 4.01 valid, i think you should make it XHTML 1.0 Strict. Ar. Then I would have to add all those / to my in all my code in all my sites. Literally millions of new / would have to be added. That act could possibly crash the net. So, until someone points out a good reason for me to change (I'm open for redirection), I'll continue to use what works for me. Besides, it's still compliant, isn't it? Call me crazy, but I use HTML 4.01 Transitional. It's messy as ever, but it works. And I've never had a browser bark over my br or br/ or br / I'll also admit I don't have enough CSS knowledge yet to make page layouts with completely dynamic positioning that actually look good, regardless of the browser window size and aspect ratio. You know, tables do a fantastic job of controlling layout. :-) (I'm expecting several hate-mail replies now.) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: posting variables to parent frame
Edward Vermillion wrote: So you're saying that if I maximize my browser window, all the sites that you made with tables will actually look good, at 1680 x 1050, because they are stretchy-pages? Honestly, I have no clue as to why some folks think that a stretchy/ liquid/dynamic layout has anything to do with good design... I have yet to see one that did anyway*... :P On the other hand, if I increase my font size (which I almost always do) I expect the layout to grow so that I can actually read what's on the page, without the words all running together. But that's a different thing than being stretchy. Ed [*] I'm often wrong, but I'm open to different viewpoints if you've got an example to prove me wrong. ;) Ok, this is attempt #2 since the list rejected the previous attempt. Well one of my biggest pet peeves with absolute-positioned-element pages is if I maximize my window, I still just have a tiny little blob in the centre which has the actual page content, with lines of text still needlessly wrapping around their artificial constraints. Then I see trash like this site looks best in 1024x768 or something similar. What ever happened to device-independent design? What's next, a trip down memory lane to 1998 when sites had looks best with Internet Explorer and looks best with Netscape plastered all over them!? I scoffed at anyone who back in the day used to say most people view web sites at 800x600, so design for that. No. I say design something that's still readable at 640x480, and make it liquid so it will expand to whatever's available up to the point where it no longer needs expansion. At that point, just make sure it's centered. So what I usually do is I put my page content in a rectangular boundary. (sometimes I'll put page headers and footers outside this bounding box, but the main content stays inside.) I then left-justify all the inner content to the box. (English reads left-to-right, so left-justified paragraphs look 10 000 times better centered text.) But if someone expands their window to a huge size, it looks dorky to have _everything_ stuck to the left of the window! So the *bounding box* is what's centered in the window. Everything inside the bounding box is then set with percentage-based widths where stretchyness is ok (eg. for blocks of text), or pixel values where it should never change (eg. for images placed on the page). For the percentage-based widths, this is a percentage of the bounding box size. The actual size of the bounding box is nice and liquid, stretching as wide as necessary until there are no more lines of text that need to be wrapped. I think that results in the best page layout, all the way from tiny PDA screens at 160x240 to your 1680x1050 behemoth! :-) If there's an elegant way of doing this with CSS, let me know. But I've found this usually works well for a simple site layout that has headers and footers as wide as the window, and a menu down the left made with 120px wide graphics. ?php echo Here's some PHP code so this list doesn't consider my post O.T.; ? body !-- Headers go here -- centertable cellpadding=0 cellspacing=0 border=0tr valign=top align=lefttd!-- bounding box start -- table tr td width=120 !-- Menu column made with 120px wide graphics goes here -- /td td width=* !-- Liquid / stretchy text and other page content goes here -- /td /tr /table /td/tr/table/center!-- bounding box end -- !-- Footers go here -- /body The coments commented as Liquid / stretchy text... can then have divs completely dynamic tables and whatever, which are all scaled to whatever size that particular table cell (with width=*) happens to end up being rendered at. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
Dotan Cohen wrote: On 25/04/07, Justin Frim [EMAIL PROTECTED] wrote: I'm assuming then you want the data to be able to contain _some_ mark-up considered to be safe? Not at this stage, no. Maybe if the users ask for it, but not now in the beginning. The universe's best engineer, Scotty, once advised us tell them that it's impossible, and only then to implement what they want. You should decide now before going any further, do you want the future capability to add mark-up codes? And if so, are they going to be similar to HTML using the and characters, or are they going to be like BBcode using the [ and ] characters? This decision will determine if filters to gaurd against XSS attacks really are the best solution or not. See, you should only use filters to prevent XSS attacks if you plan on using the and characters for mark-up codes (now or in the future). Otherwise, use htmlspecialchars() or htmlentities(). If you use a filter that strips and characters, you'll have a lot of angry / frustrated / confused users when they find they can't type and as literals if they're not aware that and are reserved for special mark-up codes. Consider: Suppose a bunch of mathematicians are having a discussion on the message board, and one of them decides to state that variable x is greater than 3. They might type x 3, but your filter will end up garbling it up. Not good! If you use htmlspecialchars(), then anything they type will appear as typed. If you want future capability for mark-up, you should inform the users which characters are reserved, and how they can represent them as literals. Basically, you're informing the users if they should speak HTML, speak BBcode, or speak the natural language when they post on the site. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] List
Have you considered using something other than Outlook? Beauford wrote: Does anyone else have this problem with the list. It seems that every time I check my email there is one or more messages from the list that royally screws up Outlook. I usually have to delete all list messages from the actual server and reboot. It only happens with emails from [EMAIL PROTECTED] Just trying to narrow down the problem. Not sure if this is spam that's sneaking into the list messing things up or what. Thanks -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
Dotan Cohen wrote: I currently an using htmlencode, so and show as expected. I do expect the math faculty to use those symbols :). Then you're already protected from XSS attacks, no HTML filters necessary. Easy as pi. ;-) (ok, that one was lame) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Server side speech
Richard Lynch wrote: If you can compile (or find it compiled) on the exact same OS, you can probably upload the binary and then use 'exec' on your own program. I've had some success doing this on a shared host. You might also be able to convince the webhost to just install Festival for you. It would take them about 5 minutes, at most... They might be leery, of course, if they think it will be too resource-intensive. Perhaps lightly off-topic, I had to make a quick audio CAPTCHA to complement a visual one for a web site. I was thinking of having a server-side TTS system, but that just became too big a can of worms for the size of the project. I also had the restriction that the hosting service provider refused to install any machine-code executables or compile any programs to be installed on their servers. So instead I used a collection of 95 sound clips, each one being a recording of an ASCII character spoken out loud, with the file named as the 2-digit hex code of the respective character. All the PHP script had to do was concatenate the audio data portion of the necessary files, then create a new header and send the result as a single audio file to the user-agent. Worked like a charm. (I should also mention the audio clips were in IMA-ADPCM format, so a simple concatenation like that didn't break anything.) Let me put it this way: There is unlikely to be anything with a better chance of suceeding in this endeavor than Festival. :-) If you build a really cool way for people to make their sites provide text-to-speech capabilities that everybody wants, and all that's needed is for webhosts to install your software and Festival, then they're gonna install Festival, because their users will demand it. In the short term, there almost-for-sure isn't any easy way to upload some magic widget that will work cross-platform and do text-to-speech. So you're going to have to create demand for your project, by making it super cool. Well, there _is_ the alternative of writing an entire TTS engine in PHP... should you have the knowledge, inclination, processing speed, and crazyness to attempt such a task. ;-) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] retrieve POST body?
Myron Turner wrote: I'm not sure I follow here, because the Perl script would be saving the posted file to disk. It would then send back a redirect with the name of the file in the query string of the url, which would point to a php script that would then read the file from the disk. So the file shouldn't be sent more than once. In any event, I do think that at least a few of use are agreed that somehow the whole post should be made available in PHP. Good luck with your solution, Myron Yes, you're right. :-) Somehow I thought the whole request just goes twice. I think I've been staring at a computer too long today. My head hurts. *L* -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: posting variables to parent frame
I'll jump in on this one, because I've dealt with the div/object/iframe frustration before. And I would not be very happy if the W3C decided to deprecate iFrames right now, at least with the current state of the world's browsers. I found that with object I didn't have very much control over the border frame (some browsers just refused to make it go away!), others had problems with sizing, positioning, and margin control. Some browsers even flat out refused to load the object data, but worked just fine with iFrame. From my own testing experience, my iFrames worked on IE 3, 4, 5, 6, and 7, all Mozilla-based browsers (Firefox, SeaMonkey, etc.) right from the start of the Mozilla foundation up to the latest version of Sea Monkey, and Opera versions 6 and 9. As for div, isn't that just for defining blocks of content in the current document? That's a whole different thing than object and iframe, which are used for embedding an entirely new document into the current one. You're comparing apples to oranges here. Al wrote: Provide an example of an iFrame that will work on all modern browsers and that can't be done with DIVs or OBJECTS Stut wrote: Al wrote: iFrames are obsolete and only IE handles them. I don't even know if IE7 does. Well that's just a complete load of rubbish. The iframe tag is not obsolete, and I don't know where you got the idea that they are. Several legitimate uses for iframes exist, and they're unlikely to go away any time soon. Use css div tags instead. They don't do the same thing, not by a long shot. -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
Just my two cents worth...
Magic quotes are the work of the devil. It's a shame that so many PHP
installations have them enabled, and a huge disappointment that PHP is
actually distributed with this stuff enabled! The mere fact that a
script can't change this setting creates a real hassle and is my major
gripe about the whole situation. I've *always* followed the programming
practice of work with your data unencoded, then encode it appropriately
only at the last final output stage. That way you always know exactly
what you're working with, no surprises, where each character is always 1
byte, regardless of what character it is. Here's a typical block of
code which I include in the start of nearly all my PHP scripts:
?php
//Do not delete this function! (unless you don't mind data corruption
with PHP's default settings)
function stripslashes_deep($value) {
return is_array($value) ? array_map('stripslashes_deep', $value) :
stripslashes($value);
}
//Get rid of those stupid damn annoying asanine magic quotes which just
garble up your data.
if (get_magic_quotes_gpc()) {
/*
(unfortunately in PHP these are enabled by default. AHH! Which idiot
thought this was a good idea to turn them on by default? Good programming
practise is to manually encode only the data that requires encoding just
just before dumping it to places which need it (ie. databases), not
automatically screwing up the entire collection of the system's variables!
AHH!)
*/
$GLOBALS['HTTP_POST_VARS'] =
stripslashes_deep($GLOBALS['HTTP_POST_VARS']);
$GLOBALS['_POST'] = stripslashes_deep($GLOBALS['_POST']);
$GLOBALS['HTTP_GET_VARS'] = stripslashes_deep($GLOBALS['HTTP_GET_VARS']);
$GLOBALS['_GET'] = stripslashes_deep($GLOBALS['_GET']);
$GLOBALS['HTTP_COOKIE_VARS'] =
stripslashes_deep($GLOBALS['HTTP_COOKIE_VARS']);
$GLOBALS['_COOKIE'] = stripslashes_deep($GLOBALS['_COOKIE']);
$GLOBALS['HTTP_SERVER_VARS'] =
stripslashes_deep($GLOBALS['HTTP_SERVER_VARS']);
$GLOBALS['_SERVER'] = stripslashes_deep($GLOBALS['_SERVER']);
$GLOBALS['HTTP_ENV_VARS'] = stripslashes_deep($GLOBALS['HTTP_ENV_VARS']);
$GLOBALS['_ENV'] = stripslashes_deep($GLOBALS['_ENV']);
$GLOBALS['HTTP_POST_FILES'] =
stripslashes_deep($GLOBALS['HTTP_POST_FILES']);
$GLOBALS['_FILES'] = stripslashes_deep($GLOBALS['_FILES']);
$GLOBALS['_REQUEST'] = stripslashes_deep($GLOBALS['_REQUEST']);
}
set_magic_quotes_runtime (0); //Fortunately these can be killed with a
single statement, unlike magic_quotes_gpc
?
Eh, don't mind the comments. Sometimes PHP programming can become quite
frustrating. ;-)
On to the next stage... encoding data for output to an HTML document.
Personally, I prefer using htmlspecialchars() over htmlentities(),
because it only converts those characters that *must* be converted for
HTML ( ). There's no use in turning your other 1-byte
characters into 5, 6, or 7-byte strings, if you already provided the
correct character set in the Content-Type HTTP header (as you should!).
Actually, if you want to get really picky, I usually use the following
conversions:
For most tag parameters: htmlspecialchars($tagdata)
For display text: nl2br(htmlspecialchars($displaytext))
(This keeps newline sequences in effect.)
For text which may contain a few control characters, special characters,
or other binary data (sometimes useful in hidden form fields, or for
special accented characters and non-english languages):
preg_replace('/([\\x00-\\x1F\\x7F-\\xFF])/e','#.ord(substr($1,-1)).;',htmlspecialchars($binarytext))
(This encodes the data in a mostly still human-readable form, entirely
with 7-bit ASCII characters only.)
For binary data (sometimes useful in hidden form fields):
strtr(base64_encode($binarydata),'+/=','-_.');
(All the advantages of Base64 encoding, without incurring any overhead
from URL encoding when the form is submitted.)
Anyhow, back on track to the original topic of this thread. For
anything that gets written to a database or used for a query, I suggest
escaping the data using a function specifically designed for that
database. (And there are many different functions for the many
different popular databases.) This should have *nothing* to do with
blocking XSS, turning into lt;, etc. Preparing for the database
query string is no place to do the data conversion which will be
necessary for the final output.
The last topic... blocking XSS attacks. If you use the encoding
routines I listed above for outputting to HTML documents, you're already
safe. And you're not outlawing any characters either... if someone
wants to type and , or show semi-colons or whatever, they can,
knowing with certainty that what they type is exactly what others will
see. If you need to let users enter some mark-up, do what message
boards and web log sites have been doing for years: BBcode. Then you
can write your own routines to provide only the features you need, using
a code format that's much
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
Eric Butera wrote: One thing you might want to keep in mind is that this little fix is going to get executed on each request if you just throw it in an include. ...big snip... That means lots function calls happened before you could even say hello world. You might want to add wrapper functions accessor functions around $_GET and $_POST so that you're only stripping when really necessary. You could always take out the lines from that fix which you don't need. For example, if you use the $_POST[] array, you probably don't need to fix $HTTP_POST_VARS too, and if you don't use cookies at all, there's no need to spend CPU cycles un-magic_quote_gpc'ing any of the cookie stuff. The problem with wrappers is they're always executed, even for people who don't have the magic quotes problem. What I liked about lumping it all together as a massive operation at the start is I could put my fix in a single if() block to skip it if it's not necessary. Those who have PHP installations that aren't tainted with magic_quotes_gpc can run the script with almost no performance hit at all... faster than if the script had wrappers. It also keeps the rest of the code pretty. ;-) If you're frequently accessing a superglobal through a wrapper (for example in a loop where you compare it with values in a long array or something), you're still back to executing several function calls. That's just out of the frying pan and into the fire. Of course a smart optimization would be to call the wrapper only once, declare a variable to store the result, and use this variable for comparison inside your loop. Now if we extend that mentality even further we can declare the variable as global at the start of the script and call the wrapper only once at the start too! Now we've essentially created an un-magic_quote_gpc'd copy of the superglobal. So the next logical thought is if we're never using the magic quoted value in the code, why make a *copy* of the superglobal? Why not just operate *directly* on it?. That's the train of thought that led to my little fix anyhow. :-) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Preventing SQL Injection/ Cross Site Scripting
Dotan Cohen wrote:
On 24/04/07, Justin Frim [EMAIL PROTECTED] wrote:
if (get_magic_quotes_gpc()) {
/*
(unfortunately in PHP these are enabled by default. AHH! Which idiot
thought this was a good idea to turn them on by default? Good
programming
practise is to manually encode only the data that requires encoding
just
You've got a typo in practice.
I seem to recall I was in a very, very bad mood when I wrote that
comment. *L*
While I do normally strip out all my nasty comments before making code
go public, I still keep them in some of my personal scripts for
historical humour among friends. But thanks... I'll try to keep that in
mind. :-)
I took chris's advice and filter for XSS after the info is retrieved
from the database, before sending it to the browser.
I'm assuming then you want the data to be able to contain _some_ mark-up
considered to be safe?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] retrieve POST body?
You are correct, I'm not very familiar with Perl. If I do go the route of using something else to accept the form data and then executing the PHP script, I'd be leaning more toward somehow executing the PHP script directly rather then sending back a redirect to the user-agent to re-send the request to the PHP script. Reason being that if a file is uploaded, it ends up getting sent twice. For a large file, that's a lot of extra HTTP traffic. Anyhow, after much talk and some pretty innovative suggestions, I think I'm going to... 1. Put in a feature request to have the entire POST body, unaltered, dumped to a temp file. And in the mean time... 2. Reconstruct an identical POST body from the $_POST[] array, with some trial-and-error form field renaming (in the case of server-side image maps) and placement of uploaded files. (Slow, I know, and not guaranteed to work everywhere, but it keeps the script as portable as possible.) 3. Instruct page designers to refrain from using special characters in form field names when using this script. And also suggest to page designers to try to keep the number of server-side image maps and file uploads at a minimum, for speed and performance reasons.) 4. Provide the capability for the PHP script to execute a user-defined include file and read a user-defined file for the POST body. This would allow future improved operation in case the feature request ever materializes, or a sysadmin uses an external process (Perl or whatever else) to dump the POST body to a file. Myron Turner wrote: Richard Lynch wrote: On Sat, April 21, 2007 10:56 pm, Myron Turner wrote: At that point, why not just have Perl call PHP? Surely Perl can do something not unlike 'exec' or whatever to run any shell script you want... I sure wouldn't do another round trip to the browser and add JS into the middle of this solution, if it's viable... Wouldn't work for me, as I can't do Perl. Perl could, could of course do the whole job. But since the Original Poster was (I assumed) not particularly familiar with Perl, I was essentially providing a Perl script to do the base essentials. So my hack would put him right back into PHP. If he execs from Perl to a PHP script to do the processing, then he would have to augment the Perl script to send back HTML to the browser, and if he can do that he can probably stick with the Perl altogether. Anyway, that was my reasoning. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] should I be looking to eliminate all notices?
Edward Vermillion wrote:
On Apr 21, 2007, at 6:35 PM, Justin Frim wrote:
I've always gone by the rule that if you're making software that
other people will see or use, make it clean.
Sometimes I'll cheat and stick a @ symbol in front of a line to
shut up errors and warnings for that particular line, but usually I
only do that for speed optimization. (ie. if it's in a short loop
that cycles many times).
Your not saving any cycles. The error handler still gets called, the
error just doesn't get shown.
And '@' is just another way of ignoring an error in your program. Not
really a good idea if you want to right good code.
Ed
Surely that's faster than calling isset(), declaring another variable,
and executing another if() statement though, no?
Compare:
?php
function myfunction($inputdata) {
global $myarray;
echo foo;
return $myarray[$inputdata];
}
function yourfunction($inputdata) {
global $yourarray;
echo bar;
return $yourarray[subfunction($inputdata)];
}
if ((@$funcresult=myfunction($_GET['formfield']))!==false) {
//Do stuff with the data from $myarray[], after doing just a single
if() comparison
}
if ((@$funcresult=yourfunction($_GET['formfield']))!==false) {
//Do stuff with the data from $yourarray[], after doing just one
more if() comparison
}
?
vs:
?php
function myfunction($inputdata) {
global $myarray;
echo foo;
if ($inputdata!=) { return $myarray[$inputdata]; }else{ return
false; }
}
function yourfunction($inputdata) {
global $yourarray;
echo bar;
if ($inputdata!=) { return subfunction($yourarray[$inputdata]);
}else{ return subfunction(false); }
}
if (isset($_GET['formfield'])) { $funcinput = $_GET['formfield']; }else{
$funcinput = ; }
$funcresult=myfunction($funcinput);
if ($funcresult!==false) {
//Now we can finally do stuff, after calling isset(), declaring a
variable, and doing three if() comparisons
}
$funcresult=yourfunction($funcinput);
if ($funcresult!==false) {
//Finally do more stuff, after doing two more if() comparisons
}
?
Now that's a stupid example, but, you get the idea.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] retrieve POST body?
Richard Lynch wrote: On Thu, April 19, 2007 10:28 pm, Myron Turner wrote: that should be necessary at this time. For instance, if it's necessary to pass in CGI parameters at the same time as sending out a file, the parameters can be tacked onto a query string and they will be packed into both the $_POST and the $_GET arrays. I've lost track of why the OP needs an md5 or whatever it is of the raw POST data, but MAYBE using an unknown MIME type and putting all the other args in the URL as $_GET parameters, would leave them with only the file itself to be parsed which would be pretty minimal parsing... There exists a mode of HTTP digest authentication where a header contains an MD5 hash of an MD5 hash of the POST body (along with a few other things that effectively add a salt to the hash, and provide the actual username/password authentication). This is used for integrity protection, to safegaurd against any malicious proxy or man in the middle attack from altering the form data while it's in transit from the authorized user to the web server. I'm a little lost here though... how can it be possible to put data into the URI as well as the POST body? The request is originating from the user-agent, not the server. Regardless though, the real problem with this proposed hack is how, through HTML code, would one instruct the user-agent to submit the form using multipart/form-data, but without it creating a Content-Type: multipart/form-data header in the request!? This sounds like an impossible task to me. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] should I be looking to eliminate all notices?
I've always gone by the rule that if you're making software that other people will see or use, make it clean. Sometimes I'll cheat and stick a @ symbol in front of a line to shut up errors and warnings for that particular line, but usually I only do that for speed optimization. (ie. if it's in a short loop that cycles many times). In any case, I don't think it's a good idea to rely on users disabling warnings and error messages from their PHP configuration file if you want the code to be portable. Personally, I leave all errors and warnings turned on, even for public PHP deployments. Ross wrote: A quick one this morning. When coding should I be trying to code so there are no notices or is it ok to turn them off. I don't really want to do a isset check for every index I have. Ross -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] retrieve POST body?
This is starting to get super ugly indeed... I was hoping I wouldn't have to essentially write an HTTP daemon from scratch, so I'll keep the sockets in mind as a *last* resort. As much as it would simplify things if $HTTP_RAW_POST_DATA (and friends) was fixed to always contain the data regardless of the Content-Type header used, it's going to take a long time before that fix trickles down into other people's PHP installations. Not everyone runs the latest versions, and this particular script I'm working on is being designed to be widely portable. *sigh* I started experimenting today with the idea of reconstructing a POST body from the $_POST[] and $_FILES[] arrays. It's doable, but with limitations. Form field names must not be permitted to contain periods, spaces, or opening square brackets. Those all get converted to underscores before the keys are created to the $_POST[] array, with no way to determine the original name. And if the form field name has both opening and closing square brackets respectively, weird funky sub-arraying occurs. Anyhow, I'd also need to do a workaround to this form field naming limitation, because server-side form-based image maps send the coordinates as formfieldname.x and formfieldname.y, no exceptions. So I'd have to search for any array key pairs that have identical names save for a _x and _y ending, and change the underscore back to a period. Of course this could mess up other form fields that just happen to end in _x and _y as specified in the HTML form, so I'd have to try several combinations (one each found key pair at a time + one for no changes) and keep comparing the hashes until I've found the correct POST body reconstruction. Then there's the final challenge: figuring out the order in which the form-data blocks were arranged in the original multipart body! It turns out the order of the $_POST[] array elements are created in the same order as the respective form-data parts in the original POST request, but if the form contains a file upload, it throws a wrench in the operation. The trouble is the $_POST[] array does not contain any elements for the file upload, so it's anyone's guess as to where in the multipart POST body the uploaded file data was inserted. The only solution I can think of is to try all the possible combinations until the correct hash is found. But if the form has several fields and multiple file uploads, this could take quite a long time... But hey, is this any dirtier than writing an entire middle-ware HTTP server in PHP? ;-) Richard Lynch wrote: One possibly super ugly hack... You could maybe write your own middle-ware HTTP server thingie with some kinda socket functions, do what you want with the input, and then pass it on to PHP somehow... I think you might maybe be better off putting in a Feature Request to get RAW_HTTP_POST_HEADERS or whatever it is turned on for multipart/form-data, or even declaring it a Bug. It might just get labeled bogus as a bug though... You may even have some luck looking at PHP source to try to submit a patch for it... Doesn't seem like it would be THAT hard to do, once you find the dang lines of C code that do file upload, and the other lines that do the RAW_HTTP thing... 'Course, it would take me months just to find those lines of code, knowing me. :-v -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] retrieve POST body?
Sorry burst your bubble, but your solution isn't a viable one in my case.
php://input only works if the form is submitted using
application/x-www-form-urlencoded.
Take your sample HTML code there and add enctype=multipart/form-data
to the form tag, and I'm pretty sure you'll find that php://input
contains no data. (Both PHP 5.2.1 running as a CGI on Windows and PHP
5.2.0 running as an Apache module on FreeBSD exhibit this behaviour.)
And before anyone asks, it *is* a requirement to accept
multipart/form-data submissions because that's the only way you can
properly implement a file upload on a web form.
Myron Turner wrote:
Tijnema ! wrote:
On 4/19/07, Myron Turner [EMAIL PROTECTED] wrote:
André Medeiros wrote:
php://stdin perhaps?
On 4/18/07, Justin Frim [EMAIL PROTECTED] wrote:
André Medeiros wrote:
Reading from php://input on a webserver will retrieve the Body
of the
HTTP Request.
Not for me it doesn't.
That only seems to work when the form is submitted as
application/x-www-form-urlencoded. When the form is submitted as
multipart/form-data, php://input is blank.
You probably could use this small Perl script via exec:
#!/usr/bin/perl
if ($ENV{'REQUEST_METHOD'} eq POST) {
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
}
print $buffer;
If you call this script via exec, it can't return the POST data send
to the PHP script right?
You're right. It doesn't carry across from Perl to PHP. As penance,
I worked out how to do it using PHP:
form action = post_data.php method=post
input type= hidden value = abcdefg name=post_test
input type = submit name=submit value=submit_this
/form
?php
if(isset($_POST['submit'])) {
$putdata = fopen(php://input, r);
/* Read the data and write it to stdout */
while ($data = fread($putdata, 1024))
echo $data, \n;
/* Close the streams */
fclose($fp);
fclose($putdata);
}
?
btw, we are here on a PHP list, not PERL :)
Does this mean you wouldn't use exec or system to run anything but PHP
scripts? Or just that you wouldn't talk about it here, under penalty
of exclusion from PHP heaven? :)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] retrieve POST body?
Interesting... But how will the user-agent know how to pack the data? AFAIK, if you don't specify enctype in the form tag, the user-agent will assume application/x-www-form-urlencoded. I'm assuming that if you put in something that's not recognized (like multipart/x-non-parsed-form-data), the user-agent won't know what it is and will again default to application/x-www-form-urlencoded. So to use the dirty hack suggested by Rasmus in that IRC log, I'd need some way of instructing the user-agent to use multipart/form-data, but then destroy the Content-Type header in the request *before* PHP sees it and snags the body. Gregory Beaver wrote: Good news and bad news. Rasmus reports on IRC: [21:57] Rasmus_ We never buffer the data in file upload mode [21:57] Rasmus_ it is streamed to disk, so no, you can't get it all in a variable like that [21:57] Rasmus_ set a different content-type if you want to do that [21:57] Rasmus_ assuming you have control over the client [21:58] CelloG can you do a file upload without multipart? [21:59] Rasmus_ Well, if you want to pick a POST apart yourself, sure [21:59] Rasmus_ set a mime type PHP doesn't understand and it will be in http_raw_post_data and then you can do whatever you want with it So the answer is sort of. You would have to parse the POST data yourself, but it is technically a possibility. Regards, Greg -- Experience the revolution, buy the PEAR Installer Manifesto http://www.packtpub.com/book/PEAR-installer -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] retrieve POST body?
Regarding some discussion a while back about putting in a feature request for obtaining the POST body... I can see the advantage of streaming the POST body directly to disk, because then you don't have to allocate a huge amount of memory for keeping a copy of the POST body in a variable. So maybe (and this is wishful thinking), a feature could be added to PHP where the entire POST body, unaltered, is streamed to a file in the same fasion as those individual temporary files referenced in the $_FILES[] array. Then for HTTP digest authenticated requests with integrity protection, I could just call md5_file() on this special file, and my world would be a whole lot simpler! (And any other script programmers, should they need to access the POST body for whatever reason, can just read the file and parse it however necessary. No gigantic memory overhead involved.) Just a thought. Gregory Beaver wrote: Good news and bad news. Rasmus reports on IRC: [21:57] Rasmus_ We never buffer the data in file upload mode [21:57] Rasmus_ it is streamed to disk, so no, you can't get it all in a variable like that [21:57] Rasmus_ set a different content-type if you want to do that [21:57] Rasmus_ assuming you have control over the client [21:58] CelloG can you do a file upload without multipart? [21:59] Rasmus_ Well, if you want to pick a POST apart yourself, sure [21:59] Rasmus_ set a mime type PHP doesn't understand and it will be in http_raw_post_data and then you can do whatever you want with it So the answer is sort of. You would have to parse the POST data yourself, but it is technically a possibility. Regards, Greg -- Experience the revolution, buy the PEAR Installer Manifesto http://www.packtpub.com/book/PEAR-installer -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] retrieve POST body?
Greetings, Is there any way to retrieve the POST message body when a form is submitted to a PHP script using multipart/form-data? I can't use just the $_POST[] and $_FILES[] arrays because I need to calculate the hash of an exact bit-accurate copy of the original POST body for data verification. (HTTP digest authentication with qop=auth-int.) Submitting the form using application/x-www-form-urlencoded is not an option either because the PHP script has to be able to handle forms with file uploads. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] retrieve POST body?
Chris Shiflett wrote: Justin Frim wrote: Is there any way to retrieve the POST message body when a form is submitted to a PHP script using multipart/form-data? There's the always_populate_raw_post_data configuration directive and the $HTTP_RAW_POST_DATA. Have you tried that? Yes, that is already configured. It appears that $HTTP_RAW_POST_DATA only works for application/x-www-form-urlencoded, but not multipart/form-data. Same thing with $GLOBALS['HTTP_RAW_POST_DATA'] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] retrieve POST body?
André Medeiros wrote: Reading from php://input on a webserver will retrieve the Body of the HTTP Request. Not for me it doesn't. That only seems to work when the form is submitted as application/x-www-form-urlencoded. When the form is submitted as multipart/form-data, php://input is blank. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] retrieve POST body?
I tried that one too. For any POST requests (regardless of Content-Type), it's always blank. For GET requests, it contains the PHP script source code. André Medeiros wrote: php://stdin perhaps? On 4/18/07, Justin Frim [EMAIL PROTECTED] wrote: André Medeiros wrote: Reading from php://input on a webserver will retrieve the Body of the HTTP Request. Not for me it doesn't. That only seems to work when the form is submitted as application/x-www-form-urlencoded. When the form is submitted as multipart/form-data, php://input is blank. -- 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
