Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm working on a Web project using Asp.Net MVC, which I'll have to deploy to a farm environment.
I've read a lot of articles and I'm thinking on disabling completely the SessionState, I think this would make a more robust application, and will save me a couple of headaches (Everything I've read tells me that handling sessions on a farm isn't trivial).
There are some things that I still don't have totally clear with this approach though, the main one being the authentication/authorization process. Basically I'm not sure of how (if?) I can handle user sessions if there's no SessionState enabled on the server.
If a user logs into the web site and then tries to access another page, how can I know that the user is already logged in?
I know using cookies is insecure, I thought of a mix of cookies with the session Id stored in the DB, but I suppose that if I disable SessionState I won't have access to the session id either.
What's the best approach on this? Is there any recommended book/article you can point me to so I can get this clear?
Thanks a lot for your help
I think use Forms Authentication for this this will be manage your logged in user name and you can also set authorization through this.
http://msdn.microsoft.com/en-us/library/ff647070.aspx
http://msdn.microsoft.com/en-us/library/xdt4thhy.aspx
http://www.codeproject.com/KB/web-security/formsroleauth.aspx
http://www.beansoftware.com/ASP.NET-Tutorials/Forms-Authentication-Active-Directory.aspx
These links are ans of your each question. Through this you can manage role authorization and session
It may be possible that if there are workflows that your application supports that you want to persist over application recycling (cluster node failure) you may be able to ignore the persistent Session complexities completely.
Consider an ecommerce checkout example or a similar multi-step process that requires a lot of state management before completion. The suggestion is to design the model of your application is such a way that during these "steps" the progress of the workslow is persisted to the data store natively though the model. That is, the "workfolow" is not some sort of externality to the main model of your app and as such treated as a "temporary" thing that requires some persistence mechanism like the aspnet Session as opposed to the apps regular data store (database).
For example, rather than storing the checkout object tree (lists of items, orders, etc) in Session, persist it to the database itself. This way not only does that "partially completed checkout" survive node failure or application recycling but additionally, if that user has to go put out an urgent fire in the kitchen or their Windows Update crashes their PC, they can resume when they log in next. :D
And: you avoid all that complex distributed session management stuff. Yuk!
I know this answer extends further than just the authentication point that the question actually highlights, but this is good to know and certainly a problem clustered/farm environments place on aspnet apps.
Hanselman on clustered mvc apps: http://www.hanselman.com/blog/LoadBalancingAndASPNET.aspx
FormsAuthentication and the ASP.NET user profile work without SessionState enabled--they run on cookies and database lookups by default.
For shopping cart-type scenarios I'd strongly consider just saving the data in the database and tagging users -- it lets people come back and grab abandoned carts.
What can and will break without the SessionState enabled is MVC's TempData -- it stashes things in the session between pages. But, if you just avoid using it, you are golden.
Related
I have an existing asp.net application that is currently in production for more than 3 years now. That application was developped based on internal and user requirements. That application is also using Google Analytics to detect different usage metrics to understand more what users are doing and which part of the system is most requested. But... we understand now that we are not so well connected to client's need's and more importantly, we don't receive a lot of feedback from them and when we receive feedback, that feedback is sent to many different people so most of the time they are lost or missing some valuable informations. Here is my question: is there some free (or paid) products that can be incorporated into an existing asp.net application that can provide the following functionnalities:
For my users:
Send feedbacks
Log bugs
Submit feature request
Ask questions
Be able to follow an issue, bug or feature and subscribe to it
Be able to rate answers
Be able to include attachments
Be able to vote for issues to prioritize them
Etc.
For me:
Respond to all of these issues and be able, in some way, to see and analyze all of this data to properly populate our product backlog with what user needs
My real need will be to have something like Telerik has implemented. Is there something that can be incorporated into an existing application?
Thanks in advance
What about User Voice? It's a great system to collect user feedback. Not sure if you'd get the integration you're looking for. For the rest of your requirements it seems it would work really well.
I build ASP.NET websites (hosted under IIS 6 usually, often with SQL Server backends and forms authentication).
Clients sometimes ask if I can check whether there are people currently browsing (and/or whether there are users currently logged in to) their website at a given moment, usually so the can safely do a deployment (they want a hotfix, for example).
I know the web is basically stateless so I can't be sure whether someone has closed the browser window, but I imagine there'd be some count of not-yet-timed-out sessions or something, and surely logged-in-users...
Is there a standard and/or easy way to check this?
Jakob's answer is correct but does rely on installing and configuring the Membership features.
A crude but simple way of tracking users online would be to store a counter in the Application object. This counter could be incremented/decremented upon their sessions starting and ending. There's an example of this on the MSDN website:
Session-State Events (MSDN Library)
Because the default Session Timeout is 20 minutes the accuracy of this method isn't guaranteed (but then that applies to any web application due to the stateless and disconnected nature of HTTP).
I know this is a pretty old question, but I figured I'd chime in. Why not use Google Analytics and view their real time dashboard? It will require minor code modifications (i.e. a single script import) and will do everything you're looking for...
You may be looking for the Membership.GetNumberOfUsersOnline method, although I'm not sure how reliable it is.
Sessions, suggested by other users, are a basic way of doing things, but are not too reliable. They can also work well in some circumstances, but not in others.
For example, if users are downloading large files or watching videos or listening to the podcasts, they may stay on the same page for hours (unless the requests to the binary data are tracked by ASP.NET too), but are still using your website.
Thus, my suggestion is to use the server logs to detect if the website is currently used by many people. It gives you the ability to:
See what sort of requests are done. It's quite easy to detect humans and crawlers, and with some experience, it's also possible to see if the human is currently doing something critical (such as writing a comment on a website, editing a document, or typing her credit card number and ordering something) or not (such as browsing).
See who is doing those requests. For example, if Google is crawling your website, it is a very bad idea to go offline, unless the search rating doesn't matter for you. On the other hand, if a bot is trying for two hours to crack your website by doing requests to different pages, you can go offline for sure.
Note: if a website has some critical areas (for example, writing this long answer, I would be angry if Stack Overflow goes offline in a few seconds just before I submit my answer), you can also send regular AJAX requests to the server while the user stays on the page. Of course, you must be careful when implementing such feature, and take in account that it will increase the bandwidth used, and will not work if the user has JavaScript disabled).
You can run command netstat and see how many active connection exist to your website ports.
Default port for http is *:80.
Default port for https is *:443.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I need to create a web application for tasks delegation, monitor and generate reports for a organization.
I am thinking about ASP.Net and MVC should be the architecture to support so many concurrent users. Is there any other better architecture that I should be looking for ?
What kind of server configuration will require to hold this application ?
How do I test so many users connected before I launch this application, is there any free/economical testing tools available ?
Thanks in advance.
anil
the choice of MVC versus webforms have little/nothing to do with the ability for the app to handle load. Your problems will be reading/writing to the DB, and that doesn't change no matter which of the two you choose.
ideas for improving ability to handle load:
first and foremost: absolute minimum is two servers: web server and DB server, they should NEVER run on the same box.
DB:
Efficient queries towards the DB, indexes in the DB, denormalizing tables that are hit a lot, CACHE, CACHE CACHE, running the DB in a cluster, oh, and did I mention CACHING?
Processing:
if you need heavy processing, do this in web services that can run on separate machines from the web servers so that you can scale out (buy more servers and put them behind a load balancer if needed)
WEB:
avoid the need for server affinity (so that it doesn't matter which web server serves a given user at any given time) this means using DB or StateServer to store sessions, syncing the MachineKey on the servers.
the decision of using MVC or not have NO impact on the ability to handle 10k concurrent users, however it's a HUGE benefit to use MVC if you want the site to be unit-testable
remember: Applications are either testable or detestable, your choice
Cache Cache Cache Cache :-) a smart caching policy will make even one server go a long way ... aside from that, you will need to find out where your bottleneck will be. If your application is database heavy, then you will need to consider scaling your database either by clustering, or sharding. If you expect your web server to be the bottleneck (for example if you are doing a lot of processing, like image processing or something), then you can put a load balancer to distribute requests between N number of servers in your webfarm.
For a setup this large I would highly recommend using a Distributed memory caching provider to be layered above your database. I would also really suggest using an ORM that has built in support for the memory cache, like NHibernate since in an application of this scale your biggest bottleneck will definitely be your database.
You will most likely need a webfarm for this scenario, if a single server is strong enough for it currently at some point in the near future you will most likely out grow a single box which is why it's important to architect in the distributed cache first so you can grow your farm out and not have to re-architect your entire system.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
For my asp.net web applications against sql server(at least the ones that require a logon to access) I generally implement security as follows:
I generally roll my own user signup, user login pages and keep a userid and an encrypted password in an sql server and validate the login against that table - I also provide for forgotten passwords, 'send me my password', email verification to activate accounts etc all thru custom code.
Once the user has been validated by the app (and lets assume that all users have the same privileges), I generally use a utility logonid to let asp.net talk to sql server, so in other words I only need to create a single logon id per application, and since 100% of all data access is done thru stored procedures, I need only grant access to a single user to execute stored procedures, and no other work is required on sql server. Each application has its own database, and the logon for that app can only access that database.
All this works perfectly well for me, the only negative of this is that it would be nice to be able to setup a trace in sql server and see the userid and the procs that are being called, but since all users are 'talking' to the database thru a single database logon, this can't happen.
So, two part question:
1) Are there security models are you folks using that I should consider? Its easy to always do the same thing over and over, - especially since it works - but are there other models that would work better or that I should consider? Is it recommended practice that all database access from an asp.net app would all share a single database login? or is this considered bad practice? and if so, why?
2) Assuming I stick with my model, is there a way to allow for the application login id to be seen in the sql trace window? It would be nice to see the sp's being called and the user id of the person logged into the system (not the database login).
Is it recommended practice that all
database access from an asp.net app
would all share a single database
login?
Yes, primarily for connection pooling.
In regards to 2), I normally do that by logging at the ASP.NET side.
1) It is recommended that your web application use a single login to the database typically. If you don't you are going to be forced to impersonate your caller, which is typcially not recommended, and it doesn't scale very well. You should not use a different connection string for each user. For example using SQL Authentication for each user is a bad idea. It will make connection polling ineffective.
2) You could do this by modifying the connection string but that would make connection pollign ineffective.
From a .NET best practices point of view, you may want to consider taking a look at Microsoft Enterprise Library. It contains a set of practices, patterns, and features that assist with issues such as Security and Data Access.
1)As long as you are using stored procedures for access one login may be fine. Some peolple like to use one for admin as well.
2)You could modify your stored procedures to accept a user id as a parameter.
I would generally share a single user for connection pooling.
In the case where you may need to trace a particular user. I write in admin functionality where you can make the application use a second database login. You can then enable this for a specific user and trace that user individually.
It just means you get the ability to trace as a one off, yet keeping the single user connection pooling for the rest of the application.
I've been using the same approach as well. More recently, I wonder if this is affecting the application's scaleability. My DB servers have multi-core processors and are quite capable of parallel operations, but I think SQL Server serialized queries running with the same userID. I think this means that stored procedures from different actual users are beeing queued up because SQL Server sees them all as coming from the same the same userID.
If this is the case, I'd think it would be severely limiting the scaleability of my app, no?
I am looking for a best practice for End to End Authentication for internal Web Applications to the Database layer.
The most common scenario I have seen is to use a single SQL account with the permissions set to what is required by the application. This account is used by all application calls. Then when people require access over the database via query tools or such a separate Group is created with the query access and people are given access to that group.
The other scenario I have seen is to use complete Windows Authentication End to End. So the users themselves are added to groups which have all the permissions set so the user is able to update and change outside the parameters of the application. This normally involves securing people down to the appropriate stored procedures so they aren't updating the tables directly.
The first scenario seems relatively easily to maintain but raises concerns if there is a security hole in the application then the whole database is compromised.
The second scenario seems more secure but has the opposite concern of having to much business logic in stored procedures on the database. This seems to limit the use of the some really cool technologies like Nhibernate and LINQ. However in this day and age where people can use data in so many different ways we don't foresee e.g. mash-ups etc is this the best approach.
Dale - That's it exactly. If you want to provide access to the underlying data store to those users then do it via services. And in my experience, it is those experienced computer users coming out of Uni/College that damage things the most. As the saying goes, they know just enough to be dangerous.
If they want to automate part of their job, and they can display they have the requisite knowledge, then go ahead, grant their domain account access to the backend. That way anything they do via their little VBA automation is tied to their account and you know exactly who to go look at when the data gets hosed.
My basic point is that the database is the proverbial holy grail of the application. You want as few fingers in that particular pie as possible.
As a consultant, whenever I hear that someone has allowed normal users into the database, my eyes light up because I know it's going to end up being a big paycheck for me when I get called to fix it.
Personally, I don't want normal end users in the database. For an intranet application (especially one which resides on a Domain) I would provide a single account for application access to the database which only has those rights which are needed for the application to function.
Access to the application would then be controlled via the user's domain account (turn off anonymous access in IIS, etc.).
IF a user needs, and can justify, direct access to the database, then their domain account would be given access to the database, and they can log into the DBMS using the appropriate tools.
I've been responsible for developing several internal web applications over the past year.
Our solution was using Windows Authentication (Active Directory or LDAP).
Our purpose was merely to allow a simple login using an existing company ID/password. We also wanted to make sure that the existing department would still be responsible for verifying and managing access permissions.
While I can't answer the argument concerning Nhibernate or LINQ, unless you have a specific killer feature these things can implement, Active Directory or LDAP are simple enough to implement and maintain that it's worth trying.
I agree with Stephen Wrighton. Domain security is the way to go. If you would like to use mashups and what-not, you can expose parts of the database via a machine-readable RESTful interface. SubSonic has one built in.
Stephen - Keeping normal end users out of the database is nice but I am wondering if in this day and age with so many experienced computer users coming out of University / College if this the right path. If someone wants to automate part of their job which includes a VBA update to a database which I allow them to do via the normal application are we losing gains by restricting their access in this way.
I guess the other path implied here is you could open up the Application via services and then secure those services via groups and still keep the users separated from the database.
Then via delegation you can allow departments to control access to their own accounts via the groups as per Jonathan's post.