Another thing: when the form fields are edited and the page is refreshed, the form is not filled in again (the top form).
Thanks for pointing out the stray characters. I saw them and removed them.
When the page is first accessed, the $cvid is successfully carried over, for the number is echoed correctly next to the Submit button:
<?php echo $cvid; ?>
<input type="hidden" name="cvid" value="<?php echo $cvid; ?>" />
<input type="submit" value="Submit Changes" /></p>
</form>
The fields are correctly filled in for editing. But making the changes to the fields returns NULL for $cvid when the Submit button is pressed and the page is refreshed, and I get the notice of the undefined var cvid. Currently, I have:
if(isset($_GET['cvid'])) {
$cvid = $_GET['cvid'];
$cvid = mysql_real_escape_string($cvid); }
var_dump($cvid);
$cover_tiers = @mysql_query("SELECT mag_name, mag_month, mag_year
FROM cover_tiers
WHERE id='$cvid'
");
Also, I had overlooked an error at the top of the page:
if (isset($_POST[‘mag_issue’]))
mag_issue should be named mag_name, since I had made a change to the table, and I forgot to update the page at that location. Even with this fix, the page is not updating the table.
In summary:
The cvid is correctly carried over the first time. When changes are made to the fields, that’s when the cvid is undefined.
Thanks,
Steve
Top form? There is only one form in that script, have you tried yet changing the occurennce in the script of $_GET to $_POST ?
By “top form” I really meant the table’s vars at top. Those are not filled in.
Changing the GET to POST has the effect of not showing the fields filled in when first accessed, whereas GET shows the fields filled in from the beginning. In both cases, I get the undefined var notice.
I had encountered the similar problem once and then i used $_REQUEST instead of $_GET and it really worked for me.
The first time the form is loaded, you pull cvid from query string. Upon submission, you are passing cvid as a hidden form variable. So upon submission you should expect cvid to be present in $_POST.
It is possible for you to be consistent by retrieving cvid from $_GET['cvid] regardless of whether your page was accessed via the GET or POST method:
<!-- For pages that contain a link to the edit page -->
<a href="cv-edit-page.php?cvid=<?php echo $cvid; ?>"></a>
<!-- On the cv edit page itself -->
<form action="<?php echo $_SERVER['PHP_SELF']; ?>?cvid=<?php echo $cvid; ?>" method="post">
.
.
.
</form>
I hope this makes sense.
OR add this to your page
if (isset $_POST['cvid']) {
$_GET['cvid'] = $_POST['cvid']
}
Now I’m confused because now we’re talking about he cvid in the form not being carried over and the thread started by talking about the cvid in a hyperlink not being carried over.
Can someone please clarify which of the two we’re now looking at? (Sorry been busy last few days).
Back in post 21, Stevenhu said that the value was correctly carried over in the URL the first time, but subsequent times he was getting errors.
The first time the data is passed as a GET, but all times following that the data is passed as a hidden field in a form whoch is set to POST.
<form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="post">
.....
.....
<input type="hidden" name="cvid" value="<?php echo $cvid; ?>" />
.....
.....
</form>
Ok, I saw him say its carried over the first time but didn’t realise that translated to the form although looking at the source again that does make sense.
This is why I always combine my _GET and _POST arrays into one array (similar to _REQUEST but without cookies) so I can access things without worry as to how they’ve been submitted.
I do this in my scripts - makes life much easier:
$_HTTP = $_GET + $_POST;
This is a security flaw, in the same way that register_globals is. You should ALWAYS know where your variables are coming from when you use them.
That may be so but it works. Additionally any attacker would have to know about it anyway and then on top of that if you know it could be coming from either place and you know that data needs processing anyway you’re still going to be accessing it directly by its key anyway.
Its still safer than $_REQUEST.
register_globals ‘works’ and has all those other conditions, doesn’t stop it being a security flaw.
Register globals is not the same thing and while I see what you’re saying (IE values could be sent by $_GET for a post form) as long as the processing script is crafted to do a good job and assess the submitted values then it works well.
I never allow input of anything which could be attacked anyway - IE prices. Anything like that is linked by its index in the database and then the rest of the info pulled from the DB when the form is submitted. I don’t allow opportunity for anyone to alter things via a form.
That’s what you may think, but I can think of at least one attack where your site could be compromised because of this.
In any case, it’s just bad practice.
If thats the case please PM me with those attack details and I’ll reconsider the approach.
Having been PM’d by Stormrider he has indeed pointed out a way in which my technique could potentially be abused if you’re not prepared for it and how an attacker could in fact fool someone else into becoming the attacker and thus hiding the original attackers own IP.
While I do stand by my method for my own use (it works well in my system which was designed to intentionally accept input from both $_GET and $_POST) this may not be the case for everyone. I therefore recommend that unless you are familiar with checking submitted data thoroughly and defending against attacks, you only use my technique for testing and debugging purposes and THEN change to $_GET and $_POST where appropriate.
There is technically nothing wrong with my method as it is slightly safer than PHPs own $_REQUEST which combines get, post and cookies but if you do use it use it with the same caution that you would use $_REQUEST.
By default, $_REQUEST no longer includes cookies, but I still maintain you shouldn’t use that either.
It doesn’t? - So its what… just $_POST and $_GET now? - I give up lol.
Rather than fight it, embrace it. Allow the context to have meaning. In my system $_GET[‘save’] retrieves a form. $_POST[‘save’] commits the form.
Get and Post are supposed to have two VERY different purposes. Get is for read operations. Browsers are expected to cache the results of pages fetched with get.
Post is for write operations. Browsers are not supposed to cache a page delivered as part of a post and warn the user if they attempt to refresh the page.
This system was devised by people quite a bit smarter than you or I tango - it would be prudent to pay attention to it, come to an understanding of why it is the way it is and use it the way it was intended.