Opened 13 years ago

Last modified 11 years ago

#7275 confirmed Bug

IE session dropped when using SCAYT, MVC

Reported by: Peter Owned by:
Priority: Normal Milestone:
Component: UI : Spell Checker Version: 3.4
Keywords: Cc: WebSpellChecker.net, camden.michael@…, abrir.fuego@…

Description

I have an MVC application where we need to use SCAYT. When it's enabled, it writes cookies to the browser. Once it hits the IE limit, the client browser arbitrarily drops cookies including the ASP.Session and Authentication kicking users out of the site randomly. Since this is an MVC application it treats www.domain.com/ticket/detail/1234 as seperate than www.domain.com/ticket/detail/1252, when in reality this is the same page with a different id passed in. In webforms this isnt an issue because the comparable url is www.domain.com/ticket/detail.aspx?id=1234 and the scayt cookie (i am guessing) doesnt look at the querystring.

I dont have any true test cases for this, but it can be reproduced in any MVC application that utilizes dynamic paths. Your team should be able to create a sample MVC app (needs to have at least a session key) that has one page that takes an extension and test it with random numbers. Monitor the site in IE6, 7, or 8 using Fiddler and after about 10-15 new number combinations, you will be able to repro the issue.

I would think that there should be a feature (or config setting) that would allow me to designate MVC patterns to treat as singular, or some other function that would cause this not to happen.

Obviously, we could disable the SCAYT feature, but this is a huge requirement for the client and if that is the solution we will just have to use a different editor.

One last thing, I am completely aware that this is an IE issue only, however, our client is a Microsoft shop and it is an actual SLA requirement for us to support IE6-IE8 since 99% of their users are on these browsers.

Attachments (1)

7275.patch (941 bytes) - added by WebSpellChecker.net 13 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 13 years ago by Alfonso Martínez de Lizarrondo

Cc: WebSpellChecker.net added

These are the cookies that are created by javascript, I don't see any reason to specify a path for them instead of using the root folder, and even the name of the cookie doesn't really need to specify the page name

NAME  [replacebyclass.html]scayt_0__options 
VALUE  %220000%22 
DOMAIN  ipv4.fiddler 
PATH  /ckeditor/_samples/ 
EXPIRES  05/03/2012 11:48:07 

NAME  [replacebyclass.html]scayt_verLang 
VALUE  5 
DOMAIN  ipv4.fiddler 
PATH  /ckeditor/_samples/ 
EXPIRES  05/03/2012 11:48:07 

It would be even better if other local storage mechanism could be used instead of cookies (IE supports userData Behavior), I think that DoJo might have some wrapper for it.

comment:2 Changed 13 years ago by Alfonso Martínez de Lizarrondo

Status: newconfirmed

comment:3 Changed 13 years ago by Michael Camden

Cc: camden.michael@… added

comment:4 Changed 13 years ago by WebSpellChecker.net

Keywords: HasPatch Review? added
Version: 3.5.23.4

We've prepared patch with SCAYT cookies disable. The option to disable SCAYT cookies is:

CKEDITOR.config.scayt_persist = false

Please note that variable persist is global and defined only once for all SCAYT instances.

Changed 13 years ago by WebSpellChecker.net

Attachment: 7275.patch added

comment:5 Changed 13 years ago by Frederico Caldeira Knabben

Keywords: HasPatch Review? removed

I'm not able to apply this patch to trunk. Additionally, it looks like the patch is creating a global named "scaytConfig", which is not permitted.

comment:6 Changed 11 years ago by Ivan Bondarenko

Cc: abrir.fuego@… added

Any chance to back somehow to this question?

Our task: we must set scayt_sLang programmatically multiple times.

Problem: scayt cookies take precedence over programmatically set values. Also we actually don't want that "scayt_*" cookies to be set. Whether to set or not cookies scayt decides basing on scayt.persist option which is simply mixed-in to scayt like "persist: true".

Possible solution: switching off persistence before scayt is loaded.

Currently we are switching it after scayt is loaded, but we don't know exactly when to set the property as everything is async. We use such ugly workaround:

var scaytInterval = setInterval(function() {
	if (scayt) {
		scayt.persist = false;
		clearInterval(scaytInterval);
	}
}, 200);

Alternative possible solution: scayt must raise some event after it is ready.

comment:7 Changed 11 years ago by Ivan Bondarenko

Never mind, 'scaytReady' event is alright.

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy