I want to store a user setting(language). so i can get the corresponding resources when the page loads. I figured cookies would be the way to go, but it's just not an option, too difficult since i have tried and tried without success.
After 2 days i want to give up on cookies and see if there is another way I can achieve the same goal
i've read this article http://msdn.microsoft.com/en-us/library/ms178581.aspx
but im not sure if I can achieve what I want using that.
What alternatives for cookies could i use in my situation?
Depending on the level of persistence you're looking for, there are a couple of other ways you can do this. The first is to use session to hold these settings. However, if you use session the settings will only live as long as the session does. If your website has some kind of authentication interface, you can store the settings in a database relative to the username used for authentication. If you don't have authentication involved and simply want to remember that the user came with a particular computer/device, you can achieve the same result by footprinting the system (not trivial) and storing that footprint in the database related to any settings it would encounter.
If those options are not available to you, then cookie will be your only remaining alternative.
An other alternative to using cookies to keep a session ID is to use cookie-less session management, which is mentioned in the article that you linked to. A cookie won't be kept on the client machine with the session identifier -- instead, it will be in the query string. It's definitely an "uglier" solution, but it's one of the few options you have. You can either keep a cookie that's sent up with each request, or stick something on the query string to identify the request.
Either way, you need some way for your server to pick up the identifier and retrieve your session data -- whether it's getting the ID from a known cookie or a known query string value.
I mean, there are probably other ways -- keeping a hidden value on each and every page, but I think that just gets even "uglier". You want to keep that information out of the page/information that you're rendering.
Related
I have 3 pages to get details of user and I'm confused what to do with users' temp data
whether
store in database and delete incomplete form data using scheduler
store in session for that user
store in cookies
All of the options you mention are valid in some cases.
I would not go for the cookies option since they are sent along with every request and the data could get too large.
If you want to keep information over sessions the database is your only option. Else wise choose the option you seem best.
It depends upon the requirement. The easiest will be session since clearing the data is not required .net will do it automatically on session-expire.
storing in database and cookie will result in more code. If you want to use the best option go for cookie it will use the least server resources, but the round trip can be costly if there are many cookies. since cookies also get transmitted every time u make a request.
The other options that you can think of is using the view state to persist the data. It will require the most code to accomplish, but will be the best since the data is only be kept till the user is completing the form. you will have to take one page data and pass it to another page in view state and so on.
1.if you use database then this option requires DB trips that is not good and it also effects to your application performance.
2.Session will be the best option to store user Temp data.With sessions you can use datatable object and then this datatable is assigned to session variable.
3.it creates a problem if some user disable browser's cookies.
Happy coding....
The goal
Pick Session or ProfileProvider to brings to life some user's information.
The problem
Session and ProfileProvider are different things — they play different roles.
There are three information that I need to use all the time: the user's Fristname, Lastname and StoreId. The Firstname and Lastname will always be the same, but the StoreId can be changed — and I can't store its value within a cookie.
So I need to ask: based on this scenario, there's any problem to store those information (First/last name & StoreId) within a Session? Install and implement all the ProfileProvider's methods costs me too much time, and a Session can solve this quickly, but I need to know if there's something wrong to store first/last name in this way of data storage.
Too broad?
I think this question can share multiple opinions, but the proposal is very simple: can I store those three information within a Session? Actually I know that I can, but what I need to know is simpler: how much will this cost to me? Performance (How much/why?)? Security (How much/why?)?
Sure, of course you can. And I don't think that performance and/or security are an issue here (without knowing the details, that is). What's important is how long you want to store this data. If it's in a session, it'll be gone as soon as the user terminates the session (logs out). If that's fine for you, use session variables. If you need to know this data the next time the same user logs in, then the ProfileProvider is what you need, it does store data independent of any session.
I'm trying to work a number of security issues on a rather large ASP.NET web application (C#). To prevent session fixation attacks I'd like to generate a new session id every time a user authenticates himself. However I want to only generate a new session id without losing the rest of the session. After doing some research on this topic I found a couple of working solutions:
Solution 1: Generating new SessionId in ASP.NET
This suggests clearing the session cookie manually by setting it to an empty string. However this requires either a page refresh or using AJAX to ensure that the cookie will indeed be removed, which isn't really a viable option in my specific case.
Solution 2: Generating a new ASP.NET session in the current HTTPContext
I have implemented this approach and it works as expected. However as the original poster states, this is not really what you might call an elegant solution. Also, this post is a few years old which has me hoping that there might be a better solution out there nowadays.
What I would like to know is if there are any alternatives to do this that I have missed in my research or if something like Solution 2 is possible without manipulating session management internals.
It's not that easy to achieve what you want due to how session management works by design in ASP.NET, re solution number 2. The solution (2) seems a bit risky considering ASP.NET session state implementation details change at some point.
I'd recommend a variant of solution 1, where you store the relevant data from the session to db/cache when the user authenticates, get a new session for the user and then populate that with the data you need. Since data is moving from an "unathenticated" session to an "authenticated" session you should also take care to validate that data.
Clearing the session cookie manually can be a slippery slope, re Ramping up ASP.NET session security. You'll find a more robust solution in the NWebsec.SessionSecurity's authenticated session identifiers (Disclaimer: I'm the developer on that project).
Web.Config changes
sessionState cookieName="ABC"
In Login.aspx page in block !ispostback write
Response.Cookies.Add(new HttpCookie("ABC", ""));
Enjoy
-Saving time is good!
I have a small web application that has multi-language support (en, de, it, fr, nl, sl, hr). This application is accessed constantly from a lot of users that use it for a short time (the time to fill their data to get an internet access code).
I have a problem with setting the culture similar to this thread:
InitializeCulture change language of domain
I know how to do it, it's just that I'm not sure which state-management to use. I wanted to ask for suggestions which method to use. Those are my thoughts:
Session - the easiest way and the more elegant, but it's server side and I have a lot of requests so I fear that the server can get too overloaded
Cookie - easy to implement and it's client side, but some users have cookies disabled in their browser
QueryString - not so easy to implement in this phase, but it's client side and can be easily tested because the application has only 3 forms (3 URLs to add query string parameters)
I'd like to hear your ideas and suggestions.
Thank you in advance!
Actual persistence store would actually depend upon the scope/life-time of culture selection. For example, if it's user specific selection that has to be persisted over sessions then you can use database or persistent cookie where cookie will remember for a machine and database will remember across machines. The retrieval (from database) will happen when it's needed - and the value can be cached into ASP.NET cache (will need different key per user) or session or view-state (if its single page application) etc.
You shouldn't worry too much about putting that into session if you are already using session state for something else. In such case, it doesn't really consume any significant memory. If you have log out function then you can explicitly clear the session state and release that little bit of memory. If you don't have log out functionality then you can use small value for session timeout.
I'm trying to store an xml serialized object in a cookie, but i get an error like this:
A potentially dangerous Request.Cookies value was detected from the client (KundeContextCookie="<?xml version="1.0" ...")
I know the problem from similiar cases when you try to store something that looks like javascript code in a form input field.
What is the best practise here? Is there a way (like the form problem i described) to supress this warning from the asp.net framework, or should i JSON serialize instead or perhaps should i binary serialize it? What is common practise when storing serialized data in a cookie?
EDIT:
Thanks for the feedback. The reason i want to store more data in the cookie than the ID is because the object i really need takes about 2 seconds to retreive from a service i have no control over. I made a lightweight object 'KundeContext' to hold a few of the properties from the full object, but these are used 90% of the time. This way i only have to call the slow service on 10% of my pages. If i only stored the Id i would still have to call the service on almost all my pages.
I could store all the strings and ints seperately but the object has other lightweight objects like 'contactinformation' and 'address' that would be tedious to manually store for each of their properties.
Storing serialized data in a cookie is a very, very bad idea. Since users have complete control over cookie data, it's just too easy for them to use this mechanism to feed you malicious data. In other words: any weakness in your deserialization code becomes instantly exploitable (or at least a way to crash something).
Instead, only keep the simplest identifier possible in your cookies, of a type of which the format can easily be validated (for example, a GUID). Then, store your serialized data server-side (in a database, XML file on the filesystem, or whatever) and retrieve it using that identifier.
Edit: also, in this scenario, make sure that your identifier is random enough to make it infeasible for users to guess each other's identifiers, and impersonate each other by simply changing their own identifier a bit. Again, GUIDs (or ASP.NET session identifiers) work very well for this purpose.
Second edit after scenario clarification by question owner: why use your own cookies at all in this case? If you keep a reference to either the original object or your lightweight object in the session state (Session object), ASP.NET will take care of all implementation details for you in a pretty efficient way.
I wouldn't store data in XML in the cookie - there is a limit on cookie size for starters (used to be 4K for all headers including the cookie). Pick a less verbose encoding strategy such as delimiters instead e.g. a|b|c or separate cookie values. Delimited encoding makes it especially easy and fast to decode the values.
The error you see is ASP.NET complaining that the headers look like an XSS attack.
Look into the View State. Perhaps you'd like to persist the data across post-backs in the ViewState instead of using cookies. Otherwise, you should probably store the XML on the server and a unique identifier to that data in the cookie, instead.
You might look into using Session State to store the value. You can configure it to use a cookie to store the session id. This is also more secure, because the value is neither visible or changeable by the user-side.
Another alternative is to use a distributed caching mechanism to store the value. My current favorite is Memcached.