PFMaBiSmAd
-
Posts
16,734 -
Joined
-
Last visited
-
Days Won
9
Posts posted by PFMaBiSmAd
-
-
You would need to post your code to get specific help with what it is doing.
My guess is that you are missing some <?php and ?> tags somewhere.
-
Remove the ; after the now() in the following line of code -
$add_post_sql = "INSERT INTO forum_posts (topic_id, post_text, post_create_time, post_owner) VALUES ('".$topic_id."', '".$_POST["post_text"]."', now();, '".$_POST["topic_owner"]."')"; -
It is likely that the syntax being used to set them is not correct. Post actual examples.
It is also possible that the php.ini that you are making changes to is not the one that php is using. The memory limit being set in the script would override any setting in php.ini, assuming the syntax is correct.
-
Please read the error -
output started at /home/runningp/public_html/index.php:7index.php, line 7 is outputting content to the browser that was preventing the session_start() and is preventing the header() redirect from working. Your page cannot output content to the browser and then do anything that needs to output a header. Correct the code so that nothing is output before the headers.
Look at it this way - if you are outputting content to the browser on a page that can redirect to another page, before you make the decision to redirect, you are wasting processing time and bandwidth every time that page is visited. Do any logic to figure out what the page will be doing first, then output only the content that is appropriate on that page.
-
I am using php to do multiple includes of huge amounts of data but it is definitely not very efficiant. and very difficult to mannage.
Based on that, it sounds like you should probably be using a database and then use php to dynamically build the web page, rather than just using php to include pieces of content.
-
The portion of the query right after single-quote in the error that mysql outputs is the point where it found something it cannot figure out. GROUP is a reserved keyword. [From the previous post - time is a data type, not a reserved keyword and it is permitted to be used as a column name.]syntax to use near 'group -
There was just a recent thread with similar problems - http://www.phpfreaks.com/forums/index.php/topic,168465.0.html Your code is dependent on register globals being on (variables magically appear from post/get/files/session/cookie data). This is not an issue with the PHP version but of php settings. Register globals are apparently off (as the should be) in the PHP5 settings.
What is sad about this is that register globals were turned off by default in php 4.2 in the year 2002. No new code, tutorials, books... should have been written after that point in time that relied on register globals being on. That was 5 years ago. Everyone on the planet should have gotten the message by now to not continue writing code this way. Register globals have been completely removed in PHP6, so everyone will need to fix any code that is dependent on register globals by the time PHP6 is released.
Edit: The posted code has no error checking, error reporting, or error recovery on the mysql function calls and will result in a blank page any time the mysql server cannot be connected to (which happens more than you would think.)
-
PHP outputs (X)HTML/CSS/Javascript content when the page is requested. The overall page is what must be valid and is what is validated.
Individual include files are not validated, because they don't have meaning until they have been included into a page. In fact, because of the doctype/html/head/body structure of a web page, include files would not validate because each of them would not necessarily contain all the structural elements required to make a whole web page (depending on how you are using includes.)
-
Blank pages are usually caused by fatal php parse errors. Check your web server log for errors.
-
Both - display_startup_errors and safe_mode cannot be set in a script at all.
The reason why the other two lines don't help you (they work for everything except fatal parse errors) is because a parse error occurs before the code is executed and those two lines never get executed.
To see fatal parse error you either need to check your web server log for errors or turn on display_errors and set the error_reporting level in php.ini or a .htaccess file.
For a .htaccess file, use the following -
php_flag display_errors on php_value error_reporting 6143
The 6143 value is the equivalent of E_ALL, but the constant E_ALL has no meaning outside of php.ini or a php script.
-
Change all the short open tags <? to full open tags <?php
-
Output started at line 1 in a php file either means there is white-space (space, tab, newline...) before the <?php tag or the file has been saved as a UTF-8 or Unicoded file and the language coding characters are being output as content prior to the <?php tag. Make sure there is no white-space before the <?php and make sure the file has been saved as an ANSI/ASCII file.
-
Short answer - no, not directly. You need a public mail server.can i send mail with my "http://localhost/" ?There are two problems - The php mail() function "looks" like an un-authenticated email client. You also don't have an email server on your localhost computer (and just for learning and testing - installing, configuring, and meeting all the DNS requirements for an email server is out of the question.)
You can send an email to or through your email account at an ISP, but you would need to use SMTP authentication (username/mailbox name and password) against that email account, which the php mail() function does not support.
To do this you need to use one of the php mailer classes, such as phpmailer http://phpmailer.codeworxtech.com/ or swiftmailer http://www.swiftmailer.org/
You basically need to make php look like an authenticated SMTP (sending only) email client. Actual settings vary by ISP and most ISP's have instructions for sending to/through them from a php script. If they don't have php specific instructions, just use typical instructions for setting up a client program like Outlook.
The good news is that once you get your code working with one of the php mailer classes, you only need to change settings when you put your code onto a live web server.
-
Lol. The above fix eliminates the security hole caused by register globals, however, if your code has security holes itself...Am I still vulnerable to security holes that my script may have?
-
From the php manual -
Most of the time, you were expecting a variable to come from outside your code, so there was little it could do that was harmful, because we are all verifying external data once it reaches the server, correct?When on, register_globals will inject your scripts with all sorts of variablesHowever, you do expect session variables to be safe from being set to a value by a hacker. There is an exploit present when register globals are on that allows an external value to be used in place of a value in a session variable. This does not actually set the session variable to a value, it sets the program variable with the session variable's name to a value, but you expect this program variable to be set from the session and not from a hacker putting a parameter on the end of the url. I just wrote this in a different thread in this forum -
What this means is if you are using session variables, which you would normally expect to be safe on the server and register globals are on and the code is referencing the session variable by its' registered global name $some_variable_name instead of $_SESSION['some_variable_name'], it is possible to visit a page, without visiting the page that sets that session variable first, and you can simply use a GET parameter on the end of the URL with the same name as the session variable and set that variable to any value you want in the code. For public scripts where the name of variables are known, this allowed things like making someone appear logged in or making them an administrator...Basically, with register globals on, you don't necessarily know where a value in a variable came from (thank you register globals.)
Any $_POST['variable_name'], $_GET['variable_name'], $_FILES['variable_name'], $_COOKIE['variable_name'], or $_SESSION['variable_name'] variable that magically set's the program variable with the same name $variable_name needs to be changed to use the $_POST['variable_name'], $_GET['variable_name'], $_FILES['variable_name'], $_COOKIE['variable_name'], or $_SESSION['variable_name'] instead. This will both make sure that you know where the variable is coming from with register globals on and it will allow the code to work with register globals turned off (or when they are completely eliminated.)
There is a built-in php function that can extract() all the variables in an array and there are a number of php code snippets that "emulate" register globals being on that will blindly go through all the POST/GET/FILES/COOKIE/SESSION variables and populate regular program variables by the same name, however if these are not used carefully, they re-introduce the same security problems that register globals had.
It is best to individually go through and set program variables from the corresponding POST/GET/FILES/COOKIE/SESSION variable so that you only set the program variables that you know you want and you know where they got set from.
-
Register globals are a huge security hole and have been eliminated in PHP6. Fix your code to work now with register globals off and it will keep working when PHP6 is released. Don't fix it now and it will stop working again on PHP6.
-
Where is $file getting set from? If it is from a form or a url parameter, your problem is that the code is dependent on register globals being on and this has nothing to do with PHP version.
-
The error message indicates that the three connection detail variables don't have any value at the time the mysql_connect() function was called.
I would guess that you are using PHP4. The "public" keyword being used to define those variables is only valid in PHP5.
-
$_POST and $_GET (and $_COOKIE/$_FILES) are sent by the browser. Any external data must be verified to make sure it contains only what you expect.
Any external data that is not verified can cause problems depending on how it is used in the program - database query, content in a forum post, headers in an email, code in a template, content in a file that was uploaded or written to a file, a string put into an eval() or shell() function, used to trigger errors that expose program and database information...
I believe your reference to variable poisoning is in relation to register globals? What this means is if you are using session variables, which you would normally expect to be safe on the server and register globals are on and the code is referencing the session variable by its' registered global name $some_variable_name instead of $_SESSION['some_variable_name'], it is possible to visit a page, without visiting the page that sets that session variable first, and you can simply use a GET parameter on the end of the URL with the same name as the session variable and set that variable to any value you want in the code. For public scripts where the name of variables are known, this allowed things like making someone appear logged in or making them an administrator...
There is a good reason why register globals were turned off by default in php 4.2, sometime in 2002. They were a great blunder. The php.net recommendation at that time was that no new code should be written that depended on register globals being on. Register globals were only a lazy-way short cut of getting the programming language to do something that the programmer should have been writing code to do himself, with disastrous results.
-
I think this will answer most of your questions -
When a browser requests a page, the page is read by the server and sent out to the browser. If that page happens to use php code/data that php code is parsed and executed. When the end of the page is reached, all the resources used by that page are released. So, if a php program variable exists, it is destroyed when the code execution stops. The web server then goes on to serve up other requests. It does not know or care that it just served any page to any visitor.
Each request by a browser for the same or any other page is completely separate for any one visitor and these are completely separate from any other request for any other visitor's browser. The only thing that ties requests for the same or any other page to a visitor is information that the browser provides (cookies, session id cookie, session id on the end of the url...).
$_POST and $_GET are actually external data from the browser that is sent by a form (POST and GET) or as parameters on the end of the requested URL (GET). They are not actually used to pass program variables between pages, unless those pages are forms or you want to build links that must be clicked. Since $_POST and $_GET values are in the hands of the visitor in their browser, they can see and modify the values. For program variables that must remain out of the hands of the visitor, they must remain on the server (in session variables.)
The only way to directly share program variables between requests for the same page for any one visitor or between different pages for any one visitor is to use sessions and session variables. The only way to share data between different visitors (or between different sessions for any one visitor) is to store that information in a globally accessible location, such as a database or a flat-file.
-
Looking further down in your code, $Orig is where you create the image from $uploadfile, but you are using $uploadfile in the imagecopyresampled() instead $Orig.
-
Your if/elseif logic that tests for the $filetype blindly continues execution when the type does not match "image/jpeg" or "image/png".
You need to prevent the resizing code from executing if there was not match and you need to echo out what $filetype actually contains. Either it is empty if the upload failed (you are checking the upload ['error'] element?) or it could contain a type your code does not expect, such as "image/pjpeg"
-
The 500 page error sounds like a bug that was recently introduced in PHP 5.2.4. In their infinite wisdom, php.net decided to - "Changed error handler to send HTTP 500 instead of blank page on PHP errors."
That by itself is not really a problem, but unfortunately, the programmer that changed the code removed or bypassed the call to the output buffer flush routine, so if you have output buffering on in php.ini and there is a fatal parse or runtime error, you won't get any output on the page (any errors due to error reporting or content up to the point of a fatal runtime error to indicate at what point the error occurred), just the HTTP 500 page.
If the above is what you are seeing, either upgrade to php 5.2.5 or turn off output buffering in php.in/.htaccess.
-
When learning, developing code, or debugging code, always check your web server log for errors and/or turn on full php error reporting.
If this is on your development system it is likely that the tmp folder that php is storing the session data files in either does not exist or does not have the proper permissions. It is also possible that the .php files have been saved as UTF-8 or Unicoded files and are outputting the language encoding characters before the <?php tag.
In either case, an error will be logged to help you pin down what the problem is.
[SOLVED] Changing Date Format when called from mysql dbase.
in PHP Coding Help
Posted
You can use the mysql date_format() function directly in your SELECT query, that is what it was designed for - http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html