Jump to content

Recommended Posts

well you want to make sure when registering someone usually that the information isn't conflicting with information in the database. This is generally done with unique identifiers of the account (username, or email address for example). You would simply check to make sure there isn't a row with username (or email, or whatever) equal to the username entered in the post data before inserting into the database. This has the added benefit of refusing someone from registering if they use a taken username.

Post data. Your forms should almost always be post data.

 

Not true. Having posts send GET data instead of POST data is just as valid. POST has some added benefits that makes it common with forms, but saying forms should always send POST data is incorrect

Post data. Your forms should almost always be post data.

 

Not true. Having posts send GET data instead of POST data is just as valid. POST has some added benefits that makes it common with forms, but saying forms should always send POST data is incorrect

 

I said almost always. And for the purpose of a person registering, that should be POST not GET. Post is just more secure than get.

As well as mikesta707's suggestion, you should force a redirect back to the same URL. This will effectively remove the previous POST request from the history, and replace it with the new one.

 

Post is just more secure than get.

 

It isn't any more secure at all, it's just hidden from sight. No user input should be considered "secure" until you secure it yourself. The reason POST is used instead of GET, is because that is what it was designed for. Look into the REST architecture.

Post data. Your forms should almost always be post data.

 

Not true. Having posts send GET data instead of POST data is just as valid. POST has some added benefits that makes it common with forms, but saying forms should always send POST data is incorrect

 

Websites should be semantic and RESTful.  According to the HTTP spec, GET is for retrieving data, while POST is for updating data*.  Forms can be used for both actions, so the proper method to use is based on the intent of the form - is it sending field values to the server in order to retrieve more data based on what's contained in those fields, or is it trying to update the back end data with the values of the fields?  Use GET for the former, POST for the latter.

 

I said almost always. And for the purpose of a person registering, that should be POST not GET. Post is just more secure than get.

 

Wrong.  POST has two advantages over GET:

 

1. It cannot be manipulated by what's in the browser's address bar.

2. It can send more data.

 

Advantage 1 isn't much of an advantage at all.  There's nothing stopping anyone with bad intent from making their own form and posting it to your form handler.  There's no inherent security built into POST.  Thinking you're safe for using it is wrong.

 

EDIT: Technically, POST is used for creating data, while PUT is used for updating.  However, since hardly any popular language/framework exposes/uses PUT naturally, both creating and updating is relegated to POST.

Basically it's a registration form. Usually, I would do checks for the same email/username/IP address, but in this case people can register with the same username/email/IP address.. i.e. have multiple accounts.. which is why it's proving to be more confusing and finding a good method is more difficult. Once the form has been submitted to register.php, I do redirect with a header() statement, however I managed to someone resubmit the form when testing and so I wanted to find a way to avoid this...

I'm fully aware of all the benefits of POST. I don't know why I only listed one, and yes "Safer" is one since less users will manipulate post data then data in the URL.

 

Basically it's a registration form. Usually, I would do checks for the same email/username/IP address, but in this case people can register with the same username/email/IP address.. i.e. have multiple accounts.. which is why it's proving to be more confusing and finding a good method is more difficult. Once the form has been submitted to register.php, I do redirect with a header() statement, however I managed to someone resubmit the form when testing and so I wanted to find a way to avoid this...

 

If you're allowing the same username then of course someone can register with testing more than once. You're not being very clear. Perhaps you want a unique Id for each user? Then consider `userid`, make sure it auto increments. As for "Resubmitting the form". Do you mean you only want one person to register once? Again, you're unclear.

Okay, I'll pinpoint what I want.

 

I am allowing users to register multiple times with the same usernames etc. I already have the userid that auto increments. HOWEVER, I DO NOT want to allow the user to register multiple accounts very quickly. For example, I don't want it so that if they press submit and then do it again and again and again in quick succession. I want some method of stopping them from re-registering for say an hour.

 

As for the resubmitting. When I submitted the form, it hovered on register.php for a while before redirecting. I managed to stop the page on register.php and then kept refreshing the page and with each refresh a repeat account was generated. I was hoping there would be a similar way to stop this quick repeat registration.

 

 

Also, on a slight side note, how can I 'timeout' user sessions? Which method would you recommend as I have read a few..

If users can have multiple accounts under the same username, I would consider rethinking the schema to remove the duplication. This would then allow you to add the unique constraint and prevent any accidental resubmissions. Out of curiosity, are you able to reproduce the problem? If so how is it happening? I've never experienced this problem before.

 

I'm fully aware of all the benefits of POST. I don't know why I only listed one, and yes "Safer" is one since less users will manipulate post data then data in the URL.

 

You have to consider the person who would try to manipulate the data; they're going to have a clue about what they're doing.

I am allowing users to register multiple times with the same usernames etc. I already have the userid that auto increments. HOWEVER, I DO NOT want to allow the user to register multiple accounts very quickly. For example, I don't want it so that if they press submit and then do it again and again and again in quick succession. I want some method of stopping them from re-registering for say an hour.

 

Create a column that stores the datetime the user registered an account. As they create another, validate it's not within an hour based on when they registered the previous account.

 

----

 

Going back to my last post, that wouldn't solve the issue I wasn't thinking straight!

Hmm, well it's just happened once where the page has hovered before getting to it's final destination. It's not MAJOR but it worries me a little as there is the potential there to refresh the page and create another account. It's making it quite difficult to find a method.

 

Could I potentially set some sort of session variable in the form and then unset this as the FIRST thing when the form is submitted? Then if the form is refreshed on a page, I could check for this session var and it won't exist.

You have to consider the person who would try to manipulate the data; they're going to have a clue about what they're doing.

 

That's just false. There's many more scripts kiddies and wannabe hackers than actual ones. I have a much bigger problem of people trying to exploit url variables than I've ever had people trying to exploit post data. This is purely my own expierence, though.

 

HOWEVER, I DO NOT want to allow the user to register multiple accounts very quickly. For example, I don't want it so that if they press submit and then do it again and again and again in quick succession. I want some method of stopping them from re-registering for say an hour.

 

Do you have sessions set up? I'd suggest a mixture of sessions and IP-address logging to prevent people from registering. For example, on each registration store an IP and dateline. When a user registers, grab all the registrations made in the past hour and check their IP-address against the stored one their. You actually may not want to use sessions, since a session can be changed just by closing the browser while the IP-address takes a bit more than that to change. Keep in mind, people WILL be able to bypass this.

 

As for the resubmitting. When I submitted the form, it hovered on register.php for a while before redirecting. I managed to stop the page on register.php and then kept refreshing the page and with each refresh a repeat account was generated.

How are you submitting the data? Through the url? If so, switch to post, that should solve the problem. The check above should also stop this.

 

 

http://prajapatinilesh.wordpress.com/2009/01/14/manually-set-php-session-timeout-php-session/

For setting sessions.

Yeah that's why i'm looking at alternate methods.

 

Okay another question, sorry for so many! I'm doing a check on IP addresses and previous join time of a user. I have stored the times using time() as a timestamp. Now how can I compare two timestamp values? I mean what number would I check for if I was look for a 2 minutes difference or 10 minutes difference etc?

Yeah that's why i'm looking at alternate methods.

 

Okay another question, sorry for so many! I'm doing a check on IP addresses and previous join time of a user. I have stored the times using time() as a timestamp. Now how can I compare two timestamp values? I mean what number would I check for if I was look for a 2 minutes difference or 10 minutes difference etc?

 

Simply math here. A unix timestamp, which is what time() returns, is simply the number of seconds since January 1st 1970. So 2 minutes would be 120 seconds, and 10 minutes would be 600 seconds.

 

http://php.net/manual/en/function.strtotime.php

 

Is also useful. But if you're doing it by such small time periods, it would be better just to input the number of seconds as an integer.

I'm having issues with the timestamp. It seems to change very quickly and by thousands even though the value entered in the database is completely different. For example, the timestamp entered into the database is 1315754757 but within seconds when I check it on the next page it is 1315827008.

 

I am not altering the values at all, just using time().

 

Could it be my database structure? :s

I'm having issues with the timestamp. It seems to change very quickly and by thousands even though the value entered in the database is completely different. For example, the timestamp entered into the database is 1315754757 but within seconds when I check it on the next page it is 1315827008.

 

I am not altering the values at all, just using time().

 

Could it be my database structure? :s

 

the time in your database is changing frequently?

will be hard to diagnose without seeing your code

Always that, it's going to be difficult to show you the code as there is stuff spread across a number of files. The time in my database isn't but i'll try explaining it as best as I can.

 

A user registers and I use time() to store the time they register at in the database. On the following page (which the form submits to) I want to check the current time with the time the user registered at for security. However, when I use time() again on this page, it's suddenly much further along than the value stored in the database just a couple of seconds ago! The time is stored in the database with a INT datatype and length of 20, nothing else is set for it.

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.