Jump to content

Doubt regarding form submission


rocky_88

Recommended Posts

I'm not sure if this is exactly a coding help question, excuse me if its not.

 

I want to know what is the best & secure way to submit a form to itself.

I've tried to google the answer, but did not get a proper answer with explanation or may be I didnt use proper keywords to search it.

 

Out of these which one do i use?

 

// Leave the action field empty.

<form method="POST" action="">

//$PHP_SELF, also if i use echo $PHP_SELF my form does not work like it should.

<form method="POST" action="<?$PHP_SELF?>">

//$_SERVER['PHP_SELF'], same problem as $PHP_SELF, it doesnt work if i use echo.
<form method="POST" action="<?$_SERVER['PHP_SELF']?>">

Link to comment
Share on other sites

@JKG

 

Thank you for replying,

if I echo $_SERVER['PHP_SELF']; I get an error when i submit my form.

If I do not echo it or remove the action attribute, it works just fine.

 

As i've read, $_SERVER['PHP_SELF'] gets the current file name and then we echo it into the action.

But I do not want that as I can manually type the file name into the action field.

The URL of my page contains the file name followed by a variable with value. Using that variable value from the URL my page displays data onto the page. So as soon as I submit the form, the variable from the URL is removed(replaced by the file name ONLY) which causes the error.This is the reason i get an error if I echo $_SERVER['PHP_SELF'];

 

So I wanted to know if it is safe to exclude the action attribute of the form? Is it the right way of doing it in my case?

Link to comment
Share on other sites

oh i see.

what is your url, you might want to use request_uri if you are using modrewrite or url parameters.

 

leaving the action blank just uses current page, i dont think there is anything wrong with that particularly, but i always prefer to define the action script/page.

Link to comment
Share on other sites

@JKG

 

Well i have a table which contains 4 fields. Id, username, name & age.

On the web page the id value is appended to the link which opens a new page containing user details.

I'm using that id from the link to display data onto the new page.

But it looks like I am logically wrong somewhere as i'm getting too many errors.

 

Leaving form action empty doesnt cause any security issue right?

Like vulnerability to XSS in the case of $_SERVER['PHP_SELF'];?

Link to comment
Share on other sites

@fugix

 

Thank you for replying,

So is it ideal to set the form action="#" if the form has to be submitted onto the same page regardless of my case here?

Coz all my form submit onto the same page before navigating to another.

Link to comment
Share on other sites

I usually use the actual file name in the action attribute. So if the form page is called "myform.php", I'll use action="myform.php".

 

I've heard there are security issues with setting the action tag to be blank or "#", but I haven't seen anything on what those security risks are. I suppose it has something to do with the GET variables being included in the action attribute.

 

In other words, if you call the form as:

www.mywebsite.com/myform.php?id=1

 

The action attribute would be set to:

action="myform.php?id=1"

 

If register globals is turned on, there could be an issue with GET data interfering with POST data.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.