On a portal's main page, I'm using a jQuery container plug-in, and by this users can hide a container by just clicking the minimize button on a container.
My question is: how can I save the user preferences in this regard? Then if the same user logs in again, I want to show the page based on user preferences. For example if a user hides the "sports news container" it won't be shown on users next visit.
You just need to create a field in the users database table (or do something more complicated, if your database is complicated).
Then you can, if the field is set, place a script on the page that hides the container. And set a callback on hiding/opening which will send an Ajax request to your application, which will set the field to 1 or 0 (ON or OFF, whatever).
I think there are basically 3 options.
Cookies (sending a cookie to the user with JavaScript/jQuery or PHP (setcookie())) and hope the cookie is stored as long as possible.
Storing the preference at the database level, per user. #valya gave a solution like that. The obvious drawback here is that every user of the site, that you want to have preferences, needs a login.
Storing the preference in the database by IP address. This solution is pretty bad, but depending on your users this might work. So you store preferences per IP address. Users with a dynamic IP address or multiple users on the same IP address will have a bad experience.
Related
My question is that how to temporally disable a number of buttons/links for user when he clicks one. For example there are 5 buttons: button1, button2.. If he clicks button1 then he can't click any of the buttons again for example 6 hours. Should it be done with php getting user ip, sending it to mysql and "banning" user for 6 hours. Whether clicking the buttons or the url where the buttons are. And after cleaning the specified ip from mysql. The buttons should be banned for the clicked user not for anyone else also refresh or browser restart should grant the option to click any again.
Or should it be done with htaccess somehow.
Extra info: PHP 5.4, mysql.
Site also has a basic login system ( http://blog.geotitles.com/2011/07/php-login-script/ )
But I think it would be easier to do separately.
Have a fool proof way to identify individual users. The only real solution here is to require the user to register and log in.
Store the last time the user did a certain thing in your database.
Check when the last time the user did a certain thing was and do not offer him the button/reject the action should he be doing it again before enough time has passed.
(Optionally: periodically clean out old and unneeded action/timestamps from the database.)
In your users database table, add a last_button_click field.
When a user clicks a button, write a record to the database saying the time they clicked it. When reading the page, check if last_button_click is more than X hours in the past, if so, display the buttons.
If a user shouldn't be able to use duplicate accounts, you'll also want to record his/her IP address in the database and prevent more signups from the same IP address. This isn't foolproof, as users with VPN services like HMA will be able to get around it, but for the majority of users it will work.
You can also look into banning anonymous proxies, VPNs and TOR if needed.
"Banning" a user in a database works fine. When they click the button it should add a ban to the database and when it draws the page again, it should query the database to see if they are banned. If they are, do not show the button, if they are not, show the button.
I'm currently working on my Referral System, but I have a problem with protecting it of frauds.
Okay, here's how it works for now:
user registers and activate it's account
user now have access to the control panel and there is it's uniqe link in following format: domain.tld/ref/12345
when someone other click to user's link, he or she must to click a specific button to confirm that is not some kind of fraud (like "click here, you'll get $100" or something)
system writes visitor's IP in a database and some data to cookies to prevent re-pressing the button. User now have +1 point.
But, the problem is that visitor can change it's IP, clear cookies and hit button again. It takes a few seconds, and that's not OK, that's cheating.
How to prevent it? Is there some trick to get some unique computer ID or something can't be changed that easy?
Really the only options are to tie the process to something which is not so easily manipulated by the user - super cookies, browser fingerprints, OpenID, Email addresses and telephome numbers (the latter 2 using some sort of validaton step before a vote is counted)
The only way you can be certain a referred party does not reuse a referral code is for the original user to send different one-time-use-only referral URLs to each person. Once the code has been used, it is flagged as such in (or removed entirely from) your database so that it can not be used again.
How you prevent the original user from sending multiple links out to the same person is another matter - and not an easy one to resolve.
Who do you perceive to be the threat?
Although it's certainly not 100% accurate, you can still fingerprint visitors using for example a combination of their ip, browser user agent, and with some javascript you can even go for screen size or installed fonts. Using these pieces of information you can set up a system where you save the fingerprints in datatable and in the same record you store the session id (from the cookie). Now when a new visitor arrives you can test their fingerprint against the db of recent fingerprints with different visitor ids. If you find a large number of matching fingerprints (you define the threshold) with different sessions then you can alert for the possibility of fraud.
Cheers
How about storing the link with with the user when they navigate to the link. then in the database you will have the link and if the users has already been to the link then deny them. Seems like it could work then you wouldn't have to worry about the cookies etc...
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, 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.
I am having trouble in understanding of how I need to do this:
Have list of items on my home page and when users click on that, I take them to a page where i ask for name and email id(both are optional fields) and when users hit submit, I will take them to other page where they get to see all the details. the reason for that name and emails fields are to store the ip address in mysql and also the url(has the item id and date) they are on.
To do this, i am having trouble in doing it in program.
I am thinking to start a session/store cookie once they hit submit. after that I want to store the ip address, item id, date and name/email(if they filled in) in mysql db
Store everything in the mysql db
Also, how can I avoid anyone going to the page directly(the one I show after they submit) ? Is there any way can I include some condition on that page and redirect them to this log in page ?
Please help me out.
regards
Since you set session variables when the user hits the submit buttons, you can test if one of those variables is set or not and redirect accordingly.
You can also do it with POST, use the page as an action to your form, and whenever someone accesses that page you test if $_POST variables (from the form) are set or not.
As the data seem to be necessary only for the immediate use, I think that a session is the right answer in this case.
If you would then use a database query, which data would you store to associate the data to the correct user? As you said, both the data you ask are optional; even in the case there would not be optional, how do you handle the case two different users report the same name and email (it could also be the same user using two different browsers).
For temporary data like that, the session is always the better choice (except few exceptions, maybe).
I was forgetting the other question.
Also in that case, I would use a session variable. Sessions variables are the solution for values that you want to keep between different forms, without the need to keep moving them between the server, and the client side.
For more information about sessions, see PHP: Sessions