My team have a big problem with a developed website. We have a page where We need to open three or four tabs, We used window.open and everything worked fine in testing area. But, in production with a load balancer (sticky session configured) when window.open is executed, It creates a new session, We saw in the logs that the request is redirected to other server when window.open is executed.
I've seen other links in stackoverflow like IE8 losing session cookies in popup windows
But the problem is that It happens also in Firefox, any clue about this kind of problem?
BTW, Our app is a ASP .Net MVC 4.5 website.
Second part of your question is pointing to a problem on the client side.
But if I read your problem it looks like a problem on the server side.
I think that your session pool over the load balancer has a problem.
Maybe try a simple page that shows your sessionId on a page and run that in your server farm for testing. make shure that the problem is not in your app but at server level.
edit after questionar reply:
Is your cookie set domain wide?
what happens if you open more tabs manually?
Is it a browser domain cookie handler problem (then the manual tabs will not work)
Or is it a javascript handler problem. (then the manual tabs will work)
Related
An ASP.NET application (actually with Silverlight but it doesn't matter) is hosted in Outlook as folder home page. In this application there's a link to open popup window, which opens a separate IE window, not in Outlook.
The problem is that in this case it seems that ASP.NET session is lost. A call to ASP.NET service has nothing in Session and Session._id is different. I suspect that Outlook has different cookies than IE.
How do I preserve session when opening IE popup from Outlook? Maybe pass session id via URL somehow, or configure this in web.config?
Note that I don't want cookieless sessions.
I ran into this problem in the past and was never able to find a way around it since the browser in outlook is running under a totally different process and it's not even a typical IE environment. I had issues with pass through authentication as well if I recall.
When the same behavior is done in IE directly, it actually opens another window using the same session.
To recreate the process in IE that is occurring in Outlook just open an IE windown and go to your app. Then open a new IE window by clicking the shortcut (not spawning it from the current IE session) and copying and pasting a link into the address bar. This is essentially what Outlook is doing.
I would try passing the value of the user's ASP.NET_SessionId cookie in the url from Outlook, then on the page that's opened in IE check for that value on the url and duplicate the ASP.NET_SessionId cookie in the response before loading the page (perhaps in an IHttpModule before the session has even been loaded for the request).
I'm not 100% sure this would work in case ASP.NET has some built-in session hijacking security in place that would prevent you from manually duplicating the session cookie somehow, but that's where I would start.
We are noticing some very strange behavior on an installation of a .NET2-based webapp on Server 2008. Our app uses old school Integrated Windows Authentication and simply reads the LOGIN_USER server variable from the request collection. There's a good reason for this, but that's somewhat irrelevant to the question, since the underlying WindowsAuthentication code from ASP.NET does the same thing.
Anyway...
When you enter the URL in the browser, it loads up just fine and displays the username (from LOGIN_USER) no problem.
When you click on a link within the web app, it loads the page just fine and authenticates without any problems.
When you hard refresh (Ctrl-F5) it also works just fine.
However, when you click open in a new window or open in a new tab, the LOGON_USER variable is blank
Any ideas? Am I missing some IIS7 setting somewhere?
Tested clients are Windows 7 with IE8 or Windows XP with IE6.
I experienced something very similar on IIS6 a few years ago. The issue then was caused by both anonymous and windows authentication being turned on for the site. Turning off anonymous authentication fixed the issue.
Though this was on IIS6 it might be something to look into.
The problem went away on it's own............ for now. After a reboot. Really. Shoulda thought to reboot earlier.
Also: anonymous auth was not enabled (otherwise, LOGON_USER would always be blank).
So, if you ever encounter this problem.... reboot!
My asp.net application works fine when launched from its own browser, but when its launched from another web application (sharepoint webpart) using window.open it works until the user clicks and posts back, then the session is lost.
I think its related to cookies, because when I set the session state to be cookieless everything works fine.
Why does the sesssionid get lost in the NEW application when launching the app using window.open? I would like each application to have its own session cookie, I've tried setting the name of the cookie but the same thing happens, on the first post back the sessionid is lost??
Please help?
Sharepoint manages it's own session. Sessions are tied to applications (URI). You would need to share some sort of login token between applications.
check out:
http://forums.asp.net/t/1335229.aspx
http://forums.asp.net/p/1356006/2781938.aspx
What browser are you using?
IE6 has this exact issue, possibly newer versions as well.
Refer to Microsoft Support
drop window.open(). use links with tarket="blank". if you need to call them from JS just do
link.click() on it.
I'm using the ASP.NET Login control and have been doing so for a couple of years on a particular site with success. Out of the blue, in the dev environment, this control has stopped working and is now bouncing me back to the login page.
Using source control I've reverted recent changes that might have been the cause but no luck. I've stepped through the code and have checked that the e.Authenticated property is correctly being set to true and that the ReturnUrl is correctly specified on the params.
Any ideas about where to look next to try and figure this out?
After logging in are you being redirected to a page that you don't have authorisation for?
I would check the following...
Cookies still set in the browser
SSL settings in conjunction with http
not forwarding onto https
Cert issues (old, new, expired)
Changes in the domain that the user
is authenticating to
Essentially, check everything except
your code, it works like you said.
;-)
When using Visual Studio's built in web server, every time I make a page request the standard login box pops up and asks for credentials. It doesn't work if I actually put in my credentials, so I just have to hit cancel 5 times so it will go away.
When I run the application through IIS (locally or on test server) it works just fine (no login box comes up).
Anyone know how to fix this or have any idea what might be causing it?
I assume you mean JavaScript alert box-looking login dialog, right? This dialog pops up when you make a request to a portion of website where anonymous access is disabled from IIS. It is different from ASP.NET authentication.
Do you have some portion of web site protected? Or are you making any HTTP request to external sites, like images and etc?
If your page looks ok after hitting cancel multiple times, it must be one of those HTTP request to protected file like images, css, js or whatever.
I'd look in Fiddler or Firebug to see if any request is failed when you hit cancel in that login dialog.
I'd also try clearing cache/authenticated session on the page that runs on IIS to see if it actually shows you that login dialog.
I had this same issue. However, my solution was different and the issue seemed different as well.
I had been working on a ASP.NET 2.0 web application, using VS 2008. Everything was working fine with the built-in IIS server. I hadn't opened this project for about a week and then when I chose "View in browser" in VS, I was prompted for my windows login creds. This project never did this before, so I was a bit baffled. I checked all the web.config settings and everything seemed fine. My project settings seemed correct as well. I decided to test the project by opening this same project in VS on a separate dev box on my network using a network path. I again chose "View in browser" and it worked fine. No logon prompt.
This told me that the issue wasn't with the actual web project itself, rather my dev environment. I checked all my browser settings as suggested above, and they were correct. I then compared my project settings while I had the same project (same physical files) opened in both dev boxes. I noticed a difference...
Under the Start Option in the Property Pages, the Web Server was set to use the Default Web server in both cases. However, on the box that was asking for my creds, the NTLM Authentication checkbox was selected. I unselected this and it resolved the issue.
I'm not sure how this was possible since I was opening the same project files, and would assume the project settings would be exactly the same. And the fact it was working fine a week ago really perplexed me. I chalked it up to an issue with VS 2008 on the box with the issue. I hope this helps anyone else that may be running into this issue.
This was because localhost was not in my trusted sites so it wouldn't do automatic NTLM authentication... I'm not sure why it was that way, but it was... adding localhost to the list fixed it.
In your project, there should be a vwd.webinfo file.
The following lines control authentication when debugging (in IISExpress). Set as follows to avoid all dialogs.
<VisualWebDeveloper>
<iisExpressSettings anonymousAuthentication="enabled" windowsAuthentication="disabled" useClassicPipelineMode="false"/>
</VisualWebDeveloper>
If windowsAuthentication="enabled" you may still get a dialog, even if anonymousAuthentication="enabled" :-)