I have a classifieds website, where anyone (no need for login currently) can post a classified. It is PHP based.
The procedure for posting is currently like this:
click on "New Classified" --->
fill in a form of all information and hit "View classified before publishing it" --->
the form submits to a "verify classifieds" page, where users verify their inputs --->
If everything is okay in the "verify" page, then the user hits OK and the classified is published.
The above procedure isn't exactly optimized. The first page (new_classified) where the form is, is pretty good, but the second page (verify) uses x number of hidden inputs in another form, used to contain the previous pages form inputs.
Now you know how it works on my site.
The issue today is that alot of companies want to publish their classifieds, and alot of classifieds at the same time. This means they have to fill out the form again and again currently.
I am thinking about creating a login, for companies only, so that their information is automatically inputted into the form, so all they would have to do is fill out the specific classified details like "headline" and "description" etc.
How should I do this in my case? Sessions?
This means I will have to create a new MySql table (I use MySql mainly) and store company-profiles there.
So do you think converting to sessions is alot of work? Worth it? More reliable?
I have never used sessions so I wouldn't know.
As a last note, you should know that I use a picture upload tool on the first page of "new_classified". When a user choses a file to upload, the page is automatically *refreshed*, and then the image is displayed on the same page under section "images uploaded". I hope the session wont interfere with this approach.
Thanks
I think it is worth your while to do logins, and even on a very basic level it will help you to identify who is using your site etc.
This is probably a big debate around developers, what is the best way to do a good login system, whether it's basic or not doesn't matter, I think the concepts still stay the same.
In your case I would suggest session cookies along with a login table consisting of user details. This would help you to verify the user on more than one occasion during his/her visit to the site.
A login is checked against a user entry in a table and then a session cookie is created. This session you can choose to never expire also.
You can then on every step check that the user is the user that is supposed to be logged in and get the companies details by checking the username. This would make for a better query in my opinion.
Sessions aren't a lot of work and it's relatively easy to learn.
http://www.php.net/manual/en/book.session.php
http://www.9lessons.info/2010/02/php-login-script-with-encryption.html is a good example of what you can do with this. Have a look around still. There are a bunch of these great tutorials on the web.
Related
I am looking to create a setup for my website that a webmaster can complete to setup the required features of the webserver, such as the database, an administrator account, etc.
What I have planned so far is a $_GET variable will automatically be assigned (if not already!) to the user, the $_GET variable will be called something such as $_GET['step'] to represent what step the user is on. This will also allow me to easily display the specific form(s) for that specific step. For example, display the 'Database Setup' form on step 1, but then on step 2 display the 'Create an Administrator' form. I would do this by using switch statements.
However, if there was an error with the information that the user has given, such as a connection cannot be established with the given information, how would I check the information that was inputted and then display an error to the user, forcing them to change the information in the form, if they have been redirected to step 2 when they submitted the form?
Thanks,
Kieron
EDIT: Here is a Pastebin link to what I have so far: http://pastebin.com/Y6YSTrgR
I couldn't put it directly in this post as it wasn't formatting properly.
You've not shared enough technical detail for this question to be helpful, however if I understand you correctly then you could save each step into the session so that you can go back if necessary. This way you could persist the data if the user finishes the last step. If the user doesn't finish the last step, nothing has changed on the server.
Really you need to tell us more about the system, such as which framework you're using (if any) and describe more about how the overall process should work.
This is what I am trying to implement and I don't know how to do it:
I have a few forms that users should be able to complete offline. Once the user has filled in the form they should be able to hit save and their data needs to be saved offline. Then later when they are online they can submit all the form data which was saved by hitting a button. They will be asked to log in and once they have done so their data will be saved on server.
These forms will be submitted via iPad/iPhone. The user can save multiple copies of each form.
I am looking for an HTML5/JavaScript/jQuery solution. My backend is php. I have not tried anything yet as I don't have any idea how to do this. Where do I start?
Thanks
You can provide a manifest file to provide a specific form to a user - Application cache IIRC:
http://dev.w3.org/html5/spec/offline.html
Caveat - without making it a native app the user would have to have visited the website while online before they will see any forms at all
Then once the user fills this in store the results in localStorage, ready to access when online.
If the user is online, the standard page will be displayed, and you can check local Storage for any unsubmitted forms, and on submission remove from localSorage.
Check out the principles used in this tutorial, they should get you most of the way there, but you'll have to look into offline html and localStorage a lot more to get a working app:
http://sixrevisions.com/web-development/html5-iphone-app/
Hope that helps.
I don't think this is possible as an web-only solution targeting iOS, since you can't count on the forms staying up in Safari. Even if the user loaded the form in their browser ahead of time when they had an active internet connection, you can't count on Safari not trying to reload the page (which would clear the page and give a connection failure since they're offline).
Therefore, I think you have to create a native iOS app for this functionality.
If you were targeting desktops instead, you could probably accomplish this with browser plugins.
I need to build a registration system which requires the collection of large data (many fields) from the user registering which is then inserted into a couple of tables in a database.
I don't really want to display a very long form to the user for the purposes of better UX.
This system will not run online, it is just a web app to run on the desktop.
I need help, pointers, references, etc on how I can better organize the registration process to make it more user friendly.
This How to encourage a user to fill in long application forms? has been helpful so far
As long as you don't mind requiring your user has Javascript, I would use AJAX. Let's say that you have 50 fields that you can logically combine into 4 different sets - the first may be about the person asking for name, email, etc., while the next set asks for historical information or employment information - like on an application.
Make one form for each set, and then present a new user with the first. When he completes the first page, instead of a "Submit" or "Register" button, use an AJAX call and a "Next" button to get the info and switch to the next page of the form with the next set of fields. You could use the AJAX calls to hold the information in a temp table in your database, and then, once the entire process is complete, you can write it to your member/users table.
You could do like other surveys or checkouts do and add a "title" for each page of the form above the form fields so that as a user moves through registration, they can monitor their own progress.
I'd recommend checking out the Amazon checkout, or really any multi-page survey (you may even be able to set one up yourself on Survey Monkey) to see how a large number of form fields can be broken down logically in a user friendly way.
Hope it helps.
Check out this link: http://www.smashingmagazine.com/2011/05/05/innovative-techniques-to-simplify-signups-and-logins/
It's talking about login- and registration-forms and how to make them more user-friendly. A suggestion which is also included in this article is as follows:
At registration don't ask the user to many questions. Only the basic data like their name for example. Then ask him about more detailed data when the user logs in the first time. This way the registration won't take too long.
Maybe this helps you out :)
I have a classifieds website, and I just asked a question regarding if I need to use captcha or not whenever users post a new classified etc.
Some places on my website (like contact forms) do need some sort of authentication (captcha etc...).
But I don't know whether I need one when posting a new classified, so I turn to you guys to decide.
Here is the procedure today:
User clicks on "new classified".
User fills out a form containing alot of inputs/selects etc. The selects are javascript populated btw, if that makes any difference.
Users then click "Preview Classified" button.
Next is the "Preview" page, where users see what their classified would look like.
Here, all the form information from the first page is stored in SESSION variables.
If the user is satisfied, then they have to choose a password. This is done by filling out another small form in the "Preview" page at the bottom, with two inputs, "Password" and "Verify Password". This password will later be used to delete the classified, edit it etc.
When the password is entered and validated with Javascript (not empty, no special chars etc) then users may press the "Insert Classified" button.
The "Preview" page is submitted to a "insert_ad_into_database.php" page.
Remember setting all information into SESSION variables, well this page uses those variables to insert them into the databases (MySql and Solr indices).
If the classified got inserted, a "Success" text is echoed, otherwise "ERROR" is echoed.
Do you think I need captcha on this, as it actually is two forms which needs to be filled out? (classified form and password form)
Thanks
I already gave my full answer to this in your other question (let the principle of "least barrier to entry" guide you), but I'll give a recap summary here:
No, this is not safe from spam bots (but it would require a fairly sophisticated spam bot to get through this -- a standard-issue "post something to a form" spambot will break down here).
But you also shouldn't include a captcha until you've seen an actual problem with spam.
Spam bots (especially sophisticated ones) are way less common than you might think, and captchas hurt new user acquisition way more than you might think. The trade-off is easily in the direction of no captcha.
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).