Please help on our issue on the user session. After log-in and select a menu, it will fall on the different user session.
The normal URL should be like this:
http://www.company.com/mams/Sales/AccountForecasting.aspx
But it goes to this URL:
http://www.company.com/mams/(X(1)S(hm4occ2bbcefegbj1gws4kwf))/Sales/AccountForecasting.aspx
Notice that there is a script inside the URL and im not sure where it came from.
After i recycle the application pool and restart the website, it will back to normal but this problem will occur again after 1 or 2 days after restart.
Any help will be greatly appreciated.... thanks
That looks like a cookieless session to me. Most likely you're running an older version of .net and the browser file isn't recognizing a newer browser, so it's defaulting to cookieless.
One option to fix is to set session to always use cookies. (cookieless="UseCookies" from the configuring session link).
Another option is to use a browser files to modify the default capabilities of the problem browser. It would require some knowledge of which browsers is causing the problem. Or you could configure all downlevel browsers to default to supporting cookies. (See http://www.hanselman.com/blog/FormsAuthenticationOnASPNETSitesWithTheGoogleChromeBrowserOnIOS.aspx)
On cookieless sessions
http://msdn.microsoft.com/en-us/library/aa479314.aspx
On configuring session
http://msdn.microsoft.com/en-us/library/h6bb9cz9.aspx
Related
I'm currently working on an ASP.NET MVC project and I'm using an azure AD to connect to my website.
When I try first on Chrome, for exemple, those are the cookies that are created :
And every thing works fine ! But if I launch the same website on FireFox without stoping IIS express, I got an infinite number of cookies incoming and the server stop and says :
HTTP 400. The size of the request headers is too long.
And got this list of cookies :
If I close IIS Express and retry an other time with FireFox, it created only 3 cookies and works fine...
Can Someone explain me what is going on ?
PS: Please don't give the solution " you need to delete old cookies" it's not the problem here... It doesn't work even if I don't have any cookies... AND nothing matters what browser i'm using, I've tried 6 differents browsers and every time only the first who has been launch is the only one who works.
Thanks in advance for your help !
Reason/Investigations
I think you have some API or AJAX calls which are secure and require authentication. When you change the browser and your requests are no more authenticated and on AJAX or API call it start creating the cookies. I am sure if you will login to the app in FireFox it will stop doing that. I dont think it is a browser specific issue. If you will move the app from Firefox to IE it will do the same.
Solution
Now, you have to either make sure that when you are not logged in or the request is not authenticated you redirect to login page and stop making unauthenticated calls.
Other solution is to delete all nonce cookies as per MikeDotNet solution.
You will find some people suggesting that it is a bug in Microsoft Nuget package Microsoft.Owin.Security.OpenIdConnect and if you use 3.0.0 it will fix the problem. It works in some of the cases but I found that solution good for IIS but not in Cloud.
Here is the problem that I'm having. Often times, I cannot login to my Plone site. Other users have the same issue as well. Basically what happens is that when I click "Log In", the web page just refreshes but it doesn't log me in. In order to correct this problem, I had to clear the browser history and cookies in order to log in successfully. Sometimes I had to do this a few times in order to work. I would like at least 50% of the time I had to clear the history before I can login. Other times, it just works and it logs me in without any issue.
This problem started quite some time ago, perhaps almost a year now. I just never had time to look into it. However it seems like this problem is related to newer version of web browsers because I never had this problem before around one year ago.
I'm running Plone version 4.0.4. Can anyone suggest how I should troubleshoot this problem? Should I upgrade a particular component within my Plone setup?
FYI, I'm using the building authentication component and not anything external like LDAP. I manage my users in Site Setup -> Users and Groups.
Thanks in advance.
Things to look into:
go to /acl_users/session/manage_propertiesForm and check the settings here to make sure they make sense
check cookie settings for if they are valid on non-ssl and that you are logging in via ssl urls.
use a web browser web inspector(like chrome) and inspect that login cookies are set properly after you're logged in(look for the __ac cookie)
Finally, look into your caching. If you're using plone.app.caching, make sure to NOT cache for logged in users. If you're overriding caching at the web server, make sure you're not caching when the __ac cookie is present.
If you're not caching at the web server, make sure cache headers for the browser are also getting set appropriately
inspecting caching will also require using a browser to inspect the headers getting returned
I am facing a problem where ASPXAUTH cookie is not being generated unless the website is hit from the same machine where it is hosted. I have confirmed this by enabling and viewing IIS logs.
From all other machines no matter what, it redirects back to the login page. This is a very strange behaviour as no installation has been made nor any changes to IIS. I would appreciate if anybody could share their experience and suggest a possible solution.
UPDATE : For some unkown reasons it is working with Firefox. Still not able to figure out what is causing this in other browsers !
After 2.5 days of intense searching and hair pulling it turned out that server date/time was not correct !!! I synchronized it with internet clock and cookies worked.
Do you have security settings where you don't allow cookies in the other browsers?
A tester of my new app reported problems with authorization support in ASP.NET MVC app: Whenever he switches to a new tab (different controller), he's prompted for his login again.
After investigation, I found that the server forcibly wants to use cookieless forms authentication using URLs such as in this question.
The problem appears in his Firefox 3.6.15. Not on other browsers on his computer, not on Firefox on other computers. I checked his Firefox options: Cookies are enabled. HTTPfox even says there is an ASPNetSessionId exchanged!
How come? Can anyone shed some light? FWIW, my web.config doesn't say anyhting about cookies or sessions. I didn't even know of these cookieless URLs before seeing them on this computer and doing some research.
Uninstall and reinstall Firefox from his machine. backup his bookmarks first so he doesnt lose anything. It sounds like its an installation issue rather than a coding problem.
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!