in reply to Re: Re: the search string and me
in thread the search string and me

dosen't handle urls that use ; as the parameter separator, and it dosen't properly handle multiple values for one parameter name

Neither of those things is needful, generally, and since this is his own function, which he is using in his own scripts, he has complete control over whether the scripts use those esoteric features.

It also presents a huge backdoor

Yes, absolutely. Rather than assigning directly to global variables, he should be storing the input in a hash.

Furthermore, any query with the string *amp* in it

Indeed. See my obfuscated version above, which handles this correctly. (Its larger, unobfuscated prototype, the function I normally use, also handles some things that I stripped out for brevity, such as file uploads, but those things are not needed for most CGI scripts.)

There is a reason why people use CGI.pm or its lighter cousin, CGI::Lite

Yes, but as came up in a recent unrelated thread, there are also good reasons, especially for scripts that may be deployed in various locations under various circumstances, to avoid using any non-core modules (or, in fact, anything that hasn't been in core at least since 5.003). Also there are good reasons for generating all the HTML yourself, as it allows you to guarantee certain things about its structure. It is of course certainly possible to use a module for fetching the input and still generate the output yourself, however.


$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/

Replies are listed 'Best First'.
Re: Re: the search string and me
by wolis (Scribe) on Sep 15, 2003 at 04:01 UTC
    can you give me a link to your "See my obfuscated version above.." you mentioned in relation to parsing & and the use of "*amp*"

    Thanks for the comments,

    ___ /\__\ "What is the world coming to?" \/__/ www.wolispace.com
      can you give me a link to your "See my obfuscated version above.."

      Yes, here.

      That's been deliberatly obfuscated, but in a nutshell I just take the raw input from the CGI query, split on ampersands, do a foreach loop over the result, split on equal signs, feed the resulting list through a map that unmangles the rest of the characters (including any encoded ampersands and equal signs, incidentally), and the result will be a key/value pair that can be stored in the input hash. Splitting first, *then* unmangling the result, has the benefit of removing from consideration any complications that might otherwise result from getting mixed up about what is and what is not a demangled ampersand or equal sign. It's also simple and straightforward (when it hasn't been deliberately obfuscated). This only handles key/value pairs delimited by ampersands, with the equal sign separating the key from the value, but all GET queries and most normal POST input will come to you that way, even if you use a big fat textarea. (I believe my non-obfuscated version also handles the case of an equal sign in the value (though of course there can't be one in the key unless it's encoded) by using the extra optional arg to split; I golfed that out of the obfuscated version.

      The only circumstances I've encountered thus far where you get something different (apart from cookies, which come in their own environment variable) is with file uploads; in that case you have to parse a custom boundary marker and deal with multiple parts and other stuff, and it does get rather more complex; if you need to do that, I suggest getting a module that does it for you, unless your purpose in rolling your own is to learn how it works.

      I rolled my own to figure out how it works, but I only ever used it to test that I had it working; since then, I've only used the regular kind of input, not having a need for file uploads. If I need to get files to the server, I ssh in and wget them from the Apache on my workstation, which has the added benefit of being resumable if my dialup connection dies partway through. If at some point in the future I discover a need to parse file uploads and store the file, I'll probably look for a module that does that; my own routine for that is too complex for me to be sure it doesn't have lurking bugs. However, for regular CGI input, I am fairly confident in my implementation; it's very simple, very straightforward. In the form I normally use it, it's a sub in an include file that I require, and it returns a reference to a hash containing all the input, (with all of the keys and values marked as tainted, in case I should forget myself and try to do anything insecure with them). The calling script usually dereferences and assigns the result to a global hash called %input


      $;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
        Thanks for that.

        The bit Im unclear about is if a form is submited with

        <input tupe="text" name="foo" value="bing&bong=bang">
        Are ALL instances of & and = in a form post (or get) converted into their 'mapped' character on the way through to the perl code?

        For some reason I didn't think this was the case <shrug>

        I have rolled my own file uploader too.. again just to understand how it all works.

        ___ /\__\ "What is the world coming to?" \/__/ www.wolispace.com