Is there any standard way of creating and reading a machine-level (not user-specific) cookie-like persistent setting? Thus, if the value is set while user X is browsing, then if user X logs off the machine and user Y logs in and goes to the same site, the value set during user X's session can be read?
This is for an internal application. I have done something like this using ActiveX controls in IE, but we do not want to have a dependency on IE but rather be able to support Chrome and other browsers. It is OK if each browser has their own implementation; they do not have to be able to share the value across browsers.
Even a read-only solution could work, as an admin user could do the creation phase out of band, as long as the setting could be read by all users' sessions and sent with an HTTP request.
Related
I've an ASP.NET web site that uses FormsAuthentication and a standard Session mechanism. In one of it's webpage the processing(on click of refresh button grid rebinds) is base on session value.If i leaves the screen open for a 'long time' and then tries the refresh. Nothing refreshes.It because session value expires.
So is there any way, i can set configure setting in web.config and synchronize both authentication cookie timeout and session timeout ?
In web.config, set the timeout value of the sessionState element, and the same value in the authentication element.
First, see this SO thread for your answer.
You can attempt to "synch" - perhaps by logging in and setting session vars in the same method, but that's not really a "setting"....
What follows is just my take/opinion that expands on that answer.
IMHO, I think you need to rethink what each type of "storage" is for. Forms Authentication is exactly for that purpose - authentication to some "content" or "resource" that you deem needs to be protected.
Session is more for exactly that - e.g. because some data/resource is "volatile" (changes within x time) - the usual example for this is if you have an ecommerce site, you have to track inventory changes for availability of a product (inventory changes because of purchases/returns made by users, while other users are browsing/shopping). That or the simpler process of users adding items to a cart (sessions and/or cookies, aka "persistence").
Its important to know that on the client (browser), cookies are the primary mechanism for sessions (or url for cookie-less sessions).
So depending on what content/resource it is you are referring to, change the process depending on which of the 2 types they fall under.
if it's a protected resource then display/access should be controlled by your auth scheme
if it's volatile/changing content/persistence needs, then sessions or just cookies might fit the bill (or newer client side storage)
if it's both (protected and volatile) then, auth first and then whatever mechanism fits the bill for volatile/persisted content.
Hth....
Relatively simple question regarding the value of session ID - Session ID is tied to a specific instance of the browser, correct (instance meaning window)? So I start with an empty desktop (WinXP or Win7 or whatever client O/S). I open an IE browser window and request a web page from an ASP.NET website. I then open a second IE browser window and request the same web page from the same ASP.NET website. (1) I assume there will be 2 different session IDs, one for each of the two IE browser windows, correct? Then, I open an additional tab within one of the IE browser windows. (2) Will that additional tab have the same session ID as the browser window, or will it have a third unique session ID? I know I could do a little testing to look at this but I need to answer a boss's question right away LOL - so I figured someone could probably just answer this question off the top of their head. TIA!
The session cookie is created per browser instance, not per browser window. If you open 3 Internet Explorer windows they will all use the same session ID.
That session ID is kept around for other requests, regardless of whether a request comes from the same window or a different window within the same instance of the browser.
By default, "instance" refers to the browser until all windows are completely closed. This can be extended, but keep in mind that sessions also remain in memory on your server (by default, this can be changed as well) so you could impact performance if you configure sessions to remain alive for too long.
When you open a new tab, they share the same session. If you want new session at the same time, you should open the site in a different browser.
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.
Inside a flex app, I have a user login. The login calls a ColdFusion function as a remote object which authenticates the user and, if applicable, returns their id and access level.
This works fine, but now I'm at the point where I want to also create a cookie for another ColdFusion template (called from fileReference.upload()) to be able to access later.
I have tried several different methods for creating the cookie -- cfcookie, creating a cookie with JavaScript inside the ColdFusion function, and creating the cookie with JavaScript with an external interface once the coldfusion function returns to the flex result handler. All of these have been tried with a plethora of options regarding expiration, path, and domain tags.
Any of these seems to work for cookie creation. Cookies show up in listings for my domain in Chrome as well as in a Firefox add-on 'View Cookies 1.9.2' that I've installed just for this purpose. Yet, still, none of these cookies seem to be readable by my upload.cfm when it is called later.
The upload.cfm, once called by a file upload request, sends the user id along with the file. From here, it should be a simple comparison between the id sent with the file and the id from the cookie. So far, the upload.cfm template has been unable to find the cookie (with any of the creation methods) looking at the obvious #cookie.name# or even #name#.
I'd appreciate any insight into why this is occurring, or perhaps an alternative method to the security I'm attempting to implement.
Thanks for reading,
-cs
Have you done most/all of your testing in a browser other than Internet Explorer?
Unfortunately, there is a bug in the Flash player [login required], which can be summarized as:
(In browsers other than Internet Explorer) The flash player uses a different network stack than the browser, and therefore...
Requests made by the flash player have a different server-side session than, for example, the request for the page that embeds the flash player.
This causes a situation whereby session variables set by the page are not (easily, by default) available to remote requests made by the flash player on the page.
CFID and CFTOKEN are set as cookies as well as stored in the session.urlToken variable. (JSessionId is included as well, if you're using Java session management).
I'm not positive, but I think this may be the root of your problem.
I believe that if you pass the CFID and CFTOKEN (and JSessionId) values to your Flex application as FlashVars, and then include them in the remote requests to the server, that the cookies you're setting will be available to later remote requests by flash (i.e. your upload).
We have an asp.net 3.5 web app that we must start load testing with LoadRunner
What we have found is that if you open several browsers (ie8) they share the same session id, so making a change in one window impacts the other windows (not just our app, others app also).
Now, LoadRunner can simulate a number of users per pc, and so we are finding its getting messed up since its all sharing the same session.
Any ideas on what is the best method to prevent this (we don't want to go with cookieless sessions).
How would you ensure each browser window is treated as a unique session?
This is a 'Feature' of IE8 :-S.
You can however start IE in a "start with new session" mode though. use:
iexplore.exe -nomerge
Not to sure how this would be applied to LoadRuner though (Never worked with it)
session/state is unique to a single user, but not across users. You will need to correlate both session and state data across your scripts and then you should be able to execute mutiple users on a single load generator without issue
Whether a new browser session is opened is purely a client side issue. The server does not know or care that a different browser session has been instantiated and is only responding to a valid request as indicated by session token, security token, state token, etc...
While replaying scripts in loadrunner, it doesnt invoke the IE and it wont have impact of the tabs.
Use the setting Check for newer versions of the stored pages every visit will help on this issue.
Also you can put clear cache and cookies before each iteration.so that each time new sessions will be created.