Opened 14 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)
Change History (8)
comment:1 Changed 14 years ago by
Cc: | WebSpellChecker.net added |
---|
comment:2 Changed 14 years ago by
Status: | new → confirmed |
---|
comment:3 Changed 14 years ago by
Cc: | camden.michael@… added |
---|
comment:4 Changed 14 years ago by
Keywords: | HasPatch Review? added |
---|---|
Version: | 3.5.2 → 3.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 14 years ago by
Attachment: | 7275.patch added |
---|
comment:5 Changed 14 years ago by
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
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.
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
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.