monotreme
02-25-2006, 02:59 PM
The site owners want to collect some additional information from the users when they register and put it in their own (non vb) tables. So here is how I did it:
1. I hacked the registration template and added the desired fields
2. I made a hook on register_addmember_complete
There's more than a few lines of processing and I want to be as independent as possible, so I tunneled the data to the custom application via curl. This thinking is just give the custom application the data but don't risk namespace conflict by sharing environment with vb.
$glomp=serialize($_POST);
$ch=curl_init("http://www.example.com/cu.php");
$pf = "id=" . $vbulletin->userinfo['userid'] .
"&loginName=" . urlencode($vbulletin->userinfo['username']) .
"&glomp=" . urlencode($glomp) ;
curl_setopt($ch,CURLOPT_USERPWD, "xxxxxxxxxxxxx");
curl_setopt($ch,CURLOPT_POST,1);
curl_setopt($ch,CURLOPT_POSTFIELDS,$pf);
$f = curl_exec($ch);
curl_close($ch);
unset($ch);
It specifically posts the new vb userid and username, and all the rest of the _POST data it just munges into a big glomp. Then it causes a new page request to happen in the background by using curl. The custom user program (cu.php) via curl filters out all the vb data and only cares about the custom data it is looking for.
What is supposed to happen:
a) cu.php goes off and does its thing asynchronously,
b) the hook returns and vb continues on it's merry way.
What actually happens
a) cu.php does it's processing just fine.
b) vb returns from the hook (verified by temporarily sticking
echo "back from hook"; exit;
right after the line in register.php where it evals the hook)
c) it fails to render a HTML page telling the user what to do next, i.e. we have
the dreeaded white screen of death.
Am I correct in assuming that the program cu.php is independent, i.e. that no variables set by it will come back into vbulletin. Even if it mistakenly set a session var (which it doesn't) it is originate from a different IP address (it originate from the server) than the user so it would be a different session. So I am a bit at a loss to figure out what is happening and why.
1. I hacked the registration template and added the desired fields
2. I made a hook on register_addmember_complete
There's more than a few lines of processing and I want to be as independent as possible, so I tunneled the data to the custom application via curl. This thinking is just give the custom application the data but don't risk namespace conflict by sharing environment with vb.
$glomp=serialize($_POST);
$ch=curl_init("http://www.example.com/cu.php");
$pf = "id=" . $vbulletin->userinfo['userid'] .
"&loginName=" . urlencode($vbulletin->userinfo['username']) .
"&glomp=" . urlencode($glomp) ;
curl_setopt($ch,CURLOPT_USERPWD, "xxxxxxxxxxxxx");
curl_setopt($ch,CURLOPT_POST,1);
curl_setopt($ch,CURLOPT_POSTFIELDS,$pf);
$f = curl_exec($ch);
curl_close($ch);
unset($ch);
It specifically posts the new vb userid and username, and all the rest of the _POST data it just munges into a big glomp. Then it causes a new page request to happen in the background by using curl. The custom user program (cu.php) via curl filters out all the vb data and only cares about the custom data it is looking for.
What is supposed to happen:
a) cu.php goes off and does its thing asynchronously,
b) the hook returns and vb continues on it's merry way.
What actually happens
a) cu.php does it's processing just fine.
b) vb returns from the hook (verified by temporarily sticking
echo "back from hook"; exit;
right after the line in register.php where it evals the hook)
c) it fails to render a HTML page telling the user what to do next, i.e. we have
the dreeaded white screen of death.
Am I correct in assuming that the program cu.php is independent, i.e. that no variables set by it will come back into vbulletin. Even if it mistakenly set a session var (which it doesn't) it is originate from a different IP address (it originate from the server) than the user so it would be a different session. So I am a bit at a loss to figure out what is happening and why.