meltingpoint

This simply means that you place important documents above the public_html folder. Then the only way to access it by calling it through a script as a regular link will not work. Why outside the public_html? Because if your site is ever hacked- they will only have access to files in the public_html folder and its sub folders. They will not see any files or folder above the public_html. The only way they would have access to those files is if they got your server id and password. I use this all the time. Before signing up for a host- make sure they allow you access to folders out side the public_html. Cheers- Andy

Exactly what was needed. Much thanks. (....i hope my hair grows back.....) Andy

Ok- entering a permission level of 1 - does not work entering a permission level of 1,2 or 1,2,3 or 1,2,3,4 works fine entering a permission level of 1,2,3,4,5 does not work nor does 1,2,3,4,5,6 or 1,2,3,4,5,6,7 entering a permission level of 2,3,4,5 works but 2,3,4,5,6 does not So to recap- a person will have at least 1 permission level 1-7. And can have any combination of all 7 permission levels i.e. 1,3,5,7 or 2,4,5 etc.....

Thanks guys- back from my coffee break. I will give it a try. Much thanks- Andy

Greetings regex experts. I have an input form that assigns levels to each user. There are 7 total. I need to test the input so that it is loaded properly. The edit box entry should look like : 1,2,3,4,5,6,7 - it needs to be separated by commas and need to end with no comma. - it can be 1,2,3 or 1,4,7 or all of them or only one or two - the important thing is that it be 1-7, each separated by commas and end with no comma. Any help would be appreciated. Tks

linjon- start a new thread

hashing is a one way street. The password that was created upon registration is hashed and stored in the database. Now, everytime the user signs in, that password is hashed and tested against the one existing in the database. If they do not match- you can be sure the person trying to sign in is not using the correct password. Hope that helps.

<?php $random = rand(10, 50); $name1 = "Jack"; $together = $name1.$random; ?>

Instead of having the page that has the form on it process the form (i.e. php_self)- have a 2nd page with your header/footer/menu etc. and in the body of that page- have your form processed complete with error messages or a "Thank for your form submission" if they enter all correctly.

The problem is that I cannot tie in the joomla session for the registered user as it is totally different from regular php sessions. The Joomla wrapper treats the page being wrapped as a completely separate page much like an Iframe. Creating a session variable in the page that gets wrapped doesn't work as it does not prevent the user from an initial direct access. For example- the page being called up in the Joomla wrapper via a menu is top_secret.php. I only want that page viewable if they access it via the menu. However- if they simply put top_secret.php at the end of the website - they will indeed have access to it. example: www.myweb.com/top_secret.php will itself initialize a session and is accessible Hope that makes sense. Also- how would they spoof the header if they don't know what it is to access that page?

I have a php page that is linked to in a Joomla site in a Wrapper. I want to be able to block access to a php page unless it was called by a link in the main menu. I figured I could use $_SERVER['HTTP_REFERER'] to accomplish this like so: Link from Main Menu -> top_secret.php <?php //the following is placed in the header of top_secret.php web page $page1 = 'http://myweb.com/index.php?option=com_wrapper&view=wrapper&Itemid=201';//page that user must come from $menu_link = $_SERVER['HTTP_REFERER'];//page that user comes from if($page1 !== $menu_link) { header('Location: http://myweb.com/error_page.php'); } ?> Thus if some one tries to simply access the top_secret.php with out going through the joomla menu- they will be re-directed to an error page. My question to the guru's is- is this secure or can someone easily get to the top_secret.php without going through the menu. Keep in mind- that the menu the person must use is only accessible from a registered joomla user for that site. Hope that makes sense.

Cool- thanks. Yeah- I always validate user input and have found for certain things it works best to assign $_POST['whatever'] to $name_whatever. But for brevity in most cases I will simply use the $_POST['whatever']. Again- thanks

Ok- I have seen it go both ways on this forum and I was wondering which is correct- or more secure. I have a script that receives $_POST variables from a form. Which is better- to change the name of the $_POST variable to do script manipulations or to simple do them with the $_POST['whatever'] $whatever = $_POST['var_from_form']; or simply utilize $_POST['var_from_form'] I know it would be less typing changing it to $whatever, but does it really matter? And yes- register_globals is off. Cheers-

That worked perfectly. Thanks a million.

Thanks- when I get off work I will give it a go. Much thanks!

**Could really use the help on this one. Anyone?

Wonderful. Yes- the database dates and form dates are formated the same. Yes- I need to do additional things with the remaining data- that is why I want to save those records in an array $matched so that I can do other things with them and then output the results. Problem is that the first iteration: $hold[$record_count] = explode("|", trim(fgets($openedfile))); takes the $openedfile and puts the first line into $hold[1] and then continues on until the end of the file with the loop. So the first line is not counted in the conditional statement. Also- if there is no record that INITIALLY meets the conditional statement inside the while loop- it does not reach the $record_count++. Here is what I have tried. $file = 'mytextfile.txt'; $openedfile =fopen($file2, "r") or die("ERROR- could not open file for editing."); // flock($openedfile, LOCK_EX) or die("Error!- Could not obtain exclusive lock on the file to edit. Please try again"); $hold[$record_count] = explode("|", trim(fgets($openedfile))); while(!feof($openedfile)) { if($hold[$record_count][1] >= $dateX && $hold[$record_count][1] <= $dateY) { $record_count++; $hold[$record_count] = explode("|", trim(fgets($openedfile))); } There is much wrong with this- but I am stumped how to: A- discard data not needed and B- Create new $matched array of data that meets the requirement.

example structure of text database- mytextfile.txt 10-11201|2010/09/01|Sam|Thurston 10-11307|2010/09/04|Tony|Piper 10-11405|2010/09/11|Sarah|Smith <?php $file2 = 'mytextfile.txt'; $openedfile =fopen($file2, "r") or die("ERROR- could not open file for editing."); // flock($openedfile, LOCK_EX) or die("Error!- Could not obtain exclusive lock on the file to edit."); $hold[$record_count] = explode("|", trim(fgets($openedfile))); while(!feof($openedfile)) { $record_count++; $hold[$record_count] = explode("|", trim(fgets($openedfile))); } ?> What I need to do is loop through this and one by one- take any arrays that contain a date that is between $dateX and $dateY (which comes via a form input) and place it in a new array $matched. I am stumped. 1-Is there a way to do it inside the above while loop that I am not seeing? 2- Do I need to open the file in another manner? 2- Would it be best to now loop through $hold[$record_count] I am trying to keep the process short so as not to use up too much memory. Point me in the right direction for this one please.

Do the pages that you are passing inside the I-Frame also have session_start() at the top of each page and also have the authentication confirmation script in them?

SESSIONS are good- but it has to be part of the security solution, not the total solution. Yes- they can be hijacked and manipulated (if you leave your self vulnerable to that exploit) SESSIONS are better for passing user permissions/info throughout the site than by the $_GET method. With SESSIONS I would; 1- Once a user is signed in- store the original IP address as a SESSION variable and check that on any secure page to make sure someone has not hi-jacked the session and is attempting to access the page from another location. 2- Never store the users password as a SESSION variable. 3- Create a time out scenario. Create a start time() on each page and check that on each subsequent page to see if say 30 minutes has passed with no activity. If the time between viewing pages is greater than 30 minutes- re-direct to a log-out page. Depending on your requirements- these are some security measures. There are many more that you can tailor to your needs. Hope that helps------------

What is messing up?

I am on a shared hosting server also. If yours allows, put sensitive files outside the public_html folder so that it is not in the root of your site. Then call the sensitive data from that folder via a script. I use flat files and this is the way I store them. That way, if someone gets by the .htaccess and is allowed to see my public_html directory tree- any and all sensitive files are not open to view. Some hosting does not allow you access to any thing above public_html though. And as suggested- ssl is a must in my opinion. Cheers

I am not sure about a program that will- on the server side, take an excel spread sheet and extract the data to a csv file to then be pulled into the php page for viewing. If they can- export the excel spreadsheet as a csv file and upload that to the server. Then when you call the php page - it will open the file and extract the data so that you can do what ever with it. My limited thoughts on this...........

Why couldn't you pass the variables with sessions. This way no one sees them, nor can they manipulate them. Another great benefit is that they are available for any page that gets called- rather than relying on passing them with the &_GET method.