In Flash, I have the ability to save certain info onto the server.
Now the problem is the user needs to be authenticated as admin in order to do so.
I can't use sessions, since if you work longer than 20 minutes in the Flash application,
the session is gone.
The way I see it, I have 2 possibilities:
1. passing a parameter (bIsAdmin) to Flash from the Website.
2. Launch a http-get request, to get this value (bIsAdmin) from an ashx handler
on application startup, when the session has not yet exired.
In my opinion, both possibilities are not really secure...
So, which one is safer, 1 or 2?
Or does anybody have a better idea ?
In my opinion, 1 is safer, because with 2, you can just switch a packet tamperer in between,
and bang, you're admin, with permission to save (or overwrite, =delete) anything.
Both are insecure. Analyzing the Flash code any user can discover the presence of the blsAdmin parameter and try generate the request to gain admin privileges.
Remember that the Flash applications can be decompiled and analyzed by anyone using tools as Flasm or SWFDump.
My solution? Use sessions to store the admin privileges. If the session is going to expire in 20 minutes generate a request every 10 minutes to a dummy page in the server to keep the session alive but this is also a bad practice. If you are an admin user you don't have to leave your application unattended in any moment without logging out when you finish using it.
Ta Ta,
Related
Problem description
I have an ASP.NET app in which the users have different rights, and are logged in through Facebook. The app includes (among other things) filling out some forms. Some users have access to forms others don't. The forms can sometimes require some searching in books and/or on the internet before being able to submit them.
As such, we're having problems with session time-outs (it seemed), where users would be met with "Not authorized to see this page/form" after doing research somewhere else.
Attempted solutions
I've created a log function that logs the state of a handful of variables on strategic points in the application. I've pinpointed the problem to the fact that the Session variable "UserRole" is null when the problem occurs.
Relogging
The obvious solution is: "Have you tried relogging?" - which should reset the session and allow the user back to the form they want. On logout, I use
Session.Clear();
Session.RemoveAll();
and I create a new session with relevant variables (including UserRole) on login. This doesn't help, though.
Keeping session alive
One way to do it is just increase the standard 20-minute Session length to an arbitrary, higher number (say 2 hours). Although that could be viable during beta (there are only around 5 users right now), it is not a viable solution in the long haul as the server would have to keep the Session objects from many users for longer time, exponentially increasing server demands.
Instead, I created a 'dummy' .ashx handler "RefreshSession.ashx", that can recieve a POST request and return "200" statuscode. I then created a jQuery function in the shared part of the app (that all the pages use) that calls this handler every 10 minutes in order to refresh the session as long as the tab is open in the browser. I've checked the network traffic, and it works as intended, calling the handler even if the window is minimized or the user is viewing another tab. This did not solve the problem either.
A caveat
When one of the users encounter the problem, they call me or my programming partner up. Of course, we go and see if we get the same issue. We all have the same (admin) rights. The 'funny' thing is that we see the exact same error on the same subpage - even if we haven't had any contact with the application for days.
The problem will 'fix itself' (i.e. let users with proper role back on the subpage) after a while, but not even republishing the app to the server will reset it manually.
Therefore, it seems to not be a simpel session error as supposed from the "UserRole" session variable being null after 15-20 minutes of inactivity. It seems to be saved somewhere internally in the server state.
My problem is, that I now have no idea where to look and how to progress. I was hoping that someone here might have an idea for a solution, or at least be able to point me in the right direction? :-)
Thank you all for your time, it is much appreciated.
Based on MaCron's comment to the question, we decided to keep the information in the user's cookies instead of the session variables. Everything seemed to point to us having exactly that issue, and deadlines being deadlines and with me not being able to figure out how to disable the synchronization of worker processes, this seemed to be a feasible and comparatively easy fix.
As far as I know it is not possible to invalidate or drop a specific (or multiple, say, based on a user name) Domino HTTP Session(s) (darn IMAP). Is there / what would be a proper workaround / mechanism to somehow drop / invalidate Domino HTTP Session(s)?
Some example cases could be:
Same user, two sessions, in one of those the user changes the HTTP Password (at this point all other sessions should be immediately invalidated). If he/she continues working / browsing in the other (browser)session (at some point) you get the "authentication failure using internet password" message on your console, and if you're in a bad luck the user gets locked out.
Facebook-style; have an overview of your current active sessions. One step further, if they see a suspicious session based on IP/Location, giving them control of invalidating it.
A client calls; "I got the feeling my session is hijacked".. First response; "you are a smart user, aren't ya?". Subsequently you want to drop those sessions with that user name (via console or "admin" web interface).
...
You would have to take control of the authentication process, which could be done using the DSAPI interface that is described in the Notes C API documentation. I've only done some pretty minimal DSAPI work myself, but I understand from others who have worked with it extensively that advanced work with DSAPI is definitely not for the faint-hearted. You might want to look into some 3rd party products (e.g. from PistolStar) that may provide at least some of the functionality you are looking for.
I want to limit concurrent access to internet or intranet web applications.
I want to be able to allow certain number of concurrent access, let's say I want to allow maximum 20 concurrent access using the same username.
I can imagine creating a session at the login time and save it into DB with incrementing a counter, but there is no way to delete it from the DB and decrement the counter if user is logged off, as user may just close the browser.
Guys, what is the best way from your opinion?
Thanks,
You are right in that you cannot know if a user just kills his browser or pulls the cord.
Create a timer that does an Ajax call every 30 seconds and log it. If a user isn't in this log for 60 seconds - throw'em out at the server.
This won't stop someone from leaving their browser open over the night and hogging a slot though.
There is another answer mentioning an "last active" field. This on the other hand messes up when someone needs to leave their browser open to look at something for more than the timeout limit of minutes.
If someone is thrown out due to the user/timeout limit; I think it would be nice to have them automagically logged in again totally transparently if there is a slot open again.
Without thinking too hard about it I believe this solution will give birth to other problems.
Edited away:
As I commented - 20 users - are you really solving the right problem?
You may wish to have a "lastactive" field on your session. When someone attempts to log in or otherwise create a session, you can query for all sessions that have been active within a period of time (say 15 minutes), and use the resulting count to tell you how many concurrent sessions are active.
I'm running a website on a shared ASP.NET 4.0 server.Therefore I only have limited memory size to store my users' session state.
The program I've written doesn't use Session variables: once a page is ready it is sent to the user and voilà. The rest is JavaScript and when the user click a link, I don't care if a new session is to be opened.
The question is: what if I reduce the session timeout to say 1 muinute only?
Will the user suffer from extra delays?
What if I go sessionless?
Since I do not use login-password for the users, I'm suspecting it won't impact the performances. Am I right?
Is there any cave at?.
Thanks.
Sessions are only needed if you need to store some "state" - to "remember" or "know" something about a specific client (user/browser) on the server-side (you can use cookies on the client side).
If you have no need to do so, you can turn off sesssions..
For MVC (note the comment by Brad Wilson for MVC2)
By default the session expiry seems to be 20 minutes.
Update: I do not want the session to expire until the browser is closed.
Update2: This is my scenario. User logs into site. Plays around the site. Leaves computer to go for a shower (>20 mins ;)). Comes back to computer and should be able to play around. He closes browser, which deletes session cookie. The next time he comes to the site from a new browser instance, he would need to login again.
In PHP I can set session.cookie_lifetime in php.ini to zero to achieve this.
If you want to extend the session beyond 20 minutes, you change the default using the IIS admin or you can set it in the web.config file. For example, to set the timeout to 60 minutes in web.config:
<configuration>
<system.web>
<sessionState timeout="60" />
... other elements omitted ...
</system.web>
... other elements omitted ....
</configuration>
You can do the same for a particular user in code with:
Session.Timeout = 60
Whichever method you choose, you can change the timeout to whatever value you think is reasonable to allow your users to do other things and still maintain their session.
There are downsides of course: for the user, there is the possible security issue of leaving their browser unattended and having it still logged in when someone else starts to use it. For you there is the issue of memory usage on the server - the longer sessions last, the more memory you'll be using at any one time. Whether or not that matters depends on the load on your server.
If you don't want to guesstimate a reasonable extended timeout, you'll need to use one of the other techniques already suggested, requiring some JavaScript running in the browser to ping the server periodically and/or abandon the session when a page is unloaded (provided the user isn't going to another page on your site, of course).
You could set a short session timeout (eg 5 mins) and then get the page to poll the server periodically, either by using Javascript to fire an XmlHttpRequest every 2 minutes, or by having a hidden iframe which points to a page which refreshes itself every 2 minutes.
Once the browser closes, the session would timeout pretty quickly afterwards as there would be nothing to keep it alive.
This is not a new problem, there are several scenarios that must be handled if you want to catch all the ways a session can end, here are general examples of some of them:
The browser instance or tab is closed.
User navigates away from your website using the same browser instance or tab.
The users loses their connection to the internet (this could include power loss to user's computer or any other means).
User walks away from the computer (or in some other way stops interacting with your site).
The server loses power/reboots.
The first two items must be handled by the client sending information to the server, generally you would use javascript to navigate to a logout page that quickly expires the session.
The third and fourth items are normally handled by setting the session state timeout (it can be any amount of time). The amount of time you use is based on finding a value that allows the users to use your site without overwhelming the server. A very rough rule of thumb could be 30 minutes plus or minus 10 minutes. However the appropriate value would probably have to be the subject of another post.
The fifth item is handled based on how you are storing your sessions. Sessions stored in-state will not survive a reboot since they are in the computer's ram. Sessions stored in a db or cookie would survive the reboot. You could handle this as you see fit.
In my limited experience when this issue has come up before, it's been determined that just setting the session timeout to an acceptable value is all that's needed. However it can be done.
This is default. When you have a session, it stores the session in a "Session Cookie", which is automatically deleted when the browser is closed.
If you want to have the session between 2 browser session, you have to set the Cookie.Expired to a date in the feature.
Because the session you talk about is stored by the server, and not the client you can't do what you want.
But consider not using ASP.NET server side session, and instead only rely on cookies.
Unfortunately due to the explicit nature of the web and the fact there is no permanent link between a website server and a users browser it is impossible to tell when a user has closed their browser. There are events and JavaScript which you can implement (e.g. onunload) which you can use to place calls back to the server which in turn could 'kill' a session - Session.Abandon();
You can set the timeout length of a session within the web.config, remember this timeout is based on the time since the last call to the server was placed by the users browser.
Browser timedout did not added.
There's no way to explicitly clear the session if you don't communicate in some way between the client and the server at the point of window closing, so I would expect sending a special URI request to clear the session at the point of receiving a window close message.
My Javascript is not good enough to give you the actual instructions to do that; sorry :(
You cant, as you can't control how the html client response.
Actually why you need to do so? As long as no one can pick up the session to use again, it would expire after that 20 minutes. If resources does matter, set a more aggressive session expiry (most hosting companies did that, which is horribly annoying) or use less objects in session. Try to avoid any kind of object, instead just store the keys for retrieving them, that is a very important design as it helps you to scale your session to a state server when you get big.
Correct me if I am misreading the intent of your question, but the underlying question seems to be less about how to force the session to end when a user closes the browser and more about how to prevent a session from ending until the browser is closed.
I think the real answer to this is to re-evaluate what you are using sessions to do. If you are using them to maintain state, I agree with the other responses that you may be out of luck.
However, a preferred approach is to use a persistent state mechanism with the same scope as the browser session such as a cookie that expires when the browser is closed. That cookie could contain just enough information to re-initiate the session on the server if it has expired since the last request. Combined with a relatively short (5-10 min) session timeout, I think this gives you the best balance between server resource usage and not making the user continually "re-boot" the site.
Oh you have rewritten the question.
That one is absolutely feasible, as long as javascript is alive. Use any timed ajax will do. Check with prototype library http://www.prototypejs.org PeriodicalExecutor or jQuery with the ajax + timer plugin. Setup a dummy page which your executor will call from time to time, so your session is always alive unless if he logouts (kill the ajax timer in the same time) or close browser (which means the executor is killed anyway)