Jump to content

flhtc

Members
  • Posts

    13
  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling

flhtc's Achievements

Newbie

Newbie (1/5)

0

Reputation

  1. Thanks!!! They are only used to return user names etc... They are unset after each use so... I really didn't see a need to make new ones for each function. I just didn't know whether or not it was best to make new ones or reuse the old ones. In my case, it's much easier to reuse them since their use is so limited, and copying scripts and modifying them at least in this context makes my life a whole lot easier. FLHTC P.S. How do I mark this as solved?
  2. I was hoping this would be an easy question. Is it better to make new session variables that return similar values for each function, or reuse them? Keeping in mind that they would be unset after each use. I.E. function this() $retval=do somthing if($retval == 0){ $_SESSION['ftpreguname'] = $_POST['vnd_login']; $_SESSION['ftprsuccess'] = true } else{ $_SESSION['ftprsuccess'] = false } function that(){ $retval=do more f($retval == 0){ $_SESSION['ftpreguname'] = $_POST['usr_login']; $_SESSION['ftprsuccess'] = true } else{ $_SESSION['ftprsuccess'] = false } is the same variable Ok, or should I use a different one for each function even though they are being unset after each use?
  3. Ok, the procFTPRegister() function is called. It in turn set a session variable(first code snippet) $_SESSION['ftpreguname'] = $_POST['vnd_login']; which upon return to the program uses that variable (second code snippet) to display the user name different messages depending upon the success or failure of the functioon. There are other function that do other things that if I can reuse the variables would make it easer to program I.E. less to remember. function called: <?php function procFTPRegister(){ global $session, $form; /* Convert usr_login to all lowercase (by option) */ if(ALL_LOWERCASE){ $_POST['vnd_login'] = strtolower($_POST['vnd_login']); } /* FTP Registration attempt */ $retval = $session->ftpregister($_POST['vnd_login'], $_POST['vnd_company'], $_POST['vnd_contact'], $_POST['vnd_phone'], $_POST['vnd_site'], $_POST['vnd_email'], $_POST['subftpregister']); /* Registration Successful */ if($retval == 0){ $_SESSION['ftpreguname'] = $_POST['vnd_login']; $_SESSION['ftpregsuccess'] = true; // header("Location: ".$session->referrer?user=$_POST['vnd_login']); } /* Error found with form */ else if($retval == 1){ $_SESSION['value_array'] = $_POST; $_SESSION['error_array'] = $form->getErrorArray(); // header("Location: ".$session->referrer?user=$_POST['vnd_login']); } /* Registration attempt failed */ else if($retval == 2){ $_SESSION['ftpreguname'] = $_POST['vnd_login']; $_SESSION['ftpregsuccess'] = false; // header("Location: ".$session->referrer."?user=$_POST['vnd_login']"); } header("Location: ".$session->referrer."?user=$_POST[vnd_login]"); } ?> return <?php if(isset($_SESSION['ftpregsuccess'])){ /* Registration was successful */ if($_SESSION['ftpregsuccess']){ echo "<h1>Registration Sucessful for: <font color='#ff0000'> $_GET[user]</font></h1><br><br>"; echo "<a href=\"../index.php\">Back to Main</a></p>"; echo "<a href=\"register_ftp_user.php\">Register another FTP User</a>"; } /* Registration failed */ else{ echo "<h1>Registration Failed for: <font color='#ff0000'> $_GET[user]</font> </h1>"; echo "<p>We're sorry, but an error has occurred and your registration for the usr_login <b>" .$_SESSION['reguname']."</b>, " ."could not be completed.<br>Please try again at a later time.</p>"; } unset($_SESSION['ftpregsuccess']); unset($_SESSION['ftpreguname']); ?>
  4. Another way to do it might be: <?php function getNumMembers(){ if($this->num_members < 0){ $q = "SELECT * FROM ".TBL_USERS; $result = mysql_query($q, $this->connection); $this->num_members = mysql_numrows($result); } return $this->num_members; } ?>
  5. Hopefully a simple question. When using session variables, is it better to make new variables or reuse old ones making sure that they are unset after each use? I have several different functions that return a user name or login name and, whether or not the function was successful. Is it better to use a different variable for each function or reuse a single variable, either way I would make sure it is unset after each use. Or does it really make a difference? Thanks, FLHTC
  6. Barand, Thanks for the input. I didn't know it could be done like that. Not exactly what I was after, but Very helpful. I did some more looking at my problem. I guess what it boils down to is the value of the input tag sent along when submitting the form to a function. What's confusing to me is that when submitting a form all the field names and their values are sent just like a variable, well I guess that's because they must be variables. Every thing I've seen in my vast (2 weeks) experience in PHP is that, variables start with a $. Also, the single quote double quote an no quote at all when using variables. I've been shell scripting for 20+ years dabbled in ansi C, Basic, and a few other languages and they all seem to handle variables a little more consistanly, at least it seems that way to me. But, that's the "fun" of learning a new language. This is an awesome and powerful language for building web content. I'll get it eventually. Best Regards
  7. I'm a bit of a newb, in over my head and loving it!!! Please excuse the long post, but I'm trying to give as much info as necessary to paint a clear picture. I downloaded a PHP login script and am modifying it to work with our FTP server's database. The scripts are quite complete as far as registering, modifying, etc.. of internal users. They also have quite complete validation of the forms. I've created additional scripts for adding and modifying FTP users. I have two scripts that do almost the same thing. The first is to register a new FTP user. I've been able to create the functions necessary for validation of the FTPuser registration form. Everything works fine. The second script is to modify an existing users profile. Both scripts use identical fields with the exception that the login name cannot be changed in the modification script. My question is; can I pass an 'extra' variable to the registration function? Basically to differentiate between modifying and adding a users info. The validation is the same. I can modify the existing registration function once the variable is passed to update instead of insert into the database, no problem. The thing is that their are three places it goes before the work is done. The forms are submitted to the process.php which checks for the existence of the $_POST for the desired process. This in turn hands it off to a local function that does a little magic and again sends it off somewhere else, this time to the session.php file which does the validation of the form and on success, submits the the variables to the database. The registration for is submitted with a variable of subftpregister to the process.php with a value of 1. I set the modification form to use subftpmodify with the same value of 1. I think if I use the same variable for both submit buttons and set the value differently it could be done. I also think that the key is in the process.php where it states: /* Register a new FTP User */ else if(isset($_POST['subftpregister'])){ $this->procFTPRegister(); } If the value of subftpregister is "1" can I pass that to the session->ftpregister function as an variable tacked on to the end of the existing ones? So the passing line would be: $retval = $session->ftpregister($_POST['vnd_login'], $_POST['vnd_company'], $_POST['vnd_contact'], $_POST['vnd_phone'], $_POST['vnd_site'], $_POST['vnd_email'], $_POST['subftpregister']); Then use that variable to determine whether or not to insert or update? I think it took me longer to write all this than to either re-create the function, or give it a whack Any help and or direction would be appreciated. Thanks, FLHTC Here's snippets of the code so you can see what's happening. Rester New FTP User: /* includes */ include("../include/session.php"); include("../include/header.php"); ?> <html> <title>FTP Registratoin Page</title> <h1>Register an FTP User</h1> Check for existing session etc... /* Start of form */ <form action="../process.php" method="POST"> <table align="left" border="0" cellspacing="0" cellpadding="3"> <tr> <td></td><td><font color = #ff0000>30</font> characters or less.</td> </tr> <tr> <td>Company Username:</td> <td> <input type="text" name="vnd_login" size = "40" maxlength="30" value="<? echo $form->value("vnd_login"); ?>"> <? echo $form->error("vnd_login"); ?> </td> </tr> More fields... /* Submit Form for for validation and insertion into the database */ <tr> <td></td><td align="left"> <input type="hidden" name="subftpregister" value="1"> <input type="submit" value="Submit"> </td> </tr> Modify FTP User: /* includes */ include("../include/session.php"); include("../include/header.php"); ?> <html> <title>FTP Modification Page</title> <h1>Modify an FTP Users Account Info.</h1> Check for session etc... /* Start of forms */ <form name = "getvendorinfo" action="" method="POST"> <table align="left" border="0" cellspacing="0" cellpadding="3"> <tr> <td></td><td><font color = #ff0000>Manditory</font> Can NOT be changed.</td> </tr> <tr> <td>Company Username:</td> <td> <p><select name=vendor onChange="submit();"> <? /* Get the list of vendors from the database, then add them to the dropdown box */ $retval = $database->getVendorList(); foreach ($retval as $initem){ if ($_POST['vendor'] == $initem) { echo "<option selected = yes> $initem </option>\n"; } else { echo "<option> $initem </option>\n"; } } echo $form->value("vendor"); ?> </select></p> More fields that are filled in from the info from the previous field... /* Submit Form for for validation and update the database */ <tr> <td></td><td align="left"> <input type="hidden" name="subftpmodify" value="1"> <input type="submit" value="Submit"> </td> </tr> Process form: A ton of if else if statements for different processes. /* Register a new FTP User */ else if(isset($_POST['subftpregister'])){ $this->procFTPRegister(); } More else if, the the functions... function procFTPRegister(){ global $session, $form; /* Convert usr_login to all lowercase (by option) */ if(ALL_LOWERCASE){ $_POST['vnd_login'] = strtolower($_POST['vnd_login']); } /* FTP Registration attempt */ $retval = $session->ftpregister($_POST['vnd_login'], $_POST['vnd_company'], $_POST['vnd_contact'], $_POST['vnd_phone'], $_POST['vnd_site'], $_POST['vnd_email']); Check the $retval and give error codes, if any. Session.php /* Error Checking */ function ftpregister($sublogin, $subcompany, $subcontact, $subphone, $subsite, $subemail){ global $database, $form, $mailer; //The database, form and mailer object /* Username error checking */ $field = "vnd_login"; //Use field name for vnd_login if(!$sublogin || strlen($sublogin = trim($sublogin)) == 0){ $form->setError($field, "* Username not entered"); } else{ /* Spruce up usr_login, check length */ $sublogin = stripslashes($sublogin); if(strlen($sublogin) < 5){ $form->setError($field, "* Username below 5 characters"); } else if(strlen($sublogin) > 30){ $form->setError($field, "* Username above 30 characters"); } 200+ more lines of validation... /* Update database */ if($database->addFTPUser($sublogin, $subcompany, $subcontact, $subphone, $subsite, $subemail)){ return 0; //New user added succesfully } else{ return 2; //Registration attempt failed } }
  8. Thanks to both of you! Things are a bit clearer now. I've learned more in these few posts than I have in two weeks of looking around. I believe I have what I need to get started. My first revision of the current code should at least be more secure than it was. It almost has to be. Thanks again, FLHTC
  9. Thanks for the reply, Not being familiar with multi users programing, I am concerned about what and how variables are passed from server to client. Yes this does answer a lot of my questions. Given the fact that the data flowing between the client and server are separated from other connections, that would tell me that there would be no need to tie a session specific identifier such as the session_id() to the variables I want to use globally once a session has started, and, It would be better to use session_start() at the beginning, and use session variables since the browser cannot change them. At least from a security point of view. One more thing, if you don't mind. Since _POST and _GET are stored local to the client. Is this where it is possible for the variable poisoning I've read about to occur? Thanks Again, FLHTC
  10. = sets a value == test to see if it is equal to that value $a = "This" if ($a == "This) echo "A = $a"; And, Yes it is paranoia.
  11. Your original code has active_users in twice. Once for ausers= and again for guest =. I would say you should change the second one to guest_users.
  12. Hello, I'm very new to PHP. I've been wanting to learn it for a while now and have finally got the chance. I've been programming for 20+ years, mostly Unix / Linux scripting (awk,sed,etc...), some basic C (mostly file manipulation), and yes even DOS's GWBASIC. All my programing experience has been in single user applications, hence the questions regarding multiple user programing. I have looked around on this and other sites and can't find much pertaining to my particular questions. Whether that's do to not searching for the proper terms or they really aren't there, I don't know. I've inherited an "Engineering Change Notification" (ECN) program written in PHP and HTML. It's got a little of everything. It includes over 100 PHP scripts and 15 include files. These scripts were written back in 2000 / 2001 by college students. Since these were written for what looks like PHP 4.x, global variables were turned on. I've been playing with them for a couple of weeks trying to get a feel for PHP programing and how to get them up to snuff with PHP 5. If I'm going to revise them, I'd like to do i right. I've been using the php.net manual to find out what I can, looking at the examples and gleaning as much as possible. I think I have a basic understanding, well enough to be dangerous anyway. Already I've seen a few really cool what to do's and a few things I don't think are right. The program is setup in two sections. Non-secured and secured. The method for differentiating between the two is whether or not a session is started and if the user is logged in. The search, search results, and sub functions thereof are non-secured. Inbox, add, change, delete, etc... are secured. I have a few questions, some referring to basic PHP methodology, some security related, and I guess some would pertain to both. 1) Once a user opens a browser to the PHP program, before a session is started. What differentiates their variables from another persons opening the same script at the same time? Could the _POST variable array overlap (for lack of terminology knowledge) with other users opening the same script? Once a session is started, is the _SESSION variable array per session? Moreover, what if anything is best to differentiate variables for multiple users? I'm sure this would answer question #2. 2) Given the fact that the two sections of the program do overlap. That is to say, you can enter a non-secured section at any time. The method for passing variables can differ. Before a session is started I'm guessing you would use _POST to pass the variables globally between scripts. Once a session is started you could use _SESSION to do the same. The question is: Should I use _POST for all variables passed globally? Or start a session right away, use _SESSION to pass variables, and depend on the logged in variable to determine access to the secured sections of the program. 3) The global statement. (The examples are kind of sketchy) This is to say that the variable is global only to the script it's running in, and can be passed to and from functions within that script, and need only to be declared inside any function that uses it? 4) Passing variables between scripts especially include files where variables used throughout the program are set. Before a session is started, would _POST or _GET be the way to go here? 5) If the same variables are used in multiple scripts... Is it necessary to include the same .inc files again and again at the top of each script? Or do I use an include_once statement in each script? I think the reason for the redundant includes is that a lot of the scripts can be called from a number of other scripts. If you choose not to answer these questions which I totally understand. Could you at least point me to some tutorials or examples that will give me the information I need. I'll be more than happy to do the leg work, If I can find it. Thank You, FLHTC
  13. Hi, I'm brand new to PHP programming.  So please pardon my ignorance.  After all, ignorance is simply the lack of knowledge, not the ability to learn. Not only am I new to this, I've also been challenged to migrate a PHP based Electronic Change Notificaton program which also relies heavily on MySQL from PHP ver. 4.0.4 to 5.0.4. Apache ver. 1.3.12 to Apache 2.0.54  As my first challenge.  Now I've been scripting (ksh) and doing basic C programing in different *nix systems for a dozen years or so, so I'm no ID-10-T when it comes to programming.  I've been doing a lot of reading here regarding PHP, MySQL and such.  I've seen how variables now should be (for lack of a better term) delcared before being used.  I've also learned a bit about syntax.  The online manual is awsome!  I had the program up and running on the new server in about 20 minutes once I figured out how to set the php.ini file to be compatible (as near as I can figure).  There are a ton of notices regarding undefined variables, indexes, and offsets. What I need help with here is finding the differneces between the two versions.  What should I be looking for in the V4 program that V5 doesn't like?  Is there a place on this or other sites that would give me a good rundown? Trust me there will be a lot more questions regarding the best way to initialize variables, sharing them between pages, etc... once I learn a bit more. Thanks in advance, FLHTC
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.