Sending large amounts of text through the address bar...alternatives?

[havok118]

Hello all,

I'm learning PHP and MySQL and to practice my skills I am attempting to write my own blog for my website.

Thus far, I can enter entries into the database and delete them, but I am having a good deal of trouble trying to edit a post. Here's how my editing code flows:

I am able to select an entry to edit and display it in a textarea box to be edited by the user. This is no problem. Then, once the user edits the entry, I want to show them the edited post so they can confirm it and finally submit it to the database. I realize I don't need to do this, but it's a learning experience so I am trying to figure it out anyway.

I have a file called display_edit.php
that receives the edited blog post as a POST variable from the form. This file will show the preview to the user to confirm. Now, my question is this: Notice that I send the $edited_blog variable (the edited blog post) in the URL address of the form to send the data to the next php script, which will insert the data into the SQL database.

In IE there seems to be a problem that will not allow you to send this much data (over 1700 characters) on the address bar. It works with Firefox and Netscape fine, but I know that many people still use IE.

Are there alternative methods to sending this type of data (large text 2000+ characters)? Global variables? Resend as form data (how)?

Here is the code for the file display_edit.php, which receives the edited post from a previous page. The point is to display the edited post as it will be seen on the main blog page. This is only the php code, I have other html code around it.

<?php

			$blog_id = clean($blog_id, 4);

			$edited_blog = $HTTP_POST_VARS["blog_edited_post"];
			print '<form method="post" action="submit_edit.php?blog_id=' . $blog_id . '&blog_edited_post=' . $edited_blog . '">';
			$query = "SELECT * from blog_table WHERE blog_id =\"$blog_id\"";

			$result = mysql_query ($query, $connection) or die('I cannot select the table from the database because: ' . mysql_error());

			while($row = mysql_fetch_array($result))
				{

				print "<h4>" . $row["blog_date"] . "</h4>";

				print "<h5><em>" . $row["blog_time"] . "</em></h5>";

				print "<p>" . $edited_blog . "</p>";

				print "<h6>Posted by: " . $row["post_name"] . "</h6>";

				}

			mysql_close($connection);

		?> 

[TheDefender]

Yeah, define it as a hidden input in a form, and POST the form. I can't really show you what I mean, since you only gave this snippet of code, and I am not sure where it would fit into your scheme of things, but something like so...

<FORM method="POST" action="whatever.php>
<input type="hidden" name="blog_id" value="<?php echo $blog_id; ?>">
<input type="hidden" name="edited_blog" value="<?php echo $edited_blog; ?>">
<input type="submit">
</form>

[Weedpacket]

Consider using PHP's [man]session[/man] functions. Then you wouldn't even have to waste bandwidth shuffling stuff back and forth between the server and the client (where it also runs the risk of getting corrupted for some reason).

[havok118]

Thanks for the responses.

TheDefender:

I totally forgot about hidden input forms (d'oh!). That would do the job.

Weedpacket:

I'm still trying to wrap my head around sessions. I understand the basic idea, but I'm missing the basic knowledge about implementation conventions. I know what they do but I don't quite know how to use them correctly and efficiently.

I'll take a look at that link.

Some quick questions though:

This particular page occurs in one session(session A) that I use for the user's login.

Could I perhaps create a new session for this piece of the program and simply register this variable with the session and then pull it out in the next file?

For example, there are three files I am working with this for this piece of the code:

edit_entry.php -> display_edit.php -> submit_edit.php

edit_entry.php posts an edited version of the blog as a textarea variable called "blog_edited_post"

display_edit.php receives this variable

$edited_blog = $HTTP_POST_VARS["blog_edited_post"];

and performs:

session_register($edited_blog);

after starting a new session(I'll call this session 😎.

Is it as simple as restarting session B in the next page(submit_edit.php) and doing:

$edited_blog = $HTTP_SESSION_VARS["edited_blog"];

?

I am a little confused about how sessions access the variables that are specific to them.

[BuzzLY]

Sessions are not complicated.

All you have to do is run session_start() at the top of your page (before any content is sent to the browser).

Then, use $SESSION['foo'] = $foo; to assign your text to the session variable. As long as you are connected to the site, any other page where you need access to that variable simply needs to run session_start(). Then, $SESSION['foo'] will be available to the page.

Make sense? Don't bother with session_register. You don't need it, and it's not as portable.

[havok118]

Okay, $_SESSION["foo"] makes foo a variable for that session. Cool.

The concept of sessions makes sense to me, I just don't have a firm grasp of what should be done as oppposed to what can be done. I'm trying to learn to use the language correctly, not just slap together whatever works.

I'm using session_register because the book I'm learning from (Web Database Applications with PHP and MySQL) uses it in the examples.

What sort of portability issues are there? Is it incompatible with other PHP versions?

[BuzzLY]

If your book is telling your to use session_register, then it is probably telling you that you can access POST variables on the next page as $foo, right? Your book is a little bit old, and is making the assumption that register_globals (in php.ini) is set to off. I recommend getting a [shameless plug]more recent book.[/shameless plug]

Before you ask about register_globals, I recommend you search the forum and/or read the manual. It is a very frequently asked question around here, and you will anger the gods...

Having register_globals on is a security issue. PHP addressed this in 4.2.0 and above by turning it off by default. Having it turned on allows the superglobal variables to be available as global variables in your forms. Click the link above for more information on this. For a list of the superglobal variables, and their functions, read the manual.

The point I'm getting at is that session_register will only register your variable as a global variable if register_globals is turned on. If you use session_register, and you try to port your application to another server with register_globals = off (or upgrade PHP to > 4.2.0), your script will no longer work. The variable $foo that you registered won't be available.

However, regardless of whether or not register_globals is set, your variable is always available through $_SESSION['foo']. On older PHP versions (< 4.1.0), it's accessed through $HTTP_SESSION_VARS['foo'].

As a beginning PHP user, this is an important concept to wrap your head around. Make sure you understand about this, because it will really make your future lessons that much easier (when you get into $POST, $GET, and $_COOKIE).

Clear as mud yet? 🙂

[havok118]

Much clearer.

I've actually seen quite a few posts related to regsiter_globals, so I was aware of the controversy. I didn't know that session_register was dependent upon that being set to on.

How do the two methods work differently? If session_register simply registers a global variable, how is $_SESSION['foo'] different, other than being an array?

As for my book, I'm being very frugal at the moment so I'm using those resources that are available in my library (a.k.a. free). When I get some money I will definitely purchase a newer book.

If your book is telling your to use session_register, then it is probably telling you that you can access POST variables on the next page as $foo, right?

If you mean that after using session_register("foo"); it allows me to use $foo to access that variable?

If I understand you correctly, that's not what this book is doing. After registering a variable, it grabs it from $HTTP_SESSION_VARS.

ie:

$foo = $HTTP_SESSION_VARS["foo"];

[BuzzLY]

There is quite a bit of information about global variables in the manual. I recommend you get familiar with these pages:

[man]session_register[/man]
Predefined Variables
Using Register Globals

The great thing is, this "book" is free, too! Just click the links 🙂

I'm not trying to be a jerk and tell you to RTFM. I know sessions can be confusing if you have never dealt with them before. Let me see if I can explain them for you. But before asking many more questions, do try to read those pages I linked for you above -- there is a lot of useful information.

---

Let's assume you have register_globals set to ON in your php.ini file. You create a page, and it takes a variable foo passed through the query_string like so:

http://www.yourserver.com/coolsite/mypage.php?foo=bar

Your file, mypage.php, will have access to the global variable $foo. It's value will be "bar." With me so far? No, this has nothing to do with sessions yet. Bear with me here.

The reason $foo is available is because the PHP server automatically registered the variables in your query string (called GET variables). I won't go into the problems this can cause, but it is a security risk (read the links above!).

The important point to note here is that PHP must store that $foo value somewhere. It does, in a special array called $GET. $GET contains all of the variables passed in through the query string (through the GET method). So, because it's been automatically registered, it is available as $foo. It is always available as $_GET['foo'], regardless of the setting of register_globals.

With me still? Hopefully you know this stuff already. If so, then you also know that this applies to POST variables as well, passed from another form via the POST method. Those variables are always available from $_POST.

These special arrays are called superglobals. There are others -- $ENV, $SERVER, $COOKIE, and (drumroll please) $SESSION!

The thing you must remember is that $foo and $_GET['foo'] point to the same data: "bar." They are not two different things, but simply two different methods of accessing the information. Yet another way is $HTTP_GET_VARS['foo'].

The same applies to $SESSION. When you use session_register("foo"), you are telling the server "please make the $SESSION['foo'] variable available as "$foo." There is no need to do this, when all you can (and SHOULD) do is simply access the data through $_SESSION['foo'].

The old way to access the session variable "foo" was to use $HTTP_SESSION_VARS['foo']. That was not set automatically, however, and required you to use session_register. $HTTP???VARS variables are now deprecated (no longer used or supported), and so is session_register.

So, regardless of whether or not you have register_globals set, if you put a value in a session variable, it will always be available through the $SESSION variable. All you have to do to use $SESSION is tell PHP "I want to access session variables on this page." You do that with session_start().

To sum it up, and answer your question, there is no difference between the two methods of accessing the session variable, except for one: $foo will not be available if register_globals = OFF, which is the recommended setting for your PHP server.

[havok118]

Once again, thanks for all the help.

I understand that passing through the query string is a security risk, that's part of the reason I asked in the first place.

I also understand how the GET and POST variables work. I was just unclear on the specifics, which you cleared up.

Things have started to crystalize a little more in my head now, and I have my original problem (and quite a few others) worked out now.

Thanks to everyone for all the help.

And yes, I'll read the damn manual. 😃

[BuzzLY]

Just to clarify... there is not a problem with passing variables through the query string. The problem comes in how you access those variables from your page. If you code your page correctly, you shouldn't have any security problems.

[Weedpacket]

Originally posted by BuzzLY
I know sessions can be confusing if you have never dealt with them before.

This is especially true in PHP, precisely because of the changes from PHP3 to PHP4, and PHP4 to PHP4.1; the manual still has to support those older versions and so ends up describing three different things - sometimes it's not too clear which one applies to you.

[havok118]

Originally posted by BuzzLY
Just to clarify... there is not a problem with passing variables through the query string. The problem comes in how you access those variables from your page. If you code your page correctly, you shouldn't have any security problems.

Right, meaning I should be performing error checking on variables that I GET from the query line.

And earlier I said that my book didn't access global variables as $foo. I took a look at one of the first pages I coded and there were a few globals being accessed in that way, which I changed to be accessed with $_SESSION. These books should come with a warning: DO NOT TRUST CONTENT AFTER TWO YEARS. :queasy:

Thanks again for the help!

[TheDefender]

Shoot, the way things change so fast around here, the book should warn you with:

"Warninig, contents are probably outdated the first week after press. Consult the gurus at phpbuilder.com for the latest and greatest way to REALLY do these things!"
LOL 😃