Spectre

It is most likely that the program will reference the file with that extension - eg. include('file.lib'). As such, I wouldn't recommend changing the extensions unless you change all references to the files accordingly.It makes no difference as to what extension you use (or if you use an extension at all) if the file is going to be called from within an existing script that has already been executed - it will take the file, and if it contains the appropriate tags (eg. <?php ?>), process that as code. The only potential problem is that if someone tries to access the file directly, it will not be executed, but most likely displayed as plain text, unless you have configured your server to treat that file's extension as a PHP script.

There isn't really a way you can be 100% certain the form data wasn't faked. Referer, cookie and POST data can very easily be sent in a manipulated form. For example, I could forge headers along these lines and send it to your server, and it would be none the wiser: POST /script.php HTTP/1.1Accept: */*Connection: closeHost: your-host.comReferer: http://your-host.com/page.htmlCookie: fake-cookie=fake-cookie-data;xxx-type: application/x-www-form-urlencodedContent-Length: 3abc (Note that xxx = Content - IPB is filtering it out). A session ID can also be easily captured prior to submitting the data (it will most likely be sent either via a cookie, or attached to links), and then be posted along with it. Simply put, and just to re-iterate, there is no 100% certain way you can be sure form data is coming from a page on your server.

My understanding is that it was against the rules to post linsk to other free hosts. That may have changed, though. Anyway, good luck with your site, but I have to be honest - I don't think it will last very long. I don't mean to be synical or mean, but I think your 'I'll do it because it's fun' attitude is going to wear off pretty quickly, and once it does, you may start to wonder whether or not you still want to run your free hosting. As a quick whois check indicates the domain's registration date was March 16th, your site is obviously in its infancy. I think the reality of providing hosting for free - such as the costs involved - may not have dawned on you just yet. Once again, I truly wish you all the best, but I'm going to remain somewhat sceptical.

I would have to agree with Mich on that one particular topic.

In my strong-headed opinion, using such a title under such a domain is certainly not a good idea, much less listing it as a Xisto forum. I only just noticed it (from within the topic The So Called "vent"...), and think it does little other than degrade the forum as a whole. I'm quite surprised in this new direction, to be honest. It's not something I would have expected from an established web hosting community that is run from a web hosting company... but there you go. Notice from mayank: Merged into this already going topic

Just as a side note, table and field names can be enclosed in ` symbols (note that it is a grave accent mark, and not a standard quotation mark as you would use to delimit a string value), but it is not required. It is often useful to make it easier to spot the tables/fields referenced, and as it doesn't have any influence on performance whatsoever, it doesn't really make any difference whether you use it or not.

There is a PHP forum. I would suggest you post such topics there.Anyway, the problem appears to lie in the path you're specifying. Note in the error that it indicates the file path is prefixed with a slash - this means that PHP is going to try and look in the server's root directory, to which you almost certainly wouldn't have access (unless you own the server). Try adding $_SERVER['DOCUMENT_ROOT'] to the start of the file path.

Hmm, I don't particularly like this search engine, but it's easy to see how it will appeal to a lot of users - it is, in a nutshell, simple whilst being aesthetically pleasing, whilst lacking functionality. Something in which Microsoft seems to be quite adept. Still, I think that rejecting this search engine purely because it is from Microsoft is little other than arrogant ignorance.Anyway, we can probably start to expect more of this from Microsoft in the near future as they pick up the competition against the currently undisputed search-giant Google (and let's not forget the Google projects which have flopped either).

Any password encrypted with any common encryption system can be cracked. Take MD5 for instance - it is a one-way hashing algorithm, meaning that once a string is encrypted using this method, it can never, ever be reversed. However, it can still be recovered by hashing lists of passwords (dictionary-based or by brute-force, where every single possible combination is attempted). As an MD5 hash is made up of 16 hexadecimal values (32 byes), which can consist of any of 16 characters A-F and 0-9, there are (16^32) or 3.4028236692093846346337460743177e+38 possible combinations for any MD5 hash in existance (although I remember a while ago there were rumors floating around that MD5 can now be reversed or something). ANYWAY, my point is that although it may be incredibly difficult and take an unreasonable length of time, encrypted strings can be broken

AJAX is a reasonably new technique for developing web-based applications where they don't need to be refreshed all the time. Gmail is an example of utilizing AJAX - most of you who use the service would have noticed how whenver you click a link within Gmail's interface, it doesn't seem to load another page or anything. But what you want could be acheived with far simpler JavaScript events. The strength of a password can be calculated using any programming language. There's not really any set rule as to what makes up a 'strong' password, so no two programs which calculate such values are going to produce identical results; however, users are generally advised to include mixed-case letters (both upper- and lower-case), as well as numbers, and aim for passwords longer than about 8 characters. So most programs which work out how strong a password is use simple rules similar to that.

Assuming the PHP engine does process the code, then viewing it is not normally possible; but that's far from the only problem you need worry about. Injection is by far one of the most commonly encountered web-based attacks, where a user can 'inject' code to manipulate the way in which something behaves - for instance, code could be injected to modify an SQL query to extract information from the database which shouldn't be, or even execute a command on the server. You can't simply assume that because the user can't see your code or because the system has been secured against other forms of attack means that it's safe from other such methods. Anyway, a basic rule of thumb is to ensure that all data entered by the user is 'sanitized'. Whether it's entered in a form and sent via a POST query, or sent as part of the URI itself via a GET query, you absolutely have to ensure that you never, ever directly pass user-entered data to anything, regardless of how insignificant it may be. One of the biggest pitfalls a lot of PHP coders (not just those who are inexperienced - everyone can overlook small potential issues, especially when working on large projects, such as IPB) fall into is passing GET variables directly to a SQL query. For example, an older version of IPB would, when you selected to 'Quote' another user's post, append to the current URI something to the effect of 'qpid=xxxx', where 'xxxx' was the ID of the post you wanted to quote. Whilst not a problem in itself, IPB would pass this value directly to the database query, so it became something like: mysql_query('SELECT x FROM post_table WHERE id = ' . $_GET['qpid']); Note that it was in fact far more complex than this, but I don't remember exactly how the query was constructed, and this is only intended as an example. Now, the problem was that the user could alter the value of 'qpid', so it turn modified the query - for example, 'qpid=UNION+SELECT+password_field+FROM+user_table+WHERE+user_id=1'. And I'm sure the danger of that is evident. So anyway, my point is, you have to make sure you always process and sanitize data entered by users - never, ever, ever, ever, EVER assume that's it always going to be what your script is expecting, because it simply isn't. And that's Basic PHP Security 101 for today.

Yeah, I'd have to agree with one or two points made here. I am sorry that you had to experience such treatment, semeticsister (assuming it was based on religious or racial prejudice, and not just a mistake on your part), but it's just one isolated case. You can't assume that other Muslim people are going to act in the same way just because one did. There are many people that are a part of the 'Ku Klux Klan' and similar white supremecy groups, but does that mean all caucasians are ignorant, racist bigots? Of course not - the majority of us, thankfully, aren't. I think it's important to keep an open mind, and not assume that just because one person fits a stereotype or acts a certain way doesn't mean that others from the same religion, country, race or background will.

I'm not a moderator, but you should probably be aware that copying content - particularly such large amounts of it - without placing it within the 'quote' tags is against the Xisto rules. This entire post (save the opening line) seems to be remarkably similar to other posts on other forums. I don't mean any offense, nor to come accross as unfriendly or unwelcoming, but most of your 11 posts so far seem as though they have been made simply to get the minimum post count required for free hosting rather than actually contributing anything. That's probably something you should avoid doing.

I think you're making some very broad generalizations in your post, and you may want to be careful in doing so. I am not a religious person, nor am I overly familiar with either Jewish or Muslim customs, but saying that 'most' and 'they' is something that you should probably look to avoid when discussing such topics.

truefusion, although you are right on it picking up unclosed (or unopened) tags, I don't think your way would work all that well either. Your method would skip over text which contains a [ character - for example, in the sample text I provided above, '[ b ][ u ]rocks[ / u ][ / b ]' would not be set as bold and italic, but only as italic.

Well, I don't know exactly how IPB does it (as I don't have the source code on hand), but something like this should do the trick: $post = preg_replace('/\[url=http:\/\/(.[^\]]*)\](.[^\[]*)\[\/url\]/ie', '\'<a href="http://$1" target="_blank" title="\'.htmlentities(\'$2\').\'">\'.htmlentities(\'$2\').\'</a>\'', $post);

Regular expressions are used, but it's a little more complex than that. If you have a look through the source code of IPB (or any other forum software that supports bbCode tags), you'll be able to get a much better example than anything I can provide. Anyway, here's a quick example of how formatting could work (in theory, anyway): <?php$post = preg_replace('/\[(\/)?(b|u|i)\]/ie', '"<$1" . strtoupper("$2") . ">"', $post);?> [b]This[/b] is my [i]post[/i] and it [b][u]rocks[/u][/b].Becomes:<B>This</B> is my <I>post</I> and it <B><U>rocks</U></B>.

There's really only very little you can do to boost the speed of a dial-up connection. Although preventing images from loading or caching all content and other such things will decrease the page load time, they obviously don't increase the connection speed.The real limitating problem is the underlying physical hardware on which a dial-up connection operates (including the phone line). Other than upgrading to a faster technology (such as ISDN or xDSL), which unfortunately isn't an option for everyone, there isn't anything you can do to significantly increase the actual speed of a standard 56kbps dial-up connection (which, in some - or most? - cases, actually operates at less than 56kbps).

I would suggest storing a timestamp of when the user logs in, updating it every time that user visits a page within your site. Then once they haven't been active for, say, 20 minutes, you mark the session as logged out. IPB uses something along these lines to determine how many users are currently active.

Although I wouldn't recommend it, you could use something like: eval($exp1.';');while( eval('return '.$exp2.';') ) { /* Do something */ eval($condition.';');} This will, essentially, perform the same as a for() loop.

I would suggest you use $_POST instead of $HTTP_POST_VARS. The former has superceded the latter - to the extent that I think some newer versions of PHP have alltogether dropped support for the previously used variable. Also, I think it would probably a good idea to change the equivalent code above to: if (isset($HTTP_POST_VARS['addr']) && $HTTP_POST_VARS['addr'] != '' ) { $searchable = $HTTP_POST_VARS['addr']; echo 'searchable = '.var_dump($searchable).'</br>'; $stack=array(); ...extra code }... Remember to always enclose variable indexes (unless they are numeric) in quotes. $variable[index] may work on some systems, but $variable['index'] will work on all, and is a better standard of coding. Note that you should still replace $HTTP_POST_VARS with $_POST in the above block of code; I've just left it as is to make it easy to read. Also, in the last section of your script, don't you think it would be easier to enclose the string in single quotes, and not have to escape every double quote you encounter? print('<form method="POST" action="ifinfo-single.php"><table><tr><td><b>Enter IP/range/list: </td><td><input type="text" name="addr"></td><td><input type="submit" value="Submit"></td></tr></table>'); print('<table><tr><td valign=top><b>Valid values: </td><td><font size="-1"><ul><li>Single IP (172.16.32.152)</li><li>Range (172.16.32.140-144)</li><li>Semicolon seperated (172.16.32.140;172.16.32.151;172.16.32.152)</li></ul></td></tr></table>');

Windows uses \r\n (CRLF) as the new-line delimiter, and UNIX-like systems just use \n (I think Mac uses just \r, but I don't know). As a quick fix, trying replacing: $fp = fopen($folder_file,'r'); // open flat file for readingif (!$fp) {print 'ERROR: Unable to open file'; echo '<br />';echo $folder_file;echo '<br />';exit;}// error if no handle found for flat file$line= fread($fp,1024); // increase this length if required$f_array=explode("\n",$line); With: $line = @file_get_contents($folder_file);if( !$line ){ print 'ERROR: Unable to open file'; echo '<br />'; echo $folder_file; echo '<br />'; exit();}$line = str_replace("\r\n","\n",$line);$f_array=explode("\n",$line); Hope that's helpful.

This has nothing to do with PHP, and is related solely to markup. Please, for the sake of everyone, try and keep your posts in the appropriate forums (I mean, you are a moderator...).

There aren't that many differences between PHP4 and PHP5. Mostly, PHP5 just has new functions and features added, as well as bug fixes and enhancements to the language; to my knowledge, the fundamental usage of any existing functions has not been changed (in order to keep it backward-compatible). It would be quite dangerous for them to do so. As such, I'm going to suggest that it's either a problem with the script or the data being used. About 99.9% of scripts created for PHP4 should work on PHP5. I've only very quickly looked over the script, but there does seem to be a few enhancements that could be made.

That's something along the lines of what I was thinking. Here is a very quick, untested, written purely for example demo: <?phpclass database { var $_query_count = 0; var $_conn_id = 0; var $_query_result = 0; var $_execution_time = 0; function database( $db_host, $db_user, $db_pass ) { $this->_conn_id = @mysql_pconnect($db_host,$db_user,$db_pass); if( !$this->_conn_id ) { return false; } return $this->_conn_id; } function sql_query( $query ) { $time_start = time() + microtime(); $this->_query_result = @mysql_query($query); $time_end = time()+microtime(); $this->_query_count++; $this->_execution_time += ($time_end-$time_start); } function close() { @mysql_free_result($this->_query_result); @mysql_close($this->_conn_id); }}?> Usage could be something along the lines of: $database = new database('host','user','pass');$database->sql_query('SELECT X FROM Y');echo '[ Time: ' . $database->_execution_time . ' ] [ Queries: ' . $database->_query_count . ' ]';$database->close(); As I said earlier, however, this is not a 'universal' solution. You are going to have to do some coding of your own to integrate it into whatever environment you wish for it to exist. Hope it helps all the same. Oh, and feel free to use that code as you wish.