I'm having a weird issue that I can't find any reference to on SO
I deploy my app to staging server daily and it has stopped behaving properly
When I Log in the address in my browser looks like so
http://x.x.x.x/(F(W24RTn2OAE25WANV8wtnrAEVS4VWP7InzD7rCS3narKQgB3F6eqHe04BLLdK2uv2RCzfrwzW5AMPbOGoN99C9aq5WMWP0_brrNTy1HD0EH1nU2G_be9gz_jXYwkZlaQDIjv4NPD-LVr9j2h2teipwjV0yPtr25wEeDrheFNaKcaHqblTFXnNZCjfTJkEJxIN0))/Controller/Action/25
If I delete the junk in there manually so that I can navigate to /Controller/Action/25 I am forced to log in again ... upon doing so I am redirected to the correct page but all that junk is back again
http://x.x.x.x/(F(W24RTn2OAE25WANV8wtnrAEVS4VWP7InzD7rCS3narKQgB3F6eqHe04BLLdK2uv2RCzfrwzW5AMPbOGoN99C9aq5WMWP0_brrNTy1HD0EH1nU2G_be9gz_jXYwkZlaQDIjv4NPD-LVr9j2h2teipwjV0yPtr25wEeDrheFNaKcaHqblTFXnNZCjfTJkEJxIN0))/Controller/Action/25
Also, it seems to be a related issue, my autocomplete textboxes no longer work... the calls never hit the DB.
Both pieces of functionality work fine locally on my IIS Express when in debug mode of the source code so I'm thinking it's the staging server IIS... but am unsure where to look to clear up this issue.. an ideas?
Here is the only thing my web.config is doing with forms authentication
<authentication mode="Forms">
<forms loginUrl="~/Account/LogOn"
timeout="2880" />
</authentication>
At login the action method is the default
FormsAuthentication.SetAuthCookie(model.Username, model.RememberMe);
This is happening on every browser on my VM and local machine both, but not on another PC. I've refreshed all browsers, deleted all cached from each browser
This does appear to be a cookie thing. In Chrome I can see the cookie when I log in to the site in debug mode in the dev tools. Using the same browser if I log in to the site pointing at the staging server there is no cookie being set.
Why would there not be a cookie being set if I am not doing anything to prevent the cookie and have deleted cache, etc?
Is forms authentication configured to not use cookies? In this case it embeds this information in the URL. This would explain why when you delete it you have to log in again.
Related
I am posting this as a question and answer for anyone else that has this issue as it was an absolute PITA to debug.
We have a taskpane add-in for Word that has a login page using cookies to store the session state. This works completely fine in everything except Word Web in Internet Explorer 11 on Windows 7.
By using Fiddler we can see that our cookies were getting set and everything is fine, even the session cookie stays the same (this is another issue altogether), but for whatever reason the .AspNet.ApplicationCookie is never getting sent back with the request for the HTML page - but it is getting sent back for the request for the JavaScript. WTF.
See the answer to this post: Cookie blocked/not saved in IFRAME in Internet Explorer
The issue has to do with the fact that in Word Web the taskpane is in an IFRAME. It has something to do with P3P policies - which as far as we can tell don't get used by anything else.
Anyway here are the important bits from that answer:
I've spend a large part of my day looking into this P3P thing and I feel the need to share what I've found out.
I've noticed that the P3P concept is very outdated and seems only to be really used/enforced by Internet Explorer (IE).
The simplest explanation is: IE wants you to define a P3P header if you are using cookies.
...and the solution...
In short - to keep IE happy - add the following line to your PHP code (Other languages should look similar)
header('P3P: CP="Potato"');
Problem solved, and IE is happy with this potato.
So basically you need to add this HTTP Header to all responses to get IE to play ball.
If you are using IIS to host your website, add this to the web.config:
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="P3P" value="CP='Potato'" />
</customHeaders>
</httpProtocol>
<system.webServer>
<configuration>
I am currently working with the umbraco cms. I notice in the web.config references to session state.
My site will be on a web farm without a state server. Is umbraco reliant on session state? And if so, is it needed for content authoring or is it needed for content serving?
The front end doesn't use any session variables at all unless you code it to do so, so that should be OK for the content serving side of things.
I'm not 100% on the back office, but I THINK it's all done with cookies, rather than sessions. The easiest way to check would be to disable sessions in the web.config file and try and use the back office. If it works, you're OK, otherwise it does need the session to work for content editing.
I have an asp.net mvc application which was working properly before I click on "Add deploy able dependencies". Cause I had some problems on deployment server, I had to click on that option. After doing so, the authentication part in web.config does not work properly :
Instead of redirecting me to ~/Admin/LogIn it redirects me to Account/Login?...
I read these useful links, like http://forums.asp.net/p/1613705/4128618.aspx, And I applied the solution in server.
But my question here is that why my application does not work any more in my local machine as before, without having problem with authentication redirection ?
I have an application running in Azure (trial account). So far so good, everything has been nice, except for a long deploy times (10-15 minutes).
I've done a deploy recently and got a lot of weird bugs I cannot trace. For example, if I log in and thus a cookie is created (I use FormsAuthentication) all I get from the application is a blank page, as in, absolutely nothing is sent to the browser. The application works fine in the ASP.NET Web Dev Server, IIS Express, even the Azure Emulator!
What could be the issue? Searching the web hasn't been much help, with only a couple of unrelated issues.
I tried logging into the site (if I correctly understood from one if the comments, the url is versulo.com) and I didn't get any blank page with 404 status code.
However, there is another problem I spotted. Your site seems to be implementing caching inappropriately. The main page, the one from which you trigger the login and which is dynamic in nature contains an Expires header set at 5 minutes after the pages first load. That means that each call or redirect to that page within 5 minutes since it was first loaded, will be served from the browser's cache.
Because of that, after I login into your application I am redirected back to the home page which looks like I am not logged in. If I force a F5 refresh on the browser, then the page will indeed show me as logged in.
If instead of a refresh I try to login again (which is what I did in my first trials, since it looked like the login didn't work in the first time), I am getting an error page with the following message:
Sorry, there has been an error on the server.
500
The page looks like an application error page and even if it displays the 500 number, it is actually served with an HTTP 200.
So, while I am not 100% sure if this is also the cause of the problem described by you, you should remove the Expires headers from the dynamic pages your application is serving.
This can be because you're combining Forms Authentication with multiple instances. Are you using multiple instances? If that's the case, could you:
Try to change it to 1 instance. Does this fix the issue?
Try to make the following change to the web.config (configure machineKey): http://msdn.microsoft.com/en-us/library/ff649308.aspx
some partial views are not rendered at all;
Do you mean some pages are working fine, but others are not? It would be better if you can point out a pattern on what’s working and what’s not? For now, please make sure all referenced assemblies (except for default .NET assemblies and Windows Azure runtime) have Copy Local set to true. For example, MVC assemblies are considered as extensions to .NET, so please set Copy Local to true. In addition, you can also try to use Fiddler to monitor the requests to see what’s returned from the server.
Best Regards,
Ming Xu.
Could you provide a link to the application, or perhaps some source code?
When you say 'blank page', what is actually returned, a 404 / 500?
Have you inspected the IIS logs, or added some trace information to your code?
Have you tried accessing the service using it's ip address rather than domain name?
I'm having trouble finding any info on this, which makes me think I'm doing something wrong. I've made an ashx that serves up secured images to our logged-in users. The problem is that a Sql Profiler trace reveals that TempResetTimeout is called in our Session State DB for every image served via this mechanism. This ashx was built to replace an aspx that used to do the same thing but was causing many session state db deadlocks due to many images and web garden usage, yada, yada. This is definitely an improvement, due to one less "Read Committed" call to session state db, but the fact that there's an update means we can still have some deadlocks. Basically, we want NO session interaction at all from the use of this ashx, but that doesn't seem to be happening.
I certainly don't have the IRequiresSessionState interface implemented, so I am led to believe that my ashx should not touch Session in any way. I see Global.asax hit for every occurrence however, and Global.asax references session in some of its code. This led me to try to exclude this particular page from any sort of authentication via the following in web.config...
<location path="ImageHandler.ashx">
<system.web>
<authentication mode="None" />
</system.web>
</location>
...but this causes the ashx to not fire at all (no image displayed and no breakpoint hit in ProcessRequest). I'm not sure why that is happening.
How can I get my ashx ImageHandler to not touch session AT ALL?
SessionState is set up on an Application level, so the only way to disable session for any ASP.NET request is to put it in its own Application in IIS and turn session state off.
<system.web>
<sessionState mode="Off" />
</system.web>
http://msdn.microsoft.com/en-us/library/h6bb9cz9.aspx
You could also create your own session state module (perhaps trying to wrap the existing one), but that also would either require IIS configuration to set up another folder as an Application, or replacing it on your root application.
http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionstatemodule.aspx
Though that just seems like a lot more effort than just turning it off for one subfolder that's configured as an Application in IIS.