I'm writing an asp.net Web Application. I wrote a login page that authenticates a user and stores their UserID in the Session["UserID"]. Every page in the web application will check for a valid Session["UserID"]. If not valid, then redirect the user to the login screen.
This works great, but it's slowing down my ability to debug every page on my website. Each time I make a change to a *.cs file, I need to press F6 to rebuild my solution. Doing this destroys my session, which means I need to go back to the login screen, type my username and password, click to the page I was working on, do my tests, make code changes to my code, and repeat.
Is there a way to keep my session alive everytime I re-build my solution so I don't have to go to the login page every single time?
Unfortunately, I don't know that you will find any way around this limitation. Every time you build your project, you are going to trigger a restart of the web application. Even if you were to use a persistent store for keeping sessions, you're going to lose the session cookie being set in your browser.
You could add a "remember me" feature to your app. You'd need to do a little reimplementation, in order to keep the information about the current user authentication in a data store that is less volatile than ASP.NET session state. Also, you'd store the index to that information in a cookie that is more persistent than a session cookie.
That's the best I can think of, or at least it's the best I can think of without some significant extensions to the .NET security providers. However, take it with a grain of salt -- I've never tried to solve this particular problem before, and I hardly consider myself an expert in all things ASP.NET session-related.
The reason why you lose your session is because your application is restarted when you write to the application folder. In fact the same thing happens when you publish your application, every user currently logged in will lose their session.
This is intentional because they have no way of knowing that the DLL's you were using in your page are still there or not. So instead they monitor the folders themselves and trigger a restart when you write to them.
There is no workaround for this. It's in fact a feature that saves you time (most of the time), imagine tracking down memory corruption errors because the pointers moved around in your code!
Related
I have a laravel webapp and I check if the user can perform certain actions or access certain information at every step of the way not just during the login. For example when they wish to view their assets I check for their UAC, after they click on them I check again, even if the edit, delete buttons are not visible, there is still a check in place in the code. And this pattern continues throughout the whole webapp. Is this overkill, will it make my webapp too cluttered with checks all over the place?
Yes, it is. Every time you don't check for access before performing a privileged action, you take the risk that an intruder might find a way to bypass your earlier checks and somehow trigger that action without actually having proper access to it. A few extra checks are a small price to pay for robustness and peace of mind.
In particular, you should always re-check privileges on the server for each new request made by the client, since you should never trust user input, and since everything the client sends to the server is potentially under the user's control. For example, even if you disable the "edit" or "delete" buttons in the client interface, what's to stop a malicious (or even just inquisitive) user from re-enabling them e.g. through their browser's developer tools, or even from simply spoofing the actual edit/delete request that the button would trigger?
If you're lucky, all a missing server-side privileges check will do is let some user see a bunch of deleted garbage. If you're not so lucky, it might give them full admin access on your site.
It is indeed a good practice and middleware can help you achieve this goal more easily.
Check the Laravel documentation for more information
I was wondering if it ever would make sense to have two concurrent sessions in the same browser? There could be two types of cases with this:
1) A user opens a browser window and logs in as user A, starting session 1. Then he opens another browser window (in the same browser) where he logs in as user A, but starts a different session, session 2.
I know that this is often not possible in many browsers, as one session cookie is set for the entire browser. However, in some browsers, it is possible to have multiple sessions in that manner.
2) This is similar to 1, except that the second time the user logs in, he logs in as user B, starting session 2. So now you have a person logged in as two users in the same browser.
Finally, allowing these things doesn't seem like the best security practice and neither does it seem to be practical. What do others think?
First thing First as the your Assumption is wrong. First of all you have to understand that when Single website is accessed from browser have single session and its not possible to simultaneously run different session of same web Browser.
It seems you have wrongly understand the working of Private Browser. Private Session are not made not to share information cookies and data with other public session and vise versa also. As soon as you close the Private Session all the Cache, Cookie and other things are deleted for forever.
I have not seen any web browser supporting the Multiple session of browser.
But an alternative approach is available i.e you have to create different Web Browser Profiles which can help you as each Profile data is maintained separately and have no conflict with other sessions.
One possible scenario currently I am facing requires allowing multiple user sessions from the same browser and I have not been able to find a proper solution for it yet.
We are using Yii framework. Currently we have two kinds of users i.e customers and admins. Both login from the same login form and use same session name and variables to store session information. Only based on type column in user table(customer or admin), the user is taken to appropriate views. In one of admin views(pages), there is an option for admin to log in as any of the users and propagate through the user's view in an iframe. The problem is that when the admin open two tabs and logs in as two different users, the session information of one overwrites the other and we start getting session related issues.
Can anyone suggest me a proper way to handle these kind of issues. I have searched a lot on trying to handle this with multiple sessions, but have not been able to find a proper solution yet.
There's nothing to "provide support for" here. One browser cannot hold more than one session, since it only holds one unique cookie per site, regardless of window. If a browser actually has a mode in which it supports holding two separate identical cookies per site, then it's the same as if the user logged on from another browser or another machine. That certainly should work; i.e. you should not try to subvert that behavior. A double session inside the same browser is then just a specific instance of this multi-session behavior, nothing special.
Here's the issue at hand: I have developed an ASP.NET MVC3 application using Razor. I have also implemented a custom membership provider and overridden the ValidateUser() method. Within, I query my db and get a lot of user information in addition to the password auth.
At the moment, I am pushing this information, i.e. companyId, to static properties of a class. This works and I can display/use this information throughout my app. The problem arises when a user closes their browser tab. Upon re-opening the app, the user is authenticated via a cookie, so they don't need to re-login; however, those static variables are blown away.
So guys and girls, how would/do you conquer this issue? Should I append the extra info to the session cookie? Or perhaps a better solution?
Use the ProfileProvider in ASP.NET.
For application level variables, they are going to be subject to application pool recycles and similar "simulated" restarts related to users starting all over. These variables should be completely independent of user usage and should be able to be recreated easily. If you have variables that are user dependent or that can't be restored easily without some sort of outside intervention then you will definitely need a different method of storage.
If the data is user specific, storing it in the session cookie is probably the best idea. If the data is user-related but branches multiple users it should be stored in a database or a flat file somewhere. If the data has nothing to do with users specifically then it should just be in a database or configuration file.
I have implemented custom membership provider in my project. i kept one flag on database to get the users online. i want to reset this flag on the log out, i can do this if the user log out properly . I have to reset the flag on database even if the the browser closed directly or on any machine failure or normal time out, any tricks on membership provider to solve this. experts am waiting for your answers!!!!!!!
Thanks.
just put a field for users like IS_LOGOUT_BUTTON_PRESSED typeof(bool) default false
if the user click LogOut set it TRUE.
if the user closes browser, it will stay false. Then you can see what user did.
I am afraid that you are tilting against windmills.
You will notice that the sql providers implement the 'users online' by simply updating last activity in most all provider methods (and subsequently the stored procedures) and then using a predefined 'online time window' to determine if the user may still be online.
To implement an authoritative 'is_online' flag would require that you have complete control over the user's means of starting a session and ending a session, which you do not and can not do due to both the nature of the browser ui and the way that sessions and ticket expirations are bumped.
So you can never really be sure whether a user is online or not, rendering any efforts you have made to track this metric unreliable.
And unreliable data is often of less value than no data at all.
I am quite certain that you will find nothing but frustration in attempting to apply an absolute, as described in your question, to the stateless and freeform nature of sessions and tickets.
Sorry I have not better news.
I'm trying to figure out exactly when the event Profile_MigrateAnonymous fires.
My best guess from just tracing through my code is that it fires when it detects BOTH an anonymous membership cookie AND an authenticated membership cookie. Can anyone confirm this? I'm looking for real in depth answer here. Not just it gets called 'when a user logs in'.
Now - why do I care?
I was trying to keep the anonymous profile hanging around after a user had authenticated so that once they log out I'd still be able to tell who they were, and certain settings that may have been set.
The problem I'm seeing is that Profile_MigrateAnonymous is getting fired on EVERY request. Not just when a user has logged in. This makes me believe it to be a bad practice to keep the anonymous cookie hanging around - and that I should always call ClearAnonymousIdentifier();
For instance I have a new store and an old store. I want users that have access to the 'new store' to never be put back on the old store. Obviously - as with most shopping carts you don't need to autenticate to begin a session. Therefore I think the only way is to call 'ClearAnonymousIdentifier' as designed but keep a secondary cookie 'UseNewStore' to track which store they should go to.
is this a good interpretation. Or should I just not care that Profile_MigrateAnonymous is being called all the time?
Don't bother with it. There is a simpler way
Migrating Profile Properties During Log On
http://msdn.microsoft.com/en-us/library/taab950e.aspx