Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re: Re: Re: Re: Re: "Correct" program style questions

by sauoq (Abbot)
on Oct 24, 2002 at 01:09 UTC ( #207593=note: print w/ replies, xml ) Need Help??


in reply to Re: Re: Re: Re: "Correct" program style questions
in thread "Correct" program style questions

I'm beginning to hate the sight of that phrase 'cargo-cultish'.

I'm sick of the term myself. I believe, however, that this was the first time I've ever actually used it. I used it with its proper meaning in mind too, although it may not have fit as well as I thought it did. I honestly thought the or-empty construct was being included more by habit than for any real purpose. Of course, it does avoid a possible warning and I suppose that's reason enough for it. Maybe. It still bugs me.

I'm of the opinion that you shouldn't process parameters unless you expect them to be there. If you expect them but they aren't there, then the warnings are a good thing. If, however, you really don't want the warnings then simply turn them off.

-sauoq
"My two cents aren't worth a dime.";


Comment on Re: Re: Re: Re: Re: "Correct" program style questions
Re: Re: Re: Re: Re: Re: "Correct" program style questions
by BrowserUk (Pope) on Oct 24, 2002 at 01:21 UTC

    One reason for processing parameters that "aren't there" is to check that someone isn't modifying a URI in an attempt to break the code?

    This seems like an appropriate way to do that and bottle out early to an error page, before going on to validate correctly passed parameters. That way you get a single log entry for each mal-formed query string, noting all the information you need rather than (potentially) several dozen essentially similar warnings, one for each missing parameter.



    Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring!
      One reason for processing parameters that "aren't there" is to check that someone isn't modifying a URI in an attempt to break the code?

      Yes. At least, that's one way you might legitimately find yourself checking for parameters that aren't there. In that case, however, you are still checking for parameters that you expect to be there. I think there are three good options in that exceptional case:

      1. If you are paranoid about it, then include code that explicitly checks whether the value returned by param() is defined.
      2. If you aren't paranoid about it, then don't write any specific handling for it and let perl spew out some warnings.
      3. If you don't care at all, turn off warnings.

      I don't think it is a good practice to write code that simply circumvents warnings which only arise under exceptional conditions. The use of the or-empty construct that started this discussion was just that.

      -sauoq
      "My two cents aren't worth a dime.";
      

        I hope I'll be forgiven for having one last try... :^)

        1. If you are paranoid about it, then include code that explicitly checks whether the value returned by param() is defined.
          1. I don't consider it paranoid to validate user input. This is no different that the whole purpose of taint checking.
          2. This goes back to what I said a couple of iterations back. Using the || operator (which is undeprecated as far as I know ) serves the purpose of simplifying and clarifying the code, and removing the need to used defined twice (or more) on each parameter.
          3. What's wrong with cleaner, simpler code?
        2. If you aren't paranoid about it, then don't write any specific handling for it and let perl spew out some warnings.

          Sounds like a possible DoS attack in the making.

          Whilst I've never heard of it being done in this particular way--and my attempts at seeing what would happen on my local Apache server where foiled by simply not being able to generate enough queries fast enough as the user agent and the webserver were always competing for cpu and were therefore self limiting--but it wouldn't be the first time that causing logs to fill/overflow or simply sapping the horsepower of the server by causing it to generate gobs of useless warnings has been used to bend or break a server.

        3. If you don't care at all, turn off warnings.

          That is probably what I would do, locally, for the duration of the untaining of the parameters and validation that I had them all.



        Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring!
Re: Re: Re: Re: Re: Re: "Correct" program style questions
by Ovid (Cardinal) on Oct 24, 2002 at 14:27 UTC

    I'd like to plead 'no contest', your honor.

    I build some fairly decent sized Web sites (well, the code for them, anyway) and for one of them, because of the way the pages are constructed, sometimes I have a parameter or two that simply doesn't appear, due to the user's permissions. As a result, I have similar pages, generated by the same templates, handled by the same Perl code, but some parameters simply will not be there. That's why I started using constructs such as I listed. However, I realize that mine is an exceptional case and shouldn't be used by most.

    Because the site is rather large, pouring over all of the code just to find those few parameters that I am surpressing warnings for seems like overkill (and I doubt I could get the client to pay for it :)

    Cheers,
    Ovid

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://207593]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (9)
As of 2014-08-23 00:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (168 votes), past polls