I have a situation where a part of some code depends on fetching a value out of the ASP.NET Session State. This works fine in all major browsers, however I one client that, for whatever reason, uses the AOL web browser, and it seems to be incapable of understanding this logic.
Every time there is a call to the session state in the code, even on the server side, the page throws an exception for them. This is easily remedied by simply having them use another browser - but I am wondering, is there a way to get around this sort of behavior?
By default the session is stored in a cookie. Maybe this aol browser is blocking all type of cookies? If this is the case, maybe he can relax a little this feature or you can change the persistance to sql.
Reposted just to mark the question closed and answered
Related
Have PHP/mySQL/JS-JQuery based web site that records finish times for racers, then sends the time back to the server. The server inserts the finish time in the db, Calculates the finish place based on a handicapping formula. Stores that and send the finish place back to the web page and it is updated on the screen.
It uses Jquery Ajax calls so the page doesn't get reloaded at all.
Everything works fine if the data connection is good.
If the data connection is bad my first version of this page would put a message up that the connection was bad.
Now I am trying to make it a bit smarter, so I have started with the HTML5 feature that tells the browser if it is on or offline(i realize this may not be the best way yet but it works for concept testing)
When a new finish time is recorded(or updated) and we are offline the JS just adds a class of notSent to the tag of the finish time. The finish place and all of the finish places would normally come from the sever are greyed out indicating the data is no longer valid(until it can communicate with the server).
When the browser finds itself back online, A simple jQuery each loop on each notSent class starts re-sending the AJAX requests and if they all get completed it processes the return finish place information and display it as up to date.
It also disables all external links on the page when the browser is offline. This keeps the user from losing the data entry page by accident by clicking a link that will give them a page not found button.
So my last issue, is the browsers reload and close buttons, if the user click these when it is offline they will lose the data entry screen and are out of luck until the connection comes back.
Can I disable these functions as well? A quick Stack-overflow search of this indicates it can be done but most answers give the old, "you really shouldn't and if you think you need to you should rethink your design." warning.
So rethinking my design I start learning about;
HTML 5 local storage (decide I don't need it, since my data is stored already in a input box)
App-cache Manifest for controlling the cache of the page so if reloaded in the browser off line if would get that cached version. After much reading came to the conclusion that this could work on a static page but not mine where the data is updated all the time. Then found that most browsers are deprecating this anyways.
Service Workers seems to be the possible future for contorlling offline caching, but not all browsers support it, it is pretty cumbersome to learn and still very new.
Now I am stuck, Leaning towards preventing browser reloads and defering learning service worker till more support and better examples for a dynamic content pages like mine.
Bottom line- am I missing something here? Is there a easy solution?
I think the best option is to use PouchDB to sync between the client and server and use Background Sync to awake a Service Worker when you regain connectivity. If Service Worker is not present in your browser, it can sync the next time your user open the browser.
You have a similar example of deferred requests explained in the Service Worker Cookbook,
I'm trying to implement some push technology on an app of mine. I intend to use node.js for that but I don't think it is relevant for my question. What I will do is basically long-polling to the server, and as I understand the event driven way nodejs works, I don't have to care much about the server side of the stuff.
My only worry is on the client side: after how much time will the browser stop waiting for the answer ? It is a programming question because I need to release a response before this time is spent, so that the long-polling is reloaded.
Side question : when the browser stops waiting, what answer does it give to the request ?
I have done stuff like this before, and the answer to the question is quite simple: it depends on the browser, and how the user has configured it.
In FF there is a setting somewhere in about:config that controls this (I forget what the setting is, exactly). IE's default timeout is controlled in the registry, and is documented here. I never found the answer for Chrome or Opera - I don't think it's controllable. Opera seems to give up after no data has been received for around 20 seconds, but it also seems to vary somewhat - no idea why.
I concluded that the best thing to do here is to design your architecture so the page is reloaded periodically or if your using AJAX, periodically cancel the request and start a new one (I found that 1 minute works well). Also, keep pushing little bits of data to the browser every few seconds, as this will prevent Opera from giving up. You can simply push a javascript:void(0); event to keep the connection alive but not actually do anything at the client side.
To answer your side question: Nothing. The browser simply closes the TCP connection and no further data is exchanged. How the server handles this is no longer the concern of the 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.
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.
My team is working on a crappy old website and most of the pages are still ASP classic. However, we've recently migrated to forms authentication using ASP.NET and wildcard mapping. Everything works surprisingly well except for one thing: logged in users are timing out too quickly. After looking in the logs it appears people are timing out exactly after 20 minutes (which is the specified timeout due to inactivity).
So, our hypothesis is that the ASP classic pages are not tripping whatever mechanism in the forms authentication framework that resets the inactivity timer. I've googled around and even read the wildcard mapping post by the Great Gu but still can't find anyone else who is having this problem. So, 1) Have you ever seen this problem? and 2) What's the best workaround? (other than manually placing a hidden frame in every janky ASP page that loads a dumb .NET page in the background)
Update: slidingExpiration is set to true
Also: We can't use perpetual sessions because we need the application to time out after 20 minutes of inactivity. Also, this terrible site was written so that the interface is usually stored in the page. There's no simple piece of interface code I could slip the JavaScript into. We tried to put some js into an include file that was called by about 80% of our pages but it's caused some esoteric problems with file download buffers so we may have to try a different tack. Thanks.
Create a perpetual session.
Essentially you end up emitting some JavaScript and an image tag in your master page or navigation users controls (whatever you're using for consistent navigation). This JavaScript on some interval changes the source of the image tag to an http handler endpoint (some .aspx, .ashx) which returns a 1x1 pix clear gif as a response for the image. The constant request ensures that idle pages will keep the session alive.
As long as a browser window is open to your page your ASP.NET session will never time out.
Often the JavaScript will tack on a random number to the request so that the browser doesn't cache the request.
A decent walkthrough is available here.
I am assuming that you have manually created the cookie, in which case your timeout value in code is probably overriding your timeout value in the configuration.
First, if possible (which it probably isn't) don't create the cookie manually, it will save you from not only this headache but dozens of others.
If you must manually create the cookie, make sure that the timeout you are using is actually reading the timeout value that you have set in the configuration file and that sliding expiration is set to true (which you have said it was).
That said, we still have ocassional strange timeout problems when the cookies are manually created. Where I work we implemented a solution which allowed the cookies to be created automatically and timeouts were no longer a problem; however, it did create other issues and we were forced to switch back.