laffin

Yep, hated them nested queries, but how often to you actually change/add/remove forums? My answer, very few... So doing queries to do this for every user wasnt really an option. So what I did, was built a multidimensional array with the db id's in php and save it somewhere (I used a plaintext file). You can store it under other mechanisms, but I just wanted something simple. So anytime I needed the id's of parent/child forums. I would load up this cache file, and quickly grab the entries for the db.

Quick note: anytime the phrase "no refresh/reload" with dynamic content than your looking at javascript/ajax/jquery you cant display an image from the html processing script, they have to remain seperate scripts (your html output script & your image script) using js to detect a change on your form to update the image itself

Correct, and you will have to use header('Content-Type: text/xml'); to dictate that the content being delivered is an xml file and be handled by the browser appropriately

You don't need to generate files, as Thorpe said php is dynamic, so it can generate the file content on the fly. with a bit of htaccess help to map xml urls to a php script (http://mysite.com/user.xml), or path_info (http://mysite.com/timeline.php/user.xml)(both using apache, other webservers you will have to lookup how to create a virtual file mapping) or just use url parameters (http://mysite.com/timeline.php?u=user). To generate actual files at specific intervals, you will probably looking at cron with a long running php process, or someway to update users while browsing your site. Of all Thorpe's suggestion is by far the easiest method.

yer missing the point A character can be 2 bytes as well this all depends on yer character representation (UTF8 for example) 1 byte - 0-255 dec 00-FF hex (an ascii character) 1 bit - 0-1 - base 2 number system 1 nibble - 0-15 base 16 numbering system (0-F hex) 1 byte = 2 nibbles = 0-255 (00-FF hex) [quote]Darkfreaks said a SHA256 was 64 Characters... 256 Bits would equal 32 Bytes and thus 32 Characters, right? 32 bytes in length, correct. However to maintain some sanity this sequence is returned in HEX notation so only using characters 0-9 and A-F (2 characters to represent 1 hex byte). Thus the 64 bytes that dark was referring to. This is done to keep some sanity between various systems/languages.

Reason I said that the password hash system shouldnt be a big worry on your security list. a simple unique salt hash system should suffice. The bigger question is external data and users. which you should be looking at closely. This is where a lot of ppl fail miserably. They spend 2days on a hashing system that doesnt provide any more security than say $salt=md5(time());{/code] and usually leave gaping holes when handling $_GETS/$_POST information.

They both are relatively the same. Concept use an array to build the option list, Pikachu uses the keys as identifiers I went as an all array solution. the selection selector is also the same, just placement is different about only thing is there is a bug in pikachu's code, actually a typo "<option value=\"k\" should be "<option value=\"$k\"

Thats a real bad example there. 1) is your selection boxes always hardcoded, and you are selecting if from a value? Learn to use an array, and loops $opts=array( array('','Select your option...'), array('1','Selection 1'), array('2','Selection 2')); echo '<select name="id">'.PHP_EOL; foreach($opts as $opt) echo ' <option value="'. $opt[0] .'"'. ($id==$opt[0]?$' selected':'') .'>'. $opt[1] .'</option>'.PHP_EOL; echo '</select>'.PHP_EOL;

Myself, it really depends on the script itself. Sometimes I leave plain text passwords Sometimes I use md5/sha1 + salt The deciding factor on which system to use, is script security. If you sanitize/validate external data, and are relatively sure that the script is secure from hack attempts. If there is 1 or 2 admin users, you should be relatively ok with plain text passwords (of course this is on a dedicated server with few ppl who have access) People can bring up the brute force argument, but listen, if you allow an infinite amount of logins, than you have a big security hole in the first place. only allow a certain number of password attempts before locking out the account, sending email/notices to staff. You don't need to get all crazy with the hash system. A random salt added to the users record, and updated every so often is a good idea. but there is no need for 1000 char salts, or repeating the hash generation. Security is reliant on Staff/users and coding to handle external data. Poor judgement in either will usually compromise your data.

Avoid the creation of the files, and let the script do the inserts. Look at what you are manually doing, and see if it can be automated,

But you don't really need it. I think the manual splitting of the file is unnecessary. the processor is a conglomeration of if's, which should be optimized. Using a switch/case or just using continue, to avoid any more if comparisons. You should be looking at your manual work and looking to automate that. <?php $fh=fopen('sample.txt','rt'); $details=array(); $insection=FALSE; $ctr=0; while(!feof($fh)) { $line=fgets($fh); $id=substr($line,0,2); if($id!=='BS' && !$insection) continue; switch($id) { case 'BS': // Initial Processing $id=md5(microtime()); $insection=TRUE; break; case 'TI': case 'BX': case 'LO': case 'LI': // Each section should have it's own processor break; case 'LT': // Do Final Processing Here $ctr++; $insection=FALSE; } } fclose($fh); echo "Processed $ctr sections"; ?> This should handle each section of the BIG FILE, just add your processing code

foreach($_POST['hdds'] as $key => $a) { $hddbrand = $a['hddbrand']; } thats all there is to iterate through your variables. Question is what kind of manipulation you are having issues with.

And how does the php script get the image from javascript?

My money is on he has other sanitization going on, perhaps magic_quotes? but still it would generate an error for unknown data type. But thing is as everyone has been saying, check the data along its path to the query. to keep these debugging messages from distorting your pages, you can always put them in html comments echo '<--- SQL Query:'. $query .' --->'. PHP_EOL;

It provides no real extra security, if you have issues of ppl getting the hash, than thats more of a security leak. As I said, I can store all sorts of sensitive information in plain text, as long as I was fairly positive that my script handle the security of external data coming in was sanitized properly. Or that data was going to be handled by non privlidged class users, than I would store data encrypted/hashed. My point was that if you think that md5/sha1 provides security, it doesnt, your script provides security, md5/sha1 just provides a quick check of data without exposing the plain text data