Re: [Phplib-users] Form POST data not making it into auth_preauth()

[Nathaniel P. <np...@te...>]

Robert Van Overmeiren wrote:

>My (PHP 4.3.3) setup has register_globals = On.
>
>
>My form does have a 'do_preauth' input (with value set to 'do_preauth'),
>but I can't echo that value from within 'auth_preauth()' either.
>
>
>I did try to pull the form data directly from the $_POST array:
>
>  $do_preauth = $_POST['do_preauth']; 
>  $username = $_POST['username'];
>  $password = $_POST['password'];
>
>    ...but there's nothing there.
>
>
>If I change the form to method="GET", and use:
>
>  $do_preauth = $_GET['do_preauth']; 
>  $username = $_GET['username'];
>  $password = $_GET['password'];
>
>    ...auth_preauth() works, but then I wind up with passwords in the
>location field.
>  
>
Makes sense, since even if it redirects, it will append the session id 
to the existing query string.

>The test form is nothing special:
>
>  <form action="https://secure.uniteddrugs.com/members/index.html"
>enctype="multipart/form-data" method="POST">
>    <input type="text" name="username" size="12">
>    <input type="password" name="password" size="12">
>    <input type="hidden" name="do_preauth" value="do_preauth">
>    <input type="submit" value="submit" name="submit" value="Login">
>  </form>
>
>In practice, the inputs would be the hidden type (values populated from
>the Tomcat JDBCRealm), and a link would execute a javascript function to
>submit he form.
>
>
>My setup uses prepend.php3, so I guess that means I'm using
>PHP3-compatible sessions.
>  
>
You might try switching to using prepend.php if you can (you'll need to 
port any modifications made to local.inc over to local4.inc). It might 
help clear up the problem, though I can't say for sure. I'd do this as 
more of a last resort, if the other things I mention below don't work 
for you.

>In 'release_token()', I noticed the code that redirects to itself and
>appends the session ID. Its right around there that I loose the form
>data. I also noticed that if I echo '$_SERVER['REQUEST_METHOD']', its
>always 'GET' - even if my form does a 'POST'. Your info got me thinking
>so I tested and the method comes back as 'POST' both before and after
>the redirect - so I still don't know where and why that gets flipped
>around, but by the time I echo it back in 'auth_preauth()', the request
>method is 'GET'.
>  
>
If you can narrow it down to a specific line in session.inc where POST 
becomes GET, that would be helpful... You might also try physically 
commenting out the whole block in release_token() starting with 'if 
($this->mode == "get")'

>I noticed 'variables_order' in php.ini (Newer overwrite older). Maybe
>when the process flips from POST to GET, they get overwritten?
>  
>
I'd assume that $_POST just doesn't get populated when it switches from 
POST to GET. After all, if the request is a 'GET', then there shouldn't 
be any posted data to worry about, so PHP would ignore it. If you can 
run something to sniff the headers being sent back and forth between the 
client and the server, it might help shed some light on what's going on. 
I personally use the Proxomitron for sniffing headers (among other 
things): http://www.proxomitron.info

>The session mode is already set to 'cookie'.
>There was nothing for fallback mode, but I set it '= false', just to try
>- no improvement.
>I noticed the loop that does the redirect seems to be for primary mode
>'GET', so I don't see why the block executes at all.
>  
>
Make sure you are setting the mode in the subclass of Session that is in 
local.inc and /not/ in session.inc. The values in local.inc will 
override the ones in session.inc. If I remember correctly, PHPlib is 
packaged with Example_Session's mode set to 'cookie' with the fallback 
mode set to 'get'.

>Tomcat/JSP and apache/PHP are on the same server, domain, and protocol -
>just different ports, so I guess having Tomcat set a PHP-like cookie is
>a possiblity. This would be a browser memory cookie and not the kind
>stored in a text file, wouldn't it?
>  
>
Either one should work, but session cookies (those stored in memory) are 
probably all you need. I'm not sure if differing ports would cause a 
problem with cookies or not.

>The info is helpful, but I still don't see why the POST data isn't
>there. 
>
>
>
>-----Original Message-----
>From: Nathaniel Price [mailto:np...@te...] 
>Sent: Wednesday, October 13, 2004 1:45 PM
>To: Robert Van Overmeiren; php...@li...
>Subject: Re: [Phplib-users] Form POST data not making it into
>auth_preauth()
>
>
>Robert Van Overmeiren wrote:
>
>  
>
>>Hello,
>>
>>I have a secure https site running on Java Tomcat and I want to be able
>>    
>>
>
>  
>
>>to access an application built on PHP and PHPlib. I'm thinking I can 
>>have a link that submits a form with the username/password as hidden 
>>inputs. I've added the 'auth_preauth()' function (posted to phpbuilder 
>>in 2000) to my extension of the 'Auth' class:
>>
>>function auth_preauth() {
>> global $do_preauth, $username, $password;
>> $uid = false; 
>> if (isset($do_preauth)) { 
>>   $this->db->query(sprintf("select user_id, perms ". 
>>                         " from %s ". 
>>                         " where username = '%s' ". 
>>                         " and password = '%s'", 
>>                         $this->database_table, 
>>                         addslashes($username), 
>>                         addslashes($password))); 
>>   while($this->db->next_record()) { 
>>     $uid = $this->db->f("user_id"); 
>>     $this->auth["perm"] = $this->db->f("perms"); 
>>     $this->auth["uname"] = $username; 
>>   } 
>> } 
>>return $uid; 
>>}
>>
>>The function is very similar to the 'auth_validatelogin()' function, 
>>but is called earlier in the whole process - before 'auth_loginform()'.
>>    
>>
>
>  
>
>>It is supposed to allow someone to use their own login form, and to 
>>bypass the default form.
>>
>>If I hard code in the username and password, I get authenticatied and 
>>go straight in. If I use a GET request method in the form, I can get 
>>in, but then the password is in the URL.
>>I can't get my form data into the variables via POST Method - which is
>>what I want to use.
>>The posting to phpbuilder doesn't say you need to do anything to get
>>    
>>
>the
>  
>
>>data into variables.
>> 
>>
>>    
>>
>Well, looking at your code, my guess would be that register_globals are 
>off in your setup, and that instead of auth_preauth() getting your form 
>data from $_POST like it should, it is trying to get it from the global 
>variable space. PHPlib was originally coded around the assumption that 
>register_globals was on; it's only relatively recently (around 2003, I 
>think?) that the register_globals issue was fixed to work whether or not
>
>PHP ran with register_globals off.
>
>I'd suggest replacing this line:
>
>global $do_preauth, $username, $password;
>
>with something that looks like this:
>
>//In addition to supplying a username and password, the form must have
>an element //named 'do_preauth' which is set to something that evaluates
>to TRUE in PHP, in order //for the preauth function to work. $do_preauth
>= $_POST['do_preauth']; 
>$username = $_POST['username'];
>$password = $_POST['password'];
>
>However, I can't be sure that this is the problem... It might be helpful
>if you post some sample code of the form you're submitting from as well
>as a stripped down version of the code you are using on your page. If
>you have customized other parts of PHPlib (aside from setting the
>database parameters), that might be useful to know as well. Also, are
>you using PHP3 or PHP4 sessions (i.e. are you using prepend.php or
>prepend.php3 to include PHPlib)? From your quoted start() code below, it
>seems like you're using PHPlib's PHP3-compatible sessions.
>
>Finally, one thing that has helped me understand PHPlib's auth system
>much better is this explanation here:
>http://www.drostan.org/Application/webdev/uod/auth_phplib.php
>
>At it's core, the auth_preauth function is nothing special... all it
>needs to do to do it's job is somehow return a PHPlib userid instead of
>false.
>
>
>  
>
>>I've been dissecting the phplib files and find that 'page_open()' calls
>>    
>>
>
>  
>
>>a 'start()' funtion from the 'Session' class, then a 'start()' function
>>    
>>
>
>>from the 'Auth' class (and another from the 'User' class). The Session 
>  
>
>>'start()' function makes a series of function calls itself:
>>
>> function start($sid = "") {
>>   $this->set_container();
>>   $this->set_tokenname();
>>   $this->put_headers();
>>   $this->release_token($sid);
>>   $this->get_id($sid);
>>   $this->thaw();
>>   $this->gc();
>> }
>>
>>I can echo back form data ($_POST['username']) up to point of the 
>>'release_token()' function. After that the data is gone and I can't get
>>    
>>
>
>  
>
>>it back.
>> 
>>
>>    
>>
>release_token() includes code that will cause a redirect (specifically, 
>it sends a 302: Moved Temporarily header and redirects to itself, 
>appending a session id to the URL) if $sess->mode is set to 'get' or 
>$sess->fallback_mode is set to 'get' and it doesn't detect that a 
>session cookie is set. Since the script tries to detect the cookie 
>before it gets set (that occurs in get_id()) when you first enter a page
>
>without an existing session cookie set on your browser, it will /always/
>
>redirect, even if your browser supports cookies. This is probably what 
>is causing you to loose your $_POST data.
>
>You can work around this by setting $sess->mode to 'cookie' 
>$sess->fallback_mode to null or false, as this will keep the code from 
>triggering a redirect. Unless you have a very good reason for supporting
>
>browsers where the user has turned cookies off (or even more rarely, one
>
>that doesn't support cookies), this should be an adequate solution.
>
>There may be a better solution that will support 'get' mode, but I can't
>
>think of one off the top of my head. You'd have to store your post data 
>in the session somewhere after the call to get_id() in release_token() 
>or something, and then have some corresponding mechanism for digging it 
>back out again. If you can switch to using PHP4-style sessions for 
>PHPlib, you might be able to do that more easily, as you could then 
>store the $_POST data in a PHP4 session natively, bypassing most of 
>PHPlib's session handling.
>
>  
>
>>What do I have to do to get the form data into the 'auth_preauth()' 
>>function?
>>
>>Of course, if you can suggest other ways to pass credentials between 
>>Tomcat container managed security and phplib, I'd be interested.
>> 
>>
>>    
>>
>The main problem is that it depends on credentials set at the client 
>end. So, basically, unless your Tomcat app can set a cookie that can 
>later be read by PHP and both your Tomcat app and PHP app are accessed 
>through the same domain name and protocol (i.e. both are accessed 
>through HTTPS), you're out of luck. PHP would also need to have access 
>to the same data store that you use to keep track of the session in
>Tomcat.
>  
>

-- 
___________________________
Nathaniel Price
http://www.tesserportal.net
Webmaster