I have list of products in the database that I show in the GridView. Each row in the Grid has a text box and Button along with Name and description of the product. The button is used to send the comment for that specific button. Everything works fine now I want to limit the comment once per session. So a user will be able to send comment for a product and then button will be disabled. Now the products count can be 10 or 1000. What will be the best and efficient approach to achieve this. Should I save the product id and session id in the Session or in database or there can be some other easy way.
I haven't mentioned any code because I am just asking for best possible way to achieve the task.
let's understand the meaning of your suggestions:
using a session:
you are opening a session key at your server and map a list of id's which already had commented. you can match a specific product against this session and determine if the product can be commented or not.
pros: very elegant and easy to maintence solution
cons: a user which request your website (say from another browser) will be able to comment product since the session is per connection and not per user
using a database:
same as session, only the data is durable because it is stored by the database.
pros: full control whenever users are able to comment a product or not
cons: must identify each user with unique key (like id) and store that information in the db as well
other alternatives:
cookie on client side - setting up a cookie that will store the information. pros: each machine saves it's own cookies (not the server) cons: each cookie need to identify the user (or else several users on the same machine will be blocked). cookies can be cleaned
local storage on client side - same as cookie for that matter
so it semms you will need to work for it a little bit.. or else the functionallity will be problematic in some scenarios
Related
Situation:
I'm creating some kind of website that let users comment and like on posts. There are two types of users, users with user name and password (type 1) and guest (type 2).
For type 1, data will be stored with the keys are their login credentials. By this an user can't like a content multiple times (next time, loading the page, they will see the "Unlike" button)
Type 2, I'm using IP for differentiate between users. But, IP is changeable by time (since normally, IPs are dynamic).
Notes: Needed to be implementable with C#, ASP .Net.
I can't use session variable, because it will be destroyed after closing the browser.
About cookie, cookie is nowadays so easy to be deleted, this will be my worst way for implementing (in case there is no other).
Question:
Is there any ways to generate unique id for a client (a PC/smart device), so first time if you use a PC to view the post X on page, you like it, next time (even after you close your browser) page can identify you then change button to "Unlike".
There is no reliable way to do this. For example, what if a user opens the site on his laptop, then his mobile, then his tablet? You cannot prevent each of those devices being registered as a different guest. The only solution is to make people log in and only allow read access to anonymous guests.
There are two ways of handling this.A) Get the Unique Device Identifier (UDID) and store it on your server.
B) Generate a Universally Unique Identifier (UUID) and store it on both the device and your server.
With the first method, you don't store a UUID on the device, so you both save space (bytes worth of data, but still) an the user can't change the ID without reinstalling the OS. But, it would be highly platform dependent.
With the second method, you use the System.Guid.newGuid() method and save the resulting UUID to a cookie on the browser.
Then you either read the data off the cookie or get device UDID and compare it to your database.
But, this wouldn't keep the user from accessing the website from different devices. The best method would be to ask the user to sign in (But PLEASE be careful with password security as people generally use the same password across services).
Hope I helped :)
I am creating a website and it has multiple pages which a user needs to go through them step by step. for example the first page www.website.com/personal.html will ask users to fill in their personal information and then the next page www.website.com/favorite.html will ask other questions about their favorites and so on...
What I would like to do is not allowing a user to manually enter the address www.website.com/personal.html and access that page again. I would only allow accessing that page through the flow of the website or if I have a tab or a link to that address.
Is there any way to prevent such thing?
If you are using MVC, why are you talking about static html pages at all?
Just use a single action method that returns multiple views based on your workflow state. That way, it's impossible for the user to direct based on URL (since the URL would be the same for every view).
You could use the referer header to detect where a link came from, but that is easily forged. Assuming you have a session database and you are setting some manner of session cookie, you could store state information with the session data, and redirect if you receive a request for personal.html if the saved state does not indicate that is the current page.
Nope, not really. You can check the referrer but that can easily be spoofed. You could use a cookie to indicate that the user has already been at each step, but again, easily circumvented.
If you are saving information after each step, can't you just check if the user has already input his personal info and if so, redirect him to the next step?
The only reliable way would be to check the saved data on the server side and act based on that.
I have an asp.net (webforms) application and I would like to track user visits to the site. I have the DB, objects, basic idea down.
My goal is to track a user from the first time he enters the site and up until he creates an account. So I can trace back where this user came from in his initial visit (Organic, paid, referrer, etc.).
I am planning to create a cookie with a GUID for each initial visit, store all actions in the DB, and finally, when the user registers, I can go back and update a username field for all rows matching the GUID.
My problem is that I can't make up my mind on the best method to do this.
Should I use an HTTP module and the session start and end events,
or maybe ajax calls to a WCF backend?
What would be the most efficient and accurate way to do this?
Unless you plan on supporting anonymous sessions (which depending on traffic may or may not be an option), Session won't work.
The simplest thing that could work is simply putting a ticket (like your guid) in a cookie. You can set and retrieve Cookies from your Page and use that to track the user. This does mean you'll only be able to track a user when he accesses from the same machine but until he's authenticated, you don't really have that much of a choice.
My asp.net session objects are storing in SQL server.I am storing an ID in session. If client open another browser and storing different ID in session. I need to notify client is “are you sure you want both ID’s open?” in same based user logged user.
Application runs on logged in user (not anonymous)
How can we check this in asp.net?
Session is not linked to an authenticated user, and there is no way of accessing an other connection's Session without knowing its SessionID.
Usually this kind of problem can be solved using cache instead of session state. With cache you can create your own user-based keys to store data. Depending on whether you are planning to just run your web app on one server or in a web farm environment, you can either use asp.net in-process cache or one of numerous distributed cache solutions (like memcached which I'm using in my web projects with great success).
There are a couple ways to go about this:
Option #1, in your user table, add a value called "session id"
When a user logs in, check to see what their last session id was. Then test to see if it's still a valid session. If it is, ask them what they want to do. Store the latest session id in that table after each log in.
However, I'd go with option #2: Don't do this. If the user wants to open multiple browser windows to access your application then let them. There's probably a pretty good reason for it. Most (as in nearly all) users have no idea what "session state" even means and they really have no desire to know. All they care about is getting their job done.
I'd like to program an authentication system, with the following features:
Use ASP.NET MVC2
Use SQL Server
(Propbably) based on MembershipProvider
User registration with email confirmation
Role based authorization
..and last but not least:
- Give the user a chance to login and/or register when authorization fails while performing a POST action.
The last feature is the most challenging feature. When a user performs a POST action (or some other kind of request) and the session times out (or the user is not authorized for some other reason), the user must be redirected to a login/registration form. During the login and/or registration process, the data of the request data (POST, GET etc.) must be saved somewhere. After user is succesfully authorized, the data should be restored and the request must be executed using the saved data.
The solution I have in mind is that the request data are serialized and stored in database, identified by some unique key. This unique key is put in cookie and/or in a hidden field in the login/registration form. When user is succesfully logged in, the context can be restored using this key and the action can be executed using this "old" request data.
The most tricky thing for me is that I don't know which data I should save and how and where to restore the context. I want to be able to use the build in attributes like [Authorize] and Routing.
I (think) I looked practically everywhere but without satisfying results. I hope someone can help me with this. Thanks in advance!
Online shopping cart normally allows anonymous users to put a few things in the cart before getting them to register/login. But unfortunately I'm not familiar with those techniques and don't want to give you half-baked explanations.
On the other hand, here are some common practices indirectly addressing this problem:
prompt user to register first before taking them to a data entry page
intercept the POST with ajax/popup login window
remind user about session timeout, and allow user to extend their session without leaving the data entry page
automatically save the data entry page for logged in user periodically
split a large data entry page into several smaller ones, reducing the chance of time out
Hope this helps.