I have implemented simple shopping cart in a website. I save the cart and items in Session object. After user checkouts (using Paypal), I clear the cart items. This works fine, but I have seen a problem in following scenario:
Suppose a user added some items to cart and opened another browser and logged in. He can now see the items in both browsers. Now if he checks out in one browser he is still able to see the cart items in other window as both browser have separate sessions.
What approach should I adopt to avoid this or will have to live with this?
EDIT:- After posting the question I was thinking about it. I will settle for this simple solution, Whenever user goes for checkout, I will hit the database to load the cart instead of session. This way I won't be hitting database for showing items in cart (on top) and there won't be any checkouts based on phantom items.
From the moment that you save the cart items on the session and you have diferent sessions you have diferent carts.
To eliminate this, you need to have a common place for all session that you going to save your cart, and this is a table on a database. This common place are connected to the user ether with the user id, ether with the user cookie.
You'd have to AJAX-ify the shopping cart panel section of the page and use setTimeout() to refresh it at regular intervals.
Probably more effort than it's worth, however - if you're doing it right, clicking 'checkout' again on the 2nd page shouldn't cause duplicate transactions and the list will refresh on the next page load.
EDIT
And by "doing it right" I mean tracking cart items based on the user's Id, not just the Session object.
Your web app is based on HTTP protocol which open and close a connection just to satisfy an Http Web request. Now it is quite normal that if you open another two browser and check out on one of them you can still see the same page (infomration) on the other one. What I think you should do is just avoid that a user can check out twice or handle if someone is trying to check out an empty basket(which is your case if the user hit checkout on the second browser)
and it that case you can just show a message. If you go for the solution for which you should refresh at interval the page bear in mind what it could happen if the user open and log in into 250 different sessions: how many time your web app will be hit?
If you go for my suggestion all user session will get just an error page like: The bastek is empty.
I hope it makes sense
Related
I have two pages.
On first user want to filter some data. After that he pick some value and go to second page.
On second page he will do some tasks and then he want to get back to first page to pick some other value to do other tasks.
But for now he have to filter back some data (on first page), but I want call back his filters. Is there any way to do this?
You got a few options here for this.
As STT mentioned in his comment to save the filter data in a session variable/ViewState, works all fine when you only got one web server otherwise you need to setup a shared sessions cache etc. The date will be kept temporary in the Server.
You can also save the data to a cookie and when loading page 1 reload last used filter used from the cookie. Then you got control of the expiry and session data is stored in Web Browser.
By adding the data for the filter into an URI parameter you can from page 2 include the data when user clicks a back button (not the browsers back button) The advantage of this its not session sensitive and the user can bookmark the url to get same filter later on.
I recently started working on a site that another developer built (who is not within the company anymore, so can't ask him)
On the site there is several separate accounttypes for users, so when a user logs in, the user comes to one of two specified login-start pages.
Some users have two accounttypes. When that's the case I want to make a dropdownlist that holds both startpage-options (let's call them a, and b)
If they choose option a) from the ddl, the a-startpage will be that users permanent startpage until the user changes it to b, then b will be that specific users permanent startpage.
the project is made with C#, ASP.NET, with Webforms, MS SQL.
any suggestions that might lead me in the right direction is much appreciated
/S
there are at least 2 possible solutions that require little effort:
a cookie on the user's system: when accessing the system for the
first time (or after a system change or a browser's cookies clearing)
the application takes the user to the dropdown page and let the user choose the
preferred login-start page. on subsequent accesses the choice is read from the cookie and then the user is forwarded to the expected page. the biggest advantage IMHO is that no changes to the backend structure are required and the changes on the fronted are minimal.BEWARE: do not trust what you get
reading the cookie and always double check that the page suggested
by the cookie is actually allowed for the user.
an attribute of the user: the user choice is saved in the user's profile and read on subsequent accesses.this approach requires some change in the backend because a new attribute must be added to the user entity and maybe also the tools (stored procedure, method, whatever) needed to interact with that new attribute have to be created.this solution requires less or no checks/validation because the information is stored server side so you can redirect 'blindly' to the login-start page.
there is not a 'right' solution because it mainly depends on what you are allowed to do and your skills.are you allwed to alter the backend's structure? what you know better, backend or frontend development?which one is easier for you to change? is there any policy/guideline to follow while developing that favor one of these approaches?
So in the end i solved it like this.
Firstly i created an int(allows null) column called "changesite" in the db (member/user)table so i could use the members id.
Then i connected it to the dropdownlist where the members/users can choose their startpage (in my case i made the ddl only visible to the members if they are the type of user that has the both user accounts).
if the user chooses the first option a 1 got saved in the db, and for the second option a 2. (This method could be used with any number of startpages you might have).
Then in .cs file were users got redirected to their designated startpage it was as simple as creating an if, else-statement, with the value from changesite as identifier.
Basically if the value from column changesite == null, do nothing. If changesite == 1 redirect to the first startpage and else redirect to the second startpage.
A big thx to Paolo for his inputs.
There may be a setting I am missing somewhere, but I am completely dumbfounded by this issue. I have a dynamic data web site that is using role based permissions to limit the content a specific user can view, edit and delete. When the user first logs in and is redirected to the default page, it displays all of the correct tables for that users role. After clicking on any of the available tables, then clicking the browser back button, the default page will display every table within the database regardless of what the users role dictates. I am dumbfounded because at no point is there a view of every table available to any users role yet somehow ie9 managed to cache this imaginary version of the page. I know that this must be a cache issue because page_load on the default page is not triggered when the back arrow is clicked. If I refresh the default page it will be displayed correctly again.
I am working with a master page and explicitly turned off every form of caching I could think of in its page load.
HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(false);
HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.NoCache);
HttpContext.Current.Response.Cache.SetNoStore();
Response.Cache.SetExpires(DateTime.Now.AddSeconds(-1));
Response.Cache.SetValidUntilExpires(true);
One other thing to note is that this only seem to be an issue with ie9 when I test the site in ff, chrome or safari things work as expected.
You have to store the role of the user who logs in in a session variable and then show the required data(table or whatever) based on that value.If the data is shown based on the user's role in the session then i don't think you will have any problem. Also you can disable the cache by giving Response.Cache.SetNoStore(); at the page load function.
I have a user complaining about frequent timeouts in my Intranet web page. While looking for a solution I found this post:
http://forums.asp.net/t/152925.aspx?PageIndex=1
Where a poster recommends intercepting the redirect to the login page, submit the data to the database, then either reauthorize the user (without their knowledge) or redirect to login page. My goal is to avoid the situation where a user enters data in a form, walks away, then comes back to submit it, only to be told they have to login again (which is fine, if the data remained and the user was sent right back to the original webform).
Does anyone know how I can accomplish this on specific pages in my app (not all of them)?
It's not necessarily trivial, but you can add an ajax component that makes occasional calls to a page to keep the session alive. This way you could lengthen the session for any particular page you need to without affecting the application as a whole.
EDIT
If you really want to let the session expire, but keep the form data, you can implement
protected void Application_PostAuthenticateRequest (object sender, EventArgs e)
event handler in your global.asax.cs file. This is called before the forms authentication redirect happens, and the form data is available to your application at this point, so you can persist it to whatever medium is necessary until your user is authenticated again. In addition, if you check the
((HttpApplication)sender).Request.Path
property it will tell you which page was requested.
Well, the easy way it to drastically lengthen the timeout specified in the web.config file.
I'm going to try using cookies to preserve the data. My plan is to update the user's cookie after each control is changed, then add logic to the page_load property of the page to populate the form data after the user is logged back in.
I have a view that shows a list of items and when you click on one of them it will take you to the items page. I also store a "Viewed" flag in the database for that item.
Now, when the user clicks back, the item should be styled differently because of the change in the "Viewed" flag. However, every time I click back, it is as it was before I clicked into the item, and I have to click refresh to see the actual state of the page now.
How can I prevent this page from being cached so when a user clicks back they will see the latest version of this site, complete with the new styling?
Mark the controller action that generates the list with the OutputCacheAttribute and set the cache location to none to prevent that page from being cached on the client. This should cause the client to request the page again. If the user is using the back button, however, I think that the page is served up by the browser without reloading regardless of the caching. At least in FF I don't see it requesting the page again using Firebug.
[OutputCache( Location = OutputCacheLocation.None )]
Call this in your controller action:
Response.Cache.SetCacheability(HttpCacheability.NoCache)
This will prevent the browser from caching the page.