I have a classifieds website where users may insert ads.
There is a insert-ad section (PHP based).
In the insert section, firstly users enter specified data and fill in all fields of the form, then they click the "Preview Ad" and the ad is previewed.
The preview page is another php page which puts all the form fields from the first 'put ad' page into hidden fields.
Then if the user is happy with the preview, he or she may click the "OK" and the ad is inserted.
Now, this method of putting form data into hidden fields before acutally inserting the ad seems 'too much'. What do you think, should I use sessions?
I am looking for stability, not performance in this case!
Thanks and if you need more input, just let me know!
The sessions may flow from one browser window to another, i.e. this way you will force the user to use a single browser window at a time (cannot design multiple ads at once).
In this case, you should stick to POST variables and not use session data.
i also agree with Tatu - if something is working now, no need to rewrite it. but if you are just starting on this: sessions are more flexible (also eliminates "Page Has Expired" errors because you can redirect, and can detect duplicate submits).
dealing with multiple windows and tabs is easy: store the form data with a unique id ($id = uniqid('', true)) and pass the id through the form. this makes it easy to add steps and is more secure - the post data can't be tampered with making validation simpler.
you can have an ajax control that previews the ad, so you wouldn't be submitting the form until it's complete, but that's up to your design.
It it isn't broken, dont fix it.
That seems fine to me. If you were to put the data into a session, then you could arguably avoid the overhead of sending it back down to the browser, but on the other hand, you'd need to deal with the possibility of multiple tabs having different ad submissions within the same session. Not particularly difficult either, but a bit more work.
Related
I'm looking for a way to create a page with items on it where each item has a button which can be clicked to "like" or "choose" the item. The website would then remember the choices and input them to a form on another page. Is there anyway of doing this?
At first glance if we are talking about a registered user, i would create fields in the database for the user's input and store its value everytime he makes a selection. Then its only a matter of putting those values wherever you want.
You have several choices. If it is persistent data, I'd suggest a database like MySQL. If you don't have access to that, then Google for "flat file database" and you'll find some great ideas.
If the data is persistent, but not a big deal if it gets deleted or spoofed, you can use cookies.
If the data is fleeting (it goes away at the end of the visit), then use sessions.
The best way to do is storing each result in a SESSION and reusing it in other form.
I am helping to make a website in PHP which is an ERP purpose website. We made mockups of a form to collect user details which is split into 4 screens facebook style where the end user keeps clicking next after filling in each partial form. Finally they get the preview and confirmation receipt is generated.
How should I go about this in the backend, I am sure that after the preview I will write the values to the Mysql db and generate a receipt. My question is how do I go about storing the values before the preview?
you can use php sessions to store the variables in a session and then at the end store them all in the database.
http://php.net/manual/en/features.sessions.php
You cannot really answer your question in isolation. It really depends on how your user is going to use the system, whether the information they enter should be persistent, and even whether you know who the user is?
Assuming you know who the user is, and you want to keep failed sessions, my suggestion would be to store the partial responses in a database so you can always access them later.
You can then populate or re-populate the form as you wish. You should also have a "start again" button in this scenario.
More information would help give a better answer.
You can just have one form per screen/page and send these values as parameters to the next page via post or get - it's the most simple way
It is also possible to keep all the form markup on single page and divide form into steps using formToWizard jquery plugin.
http://www.jankoatwarpspeed.com/post/2009/09/28/webform-wizard-jquery.aspx
This way user has all data available when users clicks and back and forth during the steps and you can just have single submit button.
For a system I'm working on I've got a bit of a problem: I'm messing with one of the basic rules of HTTP and I'm allowing users to post data through a GET request.
Don't get mad at me yet: I've got a reason for this: Users arrive in my application from an external environment and I can't prompt them for any extra input (so all necessary data is in the GET query). They should be able to close the browser window right after it opens and the input should be saved. And no, I can't do this through AJAX, an API or other under-the-hood method.
These requirements kind of rule out captcha, calculations, forms etc. So I'm left with the problem that I really do want some type of verification to prevent bots/crawlers from "accidentally" submitting something.
One of the solutions I am looking into is making a very lightweight landing page that submits itself through javascript onload but it would be the ugliest thing in my application so I'm trying to prevent it. Another is to let the landingpage not do any of the processing but instead use an AJAX-call to do this. This would however mean that older browsers (and many mobile phones) would have to use another solution.
Background: Application written in PHP5.3, built on Yii Framework, 100% cross-browser compatible (this includes pretty much every mobile phone out there).
Some more background: The "exteral environments" I'm talking about vary from e-mail clients to websites. Manipulation of our content at runtime isn't possible.
Update: Here's what I'm going to do: I'm probably going to combine solutions posted here in a fallback mechanism so that a chain of verifications will be attempted:
1. Ajax verification
2. Non-Ajax javascript verification (automatic form submission)
3. Prompt for user input (user has to click a confirm button)
Besides this I'm going to implement a bot trap as descripbed by http://www.kloth.net/internet/bottrap.php
After I'm done with building this I'll update the post if I did anything different.
Hard to understand where you app is and where external environment really are. But one simple bot-removal technique I use is to put an hidden field named 'login' or 'name' and give it an empty value.
Human people will never fill this hidden field, but spam bots are always filling it. So you can discard any request with that field being not empty.
Now you must prevent crawlers and not only spam bots. Never did it, but here are some thoughts. You could add a hidden 'human' hidden input in the form on first mouseMove events (but keyboard-only -- and think about blind people -- users will be considered as robots). So maybe if this field is not there you can launch a javascript 'confirm' where you ask "Confirm that you are a robot or click cancel if you are human".
You can make your anchor link containing a default value that this hidden field values will overwrite in js. Most crawlers will not overwrite the values, especially if you must cancel a confirmation to get the right behavior (and avoid confirmation with mouseMove event for most users).
If you are able to modify the place that your users are coming fro, you could try including a checksum. Calculate some kind of checksum or hash of all the fields in the GET request and add it to the GET request itself (i.e. through javascript, but do it in the place your users are coming from, not where they are landing). Then, in your application, reject all hits with an incorrect checksum.
Hey guys, I have a form with 3 fields 1 input, 1 select and 1 textarea. Is there a way to store the information as they type?
The reason why I need this is because if you are not logged in the submit button will take you to a fancybox with another login form or a signup one. So of course if the user logs in the page is refreshing and they loose the text they inputed.
Thanks.
You can totally use YUI's Storage module, it'll hold everything in 1) HTML5 memory, 2) SWf memory 3) Google Gears memory 4) ysql or something, so I read.
I've tested HTML5 mem and Swfstore, both ace.
Edit: Here's an excellent YUI Storage example, it counts every 5 keystrokes, perhaps you'd call the same save method when focus leaves the form handles you're working with.
AJAX could do this, though you are probably better off passing the contents of the inputs in POST and retrieving them if the page is reloaded as a postback from the login page.
There is no trivial solution to this problem. The simplest way to overcome would be asking login screen before asking for user input.
YUI storage module answer is a great option. Otherwise, you're going to have to change the behaviour of the authentication logic which automatically redirects you to the login page. You would have to store the posted values in some temporary server-side location, and re-post those values after the user logs in.
Another option would be to authenticate the user via a dynamic HTML login form and Ajax before actually submitting the form. Either way it changes the authentication logic of your application a lot.
Actually, I think the root of the problem is that you're presenting the user with a form which requires authentication to use before they are authenticated. I think you should either force the user to authenticate before presenting them with the form, or don't require authentication for posting the form (which probably isn't a good idea).
The most straight forward and simplest way that first comes to mind:
Store the information in a cookie - first thing when they hit submit so you have what they typed at any time, logged in - out - hour later, maybe even next time they visit etc.
If you can't use a cookie, maybe save it to the database in a temp table of some sort, relative to a specific session or anonymous user....
as you mention i think you can use simple SESSION variables for all your fields OR you can use AJAX.where you can popup one light-box at the same page and then login and process further you want.
Thanks.
I want to allow users as well as me(the admin) to delete data in mysql.
I used to have remove.php that would get $_GETs from whatever that needed to be deleted such as... remove.php?action=post&posting_id=2. But I learned that anyone can simply abuse it and delete all my data.
So what's the safest way for users and me to delete information without getting all crazy and hard? I am only a beginner :)
I'm not sure if I can use POSTs because there is no forms and the data isn't changing.
Is sessions good? Or would there be too many with postings, user information, comments, etc.
Ex: James wants to delete one of his postings(it is posting_id=5). So he clicks the remove link and that takes him to remove.php?action=post&posting_id=5.
EDIT: Alright, so now I am a little confused. While I can't be 100% secure, how do I do this with $_POSTs?
SOO I should use GETs to get all the data to remove.php, THEN have a confirmation submit button and when users click on it, it put all the data into POSTs and delete from the dbc?
Deleting records is a kind of a scary practice. If you or someone makes a mistake there's no real recourse to resolve the issue. Expunged records are very hard to resurrect.
Instead of deleting records, you could add an "active" bit (e.g. Boolean) column that is toggled off when users "delete" records. Essentially your users would be suspending records by toggling them off and the records would be saved in case mistakes or abuse but appear "deleted" to the user. To make this work with your other queries, just add a where clause of active = 1.
You could then have a utility script that's run at some specific date interval that would clean out deprecated, past dated records. You'd also need some type of timestamp for this type of maintenance.
Just a thought. Take if for what it's worth.
I'll echo gurun8 in preferring to 'mark' records as deleted, instead of actually removing data. And then obviously, you'll need to check that the authenticated user has permission to delete the post.
However, it seems very important to mention that $_GET is not safe even with authentication because of cross-site request forgery.
Imagine if Amazon adding things to your cart based on a GET request. All I'd have to do is put an image on my page with that URL, and everyone who visited that page and logged into Amazon will have products added automatically.
To match your example, I don't like Jame's post, so i put an image on my site like this:
<img src='http://example.com/remove.php?action=post&posting_id=5'>
And I send him a link to my page, and ask him to check it out, hoping that at the time he's logged in to your site. Because, of course, he clicked that little 'keep me logged in' button.
So you are right to be concerned about using GET. If you don't want to litter pages with forms, then confirm the action by POST.
Well you have to start by authenticating the users with a login script.
If you want the simplest solution possible, then I'd suggest protecting the directory in which you have remove.php with a simple .htaccess username and password.
If different users have different rights for deleting database entries, then you probably should create a PHP login script and use PHP session.
Bonk me if I'm stupid, but I searched for quite some time for a simple PHP login tutorial that could be placed on a real site (doesn't use session_register(), uses mysql_real_escape_string(), htmlspecialchars() etc) and I simply couldn't find one!
Probably this one comes the closest, you just have to replace session_register() variables with $_SESSION ones for it to work without register_globals (default in PHP5).