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.
Related
I have an MVC application, where one controller returns a View that have an iframe , controller also returns url that need to loaded.
I need that iframe to load legacy .aspx pages.
Now I want to share some data from MVC controller to that .aspx page via 'SESSION' or 'Request' object.
Is it possible ? Do I have any other alternative to share data securely (I don't want to pass as get parameters).
Since we are talking about two different applications, there are some options but none through SESSION
Your first issue is how to identify the same user. There are two options here.
Through the use of cookies, if both applications are in the same domain. You can store a session identifier there and it will be sent to both applications. A jwt token would do fine or any other session identifier
Through the use of a single sign on system. This would be more tricky to implement and there are a lot of oauth/openidconnect systems out there to choose from.
Now onto the session iteself. Since we are talking about two applications, you are going to need some kind of shared place to store the session values
The simplest form would be a shared database where you store the session values. It could be in memory tables in mssql to speed things up. On the downside, you should be careful to invalidate/update the values which would cost in queries
Some kind of distributed cache, like REDIS.
Warning - You might see suggestions to use session state store. This is to share SESSION between servers and not so easily between applications, so I wouldn't suggest that.
I have somewhat of a thought problem, where I'm not sure if what I already built can be done a lot more efficiently, so that's why I'll share my 'problem' here. (to be clear, everything I have built works, I'm just looking to make it more efficient).
I have a webapp made with MVC & SQL which has a log-in system etc for users.
A user has a status, which is an enum, and can be active, blocked etc and is stored in the database (along with other user-data).
Within my webapp I have made a custom AuthorizeAttr. for authorizing users on every call made (applied as a global filter).
However, the 'normal' authentication is based on the cookie, which does not change when I would change the user-status in the database. For instance, users can de-activate another user in the same group (when being Admin). These database changes are not taking immediate effect since by default the authorization only verifies the cookie, and the cookie is based on the status when logging in.
To fix this issue, I added some additional logic to my authorizationAttr, which on every request calls the database for the current user status (the enum), and then simply does some checks whether the user is allowed to continue, or a redirect is required.
Calling the database on every request seems (even just for 1 enum) seems to be a bit taxing on the server/db especially when the webapp would grow in popularity (= lots of users).
One idea I thought of was to cache the enum in session cache but for short periods of time (like 60 seconds), this would save some database calls, but obviously the user can still use the webapp for max 60seconds after being de-activated.
I could be wrong in thinking that these database calls are actually that taxing of course.
Any ideas for improvement?
how do you know that checking status per request is too expensive? did you measure performance cost of checking user status in the database? have you created your custom cache without actually measuring the cost of simple solution? do you use ORM like hibernate? they have 2nd level cache built in so often there will be no roundtrip to the database.
i think it's way better to stick to the KISS principle rather than creating custom solution for a difficult problem. even if your database will be the bottleneck then usually buying additional hardware once is cheaper than maintaining overcomplicated solution for years
if your application grow, first thing you throw away is relation database
Have you considered using ADO.NET DataSets for your requirement? If you don't have multiple front-ends you could possibly read the login statuses initially into the dataset. All read/write operations could be made to this and you could later save your changes to the actual database. In case you have multiple front-ends, would it be possible for you to restrict all read/write/modify operations of one group to a single front-end instance? Because I guess you could use the dataset approach in that case as well.
C# - ASP MVC - .NET 4.5 - Bootstrap - Razor
I have a form wizard (http://vadimg.com/twitter-bootstrap-wizard-example/examples/basic.html) that is used to setup a complex object (obj1). A property of obj1 is a List<obj2>. On one step of the wizard I want to add multiple obj2's to the list. Since obj2 is slightly complex as well, I thought I would use another wizard to help build it. Except I need to persist this List<obj2> on wizard 1, while I'm off in wizard 2 building another obj2.
My first thought was to use a session to hold the List<obj2>, I was just wondering if that's a good option, or if there would be a better one? The user may leave from Wizard1 to go to Wizard2 and come back multiple times.
There's no perfect answer here; each approach has trade-offs. But here are some options that I can think of (and these are independent of ASP.NET/C#)
Session (as you suggest)
This will store data in web server memory (by default). If you have a lot of users, this could be a problem.
You risk the information being lost when the user gets a new cookie/the session times out.
Potentially better performance that a db, depending again on the number of users
Database (as you mentioned)
Could cause more database traffic.
Can save information for user even if they close a browser, switch computer, the power goes out, etc.
Maybe a separate NoSQL database just for transient wizard data would be worth trying.
Cookie (store data on the user's computer)
Users can potentially tamper with/view the data
There is a limit on cookie size (4 KB each?)
Local storage (HTML5)
Similar to cookies
But not such a small limit
Not every browser supports it (may need polyfill)
Form/Post/Hidden/ViewState
You could just post the data and drag the information from response to response
But this gets really annoying with back buttons & timeouts
Lots of work, and again, the user can tamper with the information
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.
I need to store user preferences on a per page basis in my application. For example, several pages use a custom grid pager control that needs to keep its current page size between postbacks. Most of the settings don't need to persist once the user leaves the page, but in some situations they do need to be restored. Note: Session is disabled in this application and will not be used.
I did some reading on isolated storage and understand that it can be used to store these user settings. Obviously cookies have been around a long time and are a proven approach to this scenario, but what about isolated storage? Is it going to work for all browsers and in all environments? Are permissions a problem? Does it require configuring anything on the end-user's side? Just how widely used is it? Why should one use isolated storage in an application for the given example?
Thanks!
Obviously cookies have been around a
long time and are a proven approach to
this scenario, but what about isolated
storage? Is it going to work for all
browsers and in all environments?
Ah - .NET isolated storage is SERVER SIDE. Like a database. It is meant as a small way to store small amounts of data( ONE user, not all users, viewstate) on the side the .NET application runs (in asp.net case = the server).
As such it is totally irrelvant to your question.
Put the data in a database. I know of VERY few usages of isolated stoage for ASP.NET applications, it craetes a TON of long term problems. It is not meant for server side apps.
You can always use hidden form field variables on a per-page basis, as a way to keep track of that page's state.
This is my preference to a session state strategy to deal with the scenario of users having say 2 FireFox browser instances open to the same page. No need to deal with session state issues in that scenario.