using 'DO' in a query string for function calls

all,

I'm trying to figure out something on another forum I am part in, simply for learning experience. Although, this post will probably look suspicious too.

as with the same as this forum's search page, I was able to gather from the browser source that the following items were the form fields:

query[]=STRING
searchuser[]=STRING
exactname[]=BOOLEAN
starteronly[]=BOOLEAN
tag[]=STRING
forumchoice[]=
prefixchoice[]=
childforums[]=BOOLEAN
titleonly[]=BOOLEAN
showposts[]=BOOLEAN
searchdate[]=DROPDOWN LIST
beforeafter[]=DROPDOWN LIST
sortby[]=DROPDOWN LIST
sortorder[]=DROPDOWN LIST
replyless[]=BOOLEAN
replylimit[]=NUMBER
searchthreadid[]=
saveprefs[]=DROPDOWN LIST
quicksearch[]=
searchtype[]=
exclude[]=
nocache[]=
ajax[]=
userid[]=0

I think this is pretty useful, because it shows the strings and/or field names that are being used in the POST to generate the search id criteria in the subsequent query string for the database search. My question is, on this other forum I can type in a query string like this:
.com/search.php?query=ms%20%access&ajax=&exactname=0and the search page appears with "ms access" in the keywords textbox and the "exactname" checkbox unchecked.

BUT...when the form is actually submitted, I get redirected to this page:
.com/search.php?searchid=6009484and the results are displayed....AND the action behind the form submission is simply:search.php?do=process

First, I am confused about why, if I enter the search.php page's field values directly into a URL query string, I still get the search page. E.G. - if I enter:search.php?query=ms%20%accesswhy do I get the search page with the query box filled in? Does this simply indicate that the POST is redirecting to SELF? Similarly to the way:$SERVER_['PHP_SELF']works?

Secondly, I'm confused on how the 'process' action works. Someone here told me a while back that 'do' was a field in the db table, which makes sense. But what about the 'process' part? Is there some PHP function code in another field that is read or executed based on the 'do' input value?

I would expect someone to respond to my post here, as I'm simply wanting to learn a little bit about this different method of doing things with PHP, but if the answers I would get would expose the security measures used by vBulletin, then I guess I don't expect any responses.

I appreciate any understanding I can get though. thanks!

First, I am confused about why, if I enter the search.php page's field values directly into a URL query string, I still get the search page. E.G. - if I enter:search.php?query=ms%20%accesswhy do I get the search page with the query box filled in? Does this simply indicate that the POST is redirecting to SELF? Similarly to the way:$_SERVER['PHP_SELF']works?
That is up to the code on the page to handle what to do when you load the page. You are loading the search.php page with a query string of "query=ms access". PHP_SELF would still point to the search.php page.
Secondly, I'm confused on how the 'process' action works. Someone here told me a while back that 'do' was a field in the db table, which makes sense. But what about the 'process' part? Is there some PHP function code in another field that is read or executed based on the 'do' input value?
"process" is the string value for "do". It implicitly does nothing. The code in the page would have to get the value of do(ala $_GET['do']) and perform whatever action they wanted to do. Often "do=process" is just for reference -- the real data that's getting processed would be in the POST payload.
I would expect someone to respond to my post here, as I'm simply wanting to learn a little bit about this different method of doing things with PHP, but if the answers I would get would expose the security measures used by vBulletin, then I guess I don't expect any responses.
There is no security issue. Any of that information is easily viewed by everyone. :)

are you saying that every piece of code is executed on that page itself? if so, it must be a pretty big page!

if the form is validated though, the URL returns:search.php?searchid=39282722and a different page content is ultimately displayed. Is the code that generates that page also somewhere written in the search.php page?

it would have to be, right?

And can you offer any insight into how the searchid is generated? if form validation occurs, would that simply be an INSERT INTO statement performed on the database before the db is queried a second time to generate the new page content?

as it might be obvious, I am also really trying to test out whether or not this sort of search page method can be vulnerable to attacks or injections. But if everything is being executed by PHP on the server side, wouldn't it be virtually impossible to find a security hole? For one thing, the code will never be seen by a browser, so isn't that more than half the battle?

one other thing I would like to know, if possible....for a forum like this one, what constitutes a database record? the threads or the actual individual posts? I would think it would be the posts, but that's only from observation. am I right?

thanks so much for your input too!

are you saying that every piece of code is executed on that page itself? if so, it must be a pretty big page!

if the form is validated though, the URL returns:search.php?searchid=39282722and a different page content is ultimately displayed. Is the code that generates that page also somewhere written in the search.php page?

Yes. The page is ~24kb.

And can you offer any insight into how the searchid is generated? if form validation occurs, would that simply be an INSERT INTO statement performed on the database before the db is queried a second time to generate the new page content?
The searchid is generated by vBulletin as part of its caching mechanism. There are actually several queries that it will run in the course of executing search.php, and its includes. It does some pretty advanced stuff that you probably won't understand yet without diving in to the code. (no offense)
as it might be obvious, I am also really trying to test out whether or not this sort of search page method can be vulnerable to attacks or injections. But if everything is being executed by PHP on the server side, wouldn't it be virtually impossible to find a security hole? For one thing, the code will never be seen by a browser, so isn't that more than half the battle?
As with any page that is publicly accessible, it is possible to be exploited. However, the vBulletin team does good job of using preventative measures, and swift updates when a possible exploit is found. In general though, it's not inherently dangerous to anyone all the time.
one other thing I would like to know, if possible....for a forum like this one, what constitutes a database record? the threads or the actual individual posts? I would think it would be the posts, but that's only from observation. am I right?
vBulletin uses something like 150+ tables I believe. There are tables for posts, their data, threads, searching, users, profile data, etc. etc.