I have a couple of use cases where I would like the actions of a given user, like an administrator, to alter the experiences of other users in realtime. For example, there are actions that happen on login that place data in a session, and I'd like to be able to modify that session, or just force everyone except admins to log out upon their next request. I understand the security implications of implementing such things.
Is there a direct interface / utility method in Spring that will allow me to get another user's session, and then add to it? Moreover, can I wire up a Spring event that will fire to all sessions, not just the one that initiated it?
Related
This question applies to both ASP.NET webforms and MVC apps. I have a checkout process where there are two forms Form A (address page) and Form B (shopping cart page). The normal happy path works where the customer completes the Form A and then click submit button which takes him to the Form B.
The customer can accidently visit the Form B without ever visiting the Form A or completing the information. How can I find out whether the customer has completed the Form A if he access the Form B directly? If he has not completed the Form A, I want to redirect him to Form A. Is there a ASP.NET framework object that I can use for this purpose?
The only foolproof way is to save something to a database that indicates that the particular user has completed Form A. This could be actually storing some entity that is created by Form A or just some sort of log. The key is that you'll need to associate with the user, which means the "user" must actually have an account and be logged in. If it's anonymous, there won't be any real way to track them.
With this set up, then, you'd simply check in your database that the user has a record indicating they've completed Form A in the controller action for Form B. If nothing exists, you redirect the user to Form A. Otherwise, you allow them to view Form B.
And alternate approach is to use Session or set a cookie to indicate that Form A has been completed. There's pros and cons to both of these, and neither is foolproof. With both Session and a cookie you can track anonymous users, so you don't have to force a login. However, Session is not a permanent data store. By default, it will expire after 20 minutes of no activity, and even if you bump that timeout up significantly, it's always going to be finite.
Additionally, depending on the session store you use, it can also be very volatile. In Proc is the default, as it requires no configuration. Everything is stored in memory, but if the server restarts, App Pool recycles, etc. then all the session data is lost. It is possible to configure it to use something like SQL Server, though, and that would be very stable. Either way, you'd still have the timeout issue to deal with.
With cookies, you can set a far-future expires cookie that would effectively be permanent. However, cookies are stored client-side and can be removed by the user. They can also be manipulated (either created manually or modified). This means if a malicious user figured out how you were tracking whether Form A had been completed, they could basically fake that, and make your site think they had completed Form A, when they had actually not. Now, whether any one would care enough to do that is an entirely different matter. Still, it's something to consider.
Finally, both Session and cookies can effectively be disabled by the user. Session actually uses a cookie to store the session id, so if the user disables cookies in their browser, neither approach will then work.
Your best bet is still forcing a login and storing something in a database to indicate that Form A has been completed by that authenticated user. However, if you can deal with or mitigate the downsides of using Session or cookies, then those might be viable options.
I am working on a small web application right now and part of the requirements is to allow the user to pick how their session will be managed: with either cookies or HttpSessionState. I have researched how to use cookies (http://www.codeproject.com/Articles/31914/Beginner-s-Guide-To-ASP-NET-Cookies) and Sessions (http://msdn.microsoft.com/en-us/library/ms178581(v=vs.100).aspx). I will be using non-persistent cookies.
The application will collect some data about the user (name, age, school) and take this session data and display messages on another page depending on the data that the user entered.
The thing I am having problems with is how to deal with how the user will pick the management. That information is also part of the session! The selection will be checked on every page on the web application.
I have researched globals (http://www.dotnetperls.com/global-variables-aspnet) but that is not a good method because it can be shared among different users which is not what I want! Correct me if I am wrong. How can I store this data temporarily through the session without actually using a session or a cookie?
Is it even possible to do this with cookies and sessions being mutually exclusive?
At the end of the day, you should save it somewhere. This option if it is not persistent, as it may be asked/changed by every time user visits the web site, the easiest way is to save it in a hidden html field. As user submits the forms, the value will be passed to the next page if you are using html forms. Or you can retrieve the value and send it manually in asp.net (e.g. Transfer).
You may use ViewState (not recommended) as well. If the information should be persister for future, try using User Profiles in ASP.net and save it as a custom field in database. This one is really cumbersome.
How does Symfony's security component work?
Currently, I grab user login data, auth them against a database, and store their info in a session variable to log them in. When a user accesses a page, it checks their session to ensure they have rights to view a specific page. All of this is organized into services.
I've been looking into Symfony's security component but can't figure out exactly how it works. Specifically, is there some extra security benefit (I have an admin panel that I need to have proper security on) that it offers?
I also hate learning framework specific stuff without understanding what's going on, so would appreciate a general breakdown of how the component works.
Thanks
This video is a good resource of how the security component works. The video is from the Symfony live conference in Paris last year. The speaker Johannes Schmitt is the one who has led the development of the security component.
http://www.youtube.com/watch?v=lSxgEK8WKGA
Security is a two-step process whose goal is to prevent a user from accessing a resource that he/she should not have access to.
In the first step of the process, the security system identifies who the user is by requiring the user to submit some sort of identification. This is called authentication, and it means that the system is trying to find out who you are.
Once the system knows who you are, the next step is to determine if you should have access to a given resource. This part of the process is called authorization, and it means that the system is checking to see if you have privileges to perform a certain action.
More information can be found at :
http://symfony.com/doc/current/book/security.html
In my application I have the requirement to store, for the period the user stay logged in, some variables that's used to provide a customized experienced on how the user views it's data (pre-defined filters, language, etc.). My needed data is not more than 1Kb.
I have read many blog posts that definitely encourage to not store this data in the Session object. In many of these blog posts the authors suggests to use TempData instead.
As I understand TempData is a good choice for short-lived temporary data and not suitable for caching data during all the period the user stay logged.
Does am I wrong? What is a good alternative suitable to my scenario?
thanks for helping :)
Two options:
Cookies
Database
If this information needs to be stored only for the time the user is logged in and you don't want to persist it when he comes back cookies would work just fine. If on the other hand you want to persist the user's customized settings then you need to store them in the database or use persistent cookies.
Session is also an option but be careful if your site runs in a web farm - in this case you will need an out-of-proc session persistence.
As I understand TempData is a good choice for short-lived temporary data and not suitable for caching data during all the period the user stay logged.
You are absolutely right. TempData should be used only in the following scenario: a user calls a controller action, this controller action stores something into the TempData and immediately redirects to another controller action (it never renders a view) which fetches the stored data and renders a view (Redirect After POST scenarios).
How do i keep checking if a user still is active, for like every 1 minute? I need to know which user is currently active and who is not! I'm not using ASP.NET membership provider!
Lets say, maximum 3 log in are allowed for one user to log in simultaneously from 3 different locations, if the same user, which is the 4th log in, try to log in from another location again, i would like to block the 4th log in.
I have few issues regarding this as well! If the user unplug the connection cable or close the browser, how do i figure out if the user is still active?
I would need more detail about exactly what you are trying to accomplish, as you have asked a fairly vague question. However, I would think the best way to determine if a user is active is to check if their ASP.NET session is still alive. There is no "accurate" way to test if a user is still browsing your site, because they could be sitting there reading, or be AFK, or be in another program on their computer...dozens, if not hundreds of scenarios could exist on the client side.
However, the user's ASP.NET session will only live for a specific period of time between each activity from the user (GET, POST, etc.) Usually after 20 minutes, ASP.NET will clean up the users session, and when it does, it will fire a Session_End event that can be handled either in Global.asax, or with a custom HttpModule. You would then be able to flag that user as inactive in your own database, send an email, or do whatever it is you need to do.
You can use the HttpResponse.IsClientConnected property to check if the user is still conncted to the session. For details see this -->
http://msdn.microsoft.com/en-us/library/system.web.httpresponse.isclientconnected.aspx
Alternatevely, you can set a counter at Session_OnState at global.asax to check for the active session available and do your stuff based on that.