PFMaBiSmAd

It's more likely that you have an error in your actual code, because for a table like you show, the code you did post works correctly (just tested) and that's not your actual code.

Nope. Nested forms are invalid HTML.

You should be developing and debugging php code on a local development system, for a couple of reasons. You waste a huge amount of time constantly uploading code changes just to see what they do and until code is completely tested, it often has security holes that would allow a hacker to exploit your live server. You can set the error_reporting/display_errors settings in a .htaccess file (when php is running as an Apache Module), in a local php.ini (when php is running as a CGI application), or even in your script (fatal parse errors won't be displayed because your code is never executed when there is a parse error and the two settings won't get set.)

You can test the dynamically produced image by browsing to: graybox1.php?txt=[C] I'm also assuming that you are developing and debugging php code on a system with error_reporting set to at least E_ALL and display_errors set to ON in your master php.ini so that all the errors php detects will be reported and displayed. You also have a $text_color v.s. $textcolor naming error in the code that prevented it from ever working.

The code you posted for graybox1.php produces a fatal parse error because of the { near the start of the code. It will also produce an error for the crError() function calls because there is no function definition in that code and you commented out the include that might have defined it. Did you even test that before you posted it here?

The src="..." attribute in the <img ...> tag is a URL The URL you use would need to be to your .php script that dynamically produces and outputs the correct image (a content type header followed by the image data) with the expected character on it. You would typically use a GET parameter on the end of the URL to specify what you want the dynamically produced image to be.

Every image on a web page requires a HTML <img src="url_of_the_image" alt=""> tag. The url_of_the_image must be to a .php script that outputs the correct content type header followed by the image data.

At least 'int' is a reserved mysql keyword (there is a table of reserved words in the mysql manual.) You either need to rename your int column to something else or enclose it in back-ticks `` every time you use it in a query.

For your https session problem, when you browse to a https page, look in your browser's 'page info' section (assuming you are using FireFox) and tell us what the PHPSESSID cookie has for a Send For: value.

Based on the error, line 84 of index.php is attempting to get a directory listing of the session data files, probably for an inefficient 'who is online' function. It is using the wrong path to the session data files. The :tmp is because open_basedir is set to accept /var/www/vhosts/domain.com/httpdocs AND /tmp The setting being discussed is session.cookie_secure It would be interesting to see what a phpinfo() statement shows for that setting, both through http and https.

I did just find a change log entry for Apache where mod_rewrite added a way to allow the Cookie option to set the secure and HttpOnly flags. Unless proven otherwise, I'm going to stick with the idea that web servers internally set the 'secure' flag when a cookie is set over the https protocol and you cannot normally pass a cookie back and forth between the two protocols.

Did you read the definition of mktime() in the manual? That is the only way you can effectively learn to use a function - http://us2.php.net/mktime

Hmmm. It does work. That contradicts available information (i.e. FF maintains separate cookie caches and does not pass cookies between protocols) and observed history (i.e. threads like this one where it does not work and threads where the only successful way of passing the session id would be to put it onto the end of the URL.) I can tell you why it works, at least in your case. The 'secure' parameter (of either the session id cookie or a regular cookie) is off. However, turning on the 'secure' parameter causes the session to only work under https and to not work at all under http. So, this alone does not explain the cases where you can have sessions that work under each protocol but don't pass between the protocols. You would need to 'dynamically' change the 'secure' parameter depending on the protocol used in the request for it to account for the observed operation. I suspect (but did not find any information either way) that this is something that specific web servers have done internally in the past.

So, is this a correct statement - You went from having a login script that used a session under https that somewhat worked (i.e. you could return to the login page and you were still logged in) to not having sessions work under https? Doesn't that suggest it is not the connection but that the current code is not setting or getting the session id cookie. You apparently skipped reading the following because the code you just posted does not contain the three lines of debugging code -

A persistent connection has nothing to do with the information a browser supplies with each http (or https) request it makes to the server using that connection.

You either have an error in your code or you are switching the domain and/or path and the session id cookie parameters are not setup to cause the cookie to match the switch. Post the URL's of the pages you are using (xxxxx out the domain portion if you don't want to post that information, but don't change any of the rest of the information in the URL's.) Near the start of this thread, you were asked to put in three lines of code that set the display_startup_errors, display_errors, and error_reporting level so that php would point out problems it detects. Are you still using this for debugging? It would take seeing the offending code. We cannot really tell you anything about why your code is or is not doing anything without seeing the actual code that exhibits the problem.

All browsers (are supposed to) maintain separate caches for http and https cookies for security reasons. If you found a case where a cookie (session or otherwise) is being passed between protocols, you either have a browser that is insecure or you are actually passing the session id through the URL and not through a cookie.

For the same reason that a session id cookie is not passed between http and https protocols, a browser will not pass regular cookies back and forth between http and https protocols either. It is not secure. At the risk of repeating information - If you have something important enough that you are starting a session setting a cookie using a HTTPS connection, you must continue using a HTTPS connection to access that same session cookie data.

Output started at .... line 1 in your file, if you have no actual characters in your file before the <?php tag, usually means your file has been saved as a UTF-8 encoded file and the BOM (Byte Order Mark) characters that your editor placed at the start of the file is the output that is preventing the headers from working. Save your file without the BOM characters or save it as an ANSI encoded file (not a UTF-8 encoded file.)

The name="..." attribute of your file upload field is not the same name you are using in the php code and in fact you are using the same name="..." attribute value for both of the fields in the form. Are you developing and debugging php code on a system with error_reporting set to E_ALL and display_errors set to ON in your master php.ini so that php will help you? You will save a TON of time. You would be getting undefined error messages concerning the non-existent $_FILES variable due to the name mismatch. Also, by specifying the destination filename using a form field, and not validating that piece of information, you are allowing a hacker to upload his file anywhere within your document root folder (by using folder transversal ..\..\..\) and with any file name (i.e. he can replace your index.html or index.php file if he wants.)

Where in your code, before it is being used in the INSERT query, are you setting $newalbumname from the corresponding $_POST variable?

Browsers do NOT pass the session id cookie back and forth (either direction) between HTTP and HTTPS protocols because it is INSECURE to do so. If you have something important enough that you are starting a session using a HTTPS connection, you must continue using a HTTPS connection to access that same session data.

The \ escape characters are NOT inserted into the database. They only exist in the query itself. You should also be using mysql_real_escape_string() instead of addslashes()

Except you don't use the setcooke() function with the session id cookie. Because you can come back to the login page and the session still exists, this is clearly a problem with the session id matching the URL being requested. I hope you are not switching between http and https ?

Despite you statement that you are redirecting non-www to www addresses, you are clearly switching between URL's that have and don't have the www. on them. Unless you set the session cookie domain setting so that it matches all variations of your domain, it will only match the one where the session was created.