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.
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.
we have a vb.net application with send and receive mailing also. Now we have added a session timer of 30 min but the users are complaining that they are facing a problem when they write a long text message or while composing they get busy in something else and when they return back to continue composing message , they are redirected to a session expiry page, and their long text message is gone forever. So I am new to this and I was thinking like , when the user is in compose message the text should be automatically saved to drafts like hotmail.
Any help will be appreciated . Thank you.
There are two basic approaches you can take to this:
The proper "web" way would be to remove the need for session and state from at least this part of the application i.e. set up the application so that its resilient if the session expires and can pick up the necessary user details etc from the post if the session has expired - you can do this with a value stored in viewstate or in a cookie. However this doesn't deal with the problem of saving work in progress.
So the more appropriate solution here will be to investigate AJAX solutions to the problem whereby the page uses client side scripting to transparently "save" (post) the message text back to the server at defined intervals. This has the further advantage of prolonging the session as well.
Of course with the AJAX solution your back end data management becomes more complex too... but it that's manageable (limit it to one draft in progress and remember to clear out the draft on "send" and you should be fine) and you may still want to consider some degree of additional resiliency for loss of session for other reasons.
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,
I am having ASP .Net application which is running perfectly in IE 7.0 but as due to session sharing in IE 8.0 (also in case of new window), application is giving unexpected behavior as session can be modified by other window.
Some quick facts
I know the -NoCache option and open New Session file menu item of IE 8
I just wanted to know that is there any option to disable this session sharing behavior in new window through ASP .Net code (by getting the browser) or any other solution
I also wanted to have your suggestions for future web application development, what we need to take care to avoid session sharing issue
Session sharing has always been there is not unique to Internet Explorer 8. New tabs, Ctrl-N in any browser (IE5,6,7 FF1,2,3 OP6,7,8,9,10 etc) shares the session data of the global process. It just received a fancy name because now tabs can have multiple processes on the computer (not new either), but will still "share" the sessions. And thats' kinda "new".
It is good that you're aware of this, but it's not so good if you're trying to take this "experience" or "feature" away from the user. If you want that, I'd check into JScript/JavaScript solutions instead and issue a warning when a user tries to open several sessions, but I doubt you'd get a good "prohibit sharing sessions across windows" solution. Even notable banks have already given up on this (they never liked this session sharing thing)
From a design perspective: on the server side, it is rather simple. Just always assume that the session is changed. This can, for instance, mean that on one screen, the user is not logged in, on another he is. That's ok. If he refreshes or goes to another page, you'll show him the correct view: logged in user for the same page.
Just make sure that you check for invalidated data as the result of a changed session in another window (i.e., request). But that's a general advice: be liberal in what you accept, but make sure you validate any input.
EDIT: On extra sessions: just treat them like that. It has always been possible that users open up more then one session for the same user (two different browsers). Just as it has always been possible to change a session through another tab, window etc of the same browser.
On the "solving" side: Configure the session as cookieless. This places the session in the URL query params. Any old window not having the SESSIONID in the URL will not be considered part of the session. However, a warning is in place: this approach eventually causes more trouble then it solves (i.e., now you have to worry about with and without session requests from same user, same browser, same ip and it's still possible to "copy" a session by copying the URL or tab).
Moving some of your information from Session to ViewState may help you solve the issues you are having.
I want to let the user automatically re-login in my Flex app, which uses Basic Authentication
By the way, I have noted this StackOverflow question, which is relevant, but does not address the question of logging out client-side.
For example, after user A logs in, user B comes to the browser, goes to the login screen (perhaps in a new tab) and logs in.
This should mean that I send user B's credentials in the HTTP headers, and that since these are different from user A's, the server notes the fact and creates a new and separate session.
However, Flex's HTTP proxy catches the header and actually ignores these new credentials.
Flex does offer a way to tell the server to logout, and the Flex login code could invoke this every time before sending credentials, but that seems like an ugly workaround. I want to be able to do this client-side. I could also use a non-standard header for Basic Authentication (since I control the server-side Authentication as well), but that also seems like an ugly workaround.
Is there some way to simply end the session on client-side from Flex code? This is possible from JavaScript, for example.
And is there a way to directly work with cookies at client-side, as I can in JavaScript?
I understand that some of the limitations may be caused by security considerations, but all my communication is to the "home" server, so it should be possible to avoid the restrictions.
You're sort of asking a couple of different questions here.
You can't actually end a basic-auth "session" manually per se (at least not to the best of my knowledge); at best, you can authenticate against a kind of variable basic-auth realm, which may or may not work for you, but otherwise, you're sort of stuck with the first-authenticated session for the duration of the browser instance. Generally not the best way to go, unless you're pretty sure the user owns the machine, or can be depended on to close the browser after each session.
That leaves at least two other options, then. The first is to send in your credentials with an URLRequest object (the post you cited, which I wrote, shows how to do that), and to have your HTTP response hand back something indicating the credentials were accepted -- e.g., a GUID, maybe, generated and stored in some session table (in the database sense) on the server, perhaps. Then on successive HTTP requests, you might send along that GUID in an HTTP header, or as a value in each GET or POST request (similarly to the way Facebook handles their API clients, for instance), check the timeliness of that value on the server, and if all's well, carry on. To "log out," then, you'd simply send in a request to invalidate that GUID, perform the necessary cleanup on the server and inside your Flex app, and all should be fine: the next user can sit down, log in, authenticate, and the process continues.
Another way would be to work with cookies directly. The cookie mechanisms are actually handled mostly for you in Flex, though, since everything gets passed back and forth by the browser on your behalf. For example, if you send in a URLRequest with a username and password, and the server responds with a cookie of any kind, each request you make thereafter will package and send the same cookie, so in most cases, all you need to do is parse the initial response from the server (to set the state of your Flex app), assume the continued presence of the cookie, and when it's time to log out, send a URLRequest to log out, kill the cookie on the server, on status=200 do your Flex-app cleanup, and so on. Accessing the cookie values directly isn't the easiest thing in the world, though; you can use ExternalInterface as a proxy to JavaScript (examples of this online and here on SO, I'm sure), and get at them that way, but there's a good chance you don't even have to do that.
Hopefully that helps. Good luck!
Note also this post, which details some of the incredible distortion that Flex adds to HTTP Requests.