What does this code do? And why is it needed?

[♥Tsimi]

osC uses this following piece of code inside the index.php

if ( (!isset($HTTP_GET_VARS['sort'])) || (!preg_match('/^[1-8][ad]$/', $HTTP_GET_VARS['sort'])) || (substr($HTTP_GET_VARS['sort'], 0, 1) > sizeof($column_list)) ) {

what is this following regex (regular expression) code for? What does it do exactly?

 

(!preg_match('/^[1-8][ad]$/', $HTTP_GET_VARS['sort']))

 

 

[Bob Terveuren]

Hi

 

It blocks out the sort by - if you get a category listing up and click the sort by headings it'll submit the page with a $_GET['sort'] set to something like 2a or 2d (a and d for ascending/descending - the numeric value is generated in the code - 2a is product name ascending)

 

the code (!preg_match('/^[1-8][ad]$/', $HTTP_GET_VARS['sort'])) says 'if $_GET['sort'] is not 1-8/a or d by:

 

'/^[1-8][ad]$/' the ^ tells it to start at the beginning of the value and the the two sets of square brackets tell it to look for:

 

[1-8] - a single value in the range 1 to 8

[ad]  - a single value either a or d

[oscMarket]

@@Tsimi, that is already explained..... you ask the question wrong.

 

Tsimi wants to know WHY it is doing these checks, as it works good enough without it.

 

Is there a special reason why it is done like it is done?

Was/is there any security issues if not use it (sql injections?).

[♥Tsimi]

Thanks Bob. But i meant more like Whitehat just said.

Thanks for correcting the question Henry.

[Bob Terveuren]

Hi

 

Arrr - just seen the other thread.... on this one - it's a filter to restrict the value of $_GET['sort'] to the range 1a->8d.

 

There's no actual database sanitsiing performed by it as the value of $_GET['sort'] is evaluated and then transposed into the listing_sql query indirectly - so if it were missing and you tried inputting something like ?sort=truncate%20table%20orders then that would have no effect on the store.

 

However it does filter the input so that you cannot cause trouble by manipulating any of the functions that use $_GET - e.g.

 

?sort=&action=buy_now&products_id=1726

 

That would add a product to the cart (not sure if that's a useful hack or not!)  - but it shows that without the code you could get a string onto your server that should not be there (especially as the value of $GET['sort'] is echoed out further down the page in the filterlist_sql)

[♥Tsimi]

@@Bob Terveuren

 

Thanks for the explanation Bob. :thumbsup:

[MrPhil]

!preg_match('/^[1-8][ad]$/', $HTTP_GET_VARS['sort']

is going to be true if the 'sort' is not of the format cx, where c is the column number 1-8 and x is the direction a(scending) or d(escending). This is sanitizing the input by checking if only the permitted data is present. The other checks are if there is no 'sort' at all or if the column number is out of bounds (too large). I presume the code then goes on to output an error message or otherwise refuse to do the sort, or perhaps falling back to a default sort.

[♥Tsimi]

Thanks @@MrPhil!

 

 

The other checks are if there is no 'sort' at all or if the column number is out of bounds (too large). I presume the code then goes on to output an error message or otherwise refuse to do the sort, or perhaps falling back to a default sort.

 

Yes, that seems to be the case.

 

       (isset)            (preg_match)         (xxx > xxx)

If *condition 1* OR *condition 2* OR *condition 3* {

 

DO THIS

 

} else {

 

DEFAULT

 

}

 

Wonder why they didn't use AND (&&) instead of OR (||) because if only one of the 3 conditions needs to be met then no need for the others right?

The first condition isset is the most important maybe? But on the other hand I have no clue so...forgive me if I am just talking non-sense here.

[MrPhil]

The "DO THIS" clause presumably is the error condition, so any of the listed conditions (no sort, invalid sort, out of range column) should trip the error handling code. Otherwise ("DEFAULT") do the normal sorting.