I cannot log into edit mode using Internet Explorer 9/10 - after logging in a weird guid of some kind is added the the URL such as: http://dev_epi7.mysite.com/(F(tBsvVe16UFVNG6hf2nW5Nhdcga5Hb7ouqfZHW6JQDKdKfS1ySFSRpeLbF-IMv_oNGvZrs2h8ztOY74KzDfm2oV1KccgP9VuMTZeLts43ii2UjcghEUNyuCi2WLe23YrWFdC8tKKs2x_CnPZYR0Z59oNuEL5wjDv0eej-X9RfUAHyilra1crePOLoNIcsE8Ol0))/EPiServer/Cms/.
The console output looks like this:
SEC7113: CSS was ignored due to mime type mismatch login.aspxSEC7113: CSS was ignored due to mime type mismatch login.aspxSCRIPT1002: Syntax error dojo.js, line 2 character 1SCRIPT1002: Syntax error epi.js, line 2 character 1SCRIPT1002: Syntax error DojoDashboardCompatibility.js, line 2 character 1SCRIPT5009: 'require' is undefined Cms, line 37 character 9SCRIPT1002: Syntax error ReportCenter.js, line 2 character 1
I've upgraded an EPiServer CMS 6 R2 to EPiServer CMS 7 using the latest Nuget feed EPiServer.Core and EPiServer.Framework. From the upgrade point of view I don't see that there are any issues - the site works perfectly with the latest crome, firefox, and IE when running it locally from VS2012 with the option: Use Local IIS Web server. I've created an IIS site that in pointed the the source code web root. y Development computer has IIS version 8.
The issue occurs in my shared dev where i've created a site on top of IIS 7.5 with identical configuration to the local site. By identical i mean all IIS configurations, config files with an exception that instead of localhost type configurations are changed to dev_epi7.mysite.com.
Any idea, no matter how obvious is appreciated.
Right, you're set to use something called a cookieless session which is what that mysterious code is in your URL.
Check your web.config settings for
<sessionState cookieless="true" />
and set it to false to remove the code (but you must ensure cookies are enabled in IE)
It may not fix all your problems but it answers your first question.
More information is available here
Thanks for the reply but i'm afraid that didn't solve the issue.
The <sessionState> node has the attribute cookieless="false". I decided to try out by setting cookieless="true". This did add session id code to my URL but it didn't remove the first issue. Session ID code in the URL seems to be of type:
- where as the code I have in my issue is of type:
After configuring the cookieless sessionstate it added the session id code in addition to the first one such as:
In addition, IE Privacy settings have been set to "Accept all cookies"
I guess i need to check out what does the (F(xxxxxxxxxxxxx)) stand for (ie (S(xxxxxxxxxxxxxxx)) seems to stand for session.
The F stands for Forms authentication. More details here
That does seem a little strange though... :/
Another thought that springs to mind is that the session database is normally installed with the EPiServer instance. This would negate the need for cookies. The tables all begin 'dbo.aspnet_' and I happen to have eleven of them in my instances. Can you check these are in your dev DB?
Yes the session data-tables are located in the same development database. This seems very strange and can't seem to put a finger on it. IMO it's an issue with Explorer since the site works fine with all other browsers. This doesn't explain the fact that why it works on my local dev though with similar/same configurations.
The issue was caused by the domain name - in more detail the "_" in the domain name which is in violation to RFC as described here: http://stackoverflow.com/questions/794243/internet-explorer-ignores-cookies-on-some-domains-cannot-read-or-set-cookies.
A recap - After fiddlering the sites around I noticed that my dev sites cookies weren't accepted by Internet Explorer at all (I have 3 upgraded EPi7 sites on the same server). The other browsers (Chrome, Firefox) seemed to work as intended.
I tried to fix the issue by following this thread: http://stackoverflow.com/questions/6983732/ie10-user-agent-causes-asp-net-to-not-send-back-set-cookie-ie10-not-setting-coo. The tips and tricks here didn't seem to do any good. This lead to the question of why IE didn't accept my cookies which lead to the first link.
Thanks Steve for participating ;)