Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#10165 closed Bug (fixed)

CKeditor 4.0.1 Access denied error in IE9-10

Reported by: Ramesh Ponnusamy Owned by: Olek Nowodziński
Priority: Normal Milestone: CKEditor 4.1.2
Component: General Version: 4.0 Beta
Keywords: Oracle IE9 IE10 Cc: Ramesh Ponnusamy, Senthil, christian.schnepf@…

Description

When i upgrade CKeditor from 3.6.2 to 4.0.1 I'm getting access denied error in IE. When try to investigate i found that the issue due to the document.domain set in the parent page which is invoking ckeditor.

In Previous versions Ckeditor picks up the document.domain from the parent which is invoking it and sets it to the iframe which ckeditor generates but the 4.0.1 is not doing this.

This is impacting our upgrade and it is very critical for us. Please provide the fix as quick as possible.

Thanks, Ramesh

Attachments (6)

test2.html​ (6.7 KB) - added by Jakub Ś 12 years ago.
To reproduce the Access denied Error.doc​ (28.0 KB) - added by Senthil 12 years ago.
0001-Simplified-fix-for-Access-denied-error-in-IE9-10-whe.patch​ (2.0 KB) - added by Olek Nowodziński 12 years ago.
IE Access Denied Error1.png​ (56.7 KB) - added by Ramesh Ponnusamy 12 years ago.
test.html​ (639 bytes) - added by Piotrek Koszuliński 12 years ago.
test3.html​ (839 bytes) - added by Jakub Ś 12 years ago.

Download all attachments as: .zip

Change History (40)

comment:1 Changed 12 years ago by Jakub Ś

Keywords: IE9 IE10 added
Status: new → confirmed
Summary: CKeditor 4.0.1 Access denied error in IE → CKeditor 4.0.1 Access denied error in IE9-10
Version: 4.0.1 → 4.0 Beta

I was able to reproduce this issue from CKEditor 4 beta in IE9-10 only.

To reproduce:

  1. Configure your server so that is has e.g. example.com and subdomain.example.com
  2. In subdomain "folder" place attached test2.html file (it contains document.domain set to example.com)
  3. In the same folder place ckeditor 4 folder.
  4. Run your file from IE browser using e.g. ​http://subdomain.example.com/test2.html

Result:Since version 4 beta IE9 and IE10 shows access denied (IE7 and IE8 work fine).

NOTE: One of our user said that document.domain is not set on iframe but I didn't get this result. In every version I had document.domain set: 

<iframe tabIndex="0" title="..." class="cke_wysiwyg_frame cke_reset" aria-describedby="cke_89" src="javascript:void(function(){document.open()%3Bdocument.domain%3D%22example.com%22%3Bdocument.close()%3B}())" frameBorder="0" style="width: 100%; height: 100%;" allowTransparency="true">

Changed 12 years ago by Jakub Ś

Attachment: test2.html​ added

comment:2 Changed 12 years ago by Piotrek Koszuliński

Owner: set to Piotrek Koszuliński
Status: confirmed → assigned

comment:3 Changed 12 years ago by Olek Nowodziński

Owner: changed from Piotrek Koszuliński to Olek Nowodziński

comment:4 Changed 12 years ago by Ramesh Ponnusamy

Hi,

Any update on this bug...?

We are waiting for the fix. Please provide the fix as early as possible

Thanks, Ramesh

comment:5 Changed 12 years ago by Olek Nowodziński

Created branch ​t/10165 which is based on 4.0.1. It contains a temporary fix for this issue, which requires config.forceCustomDomain: true if document.domain is touched (even if document.domain = document.domain): 

document.domain = "custom.domain";
CKEDITOR.replace( 'editor1', {
	forceCustomDomain: true
} );

The origin of the issue

  1. In IE9-10, src attribute must contain a script that changes document.domain to parent document's domain. IE distinguishes between document.domain changed manually and automatic value (even it they're equal like: document.domain = document.domain).

In such case CKEDITOR.env.isCustomDomain() is inaccurate, and script in src must be forced by some config option.

  1. In IE9-10, the iframe must be assigned src immediatelly to use this fix: 
    CKEDITOR.dom.element.createFromHtml( '<iframe src="' + src + '"></iframe>', CKEDITOR.document );

It cannot be set via element.setAttribute() as this is way too late.

comment:6 Changed 12 years ago by Ramesh Ponnusamy

Thanks for the quick response but unfortunately this workaround is not solving the issue for us.

It still gives me the access denied error.

Thanks, Ramesh

comment:7 Changed 12 years ago by Senthil

Attached the detailed doc to reproduce.

Changed 12 years ago by Senthil

Attachment: To reproduce the Access denied Error.doc​ added

Changed 12 years ago by Olek Nowodziński

Attachment: 0001-Simplified-fix-for-Access-denied-error-in-IE9-10-whe.patch​ added

comment:8 Changed 12 years ago by Olek Nowodziński

I created another branch ​t/10165b with simplified version of previous fix.

I'm using the following HTML as ​http://sub.ckeditor4.t/domain.html, while setting document.domain = 'ckeditor4.t': 

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
	<title>Replace Textarea by Code &mdash; CKEditor Sample</title>
	<meta content="text/html; charset=utf-8" http-equiv="content-type" />
	<script type="text/javascript" src="ckeditor/ckeditor.js"></script>
	<script src="sample.js" type="text/javascript"></script>
	<link href="sample.css" rel="stylesheet" type="text/css" />
	<script>
		document.domain = 'ckeditor4.t';
	</script>
</head>
<body>
	<textarea id="editor1">
		CKEditor!
	</textarea>
	<script>
		CKEDITOR.replace( 'editor1' );
	</script>
</body>
</html>

With IE7/8:

With IE9/10:

  • 4.0.1: I got SCRIPT5: Access is denied. plugin.js (wysiwigarea), line 91 character 6.
  • ​git:74773ae30: WFM. No errors.

You can also apply ​git:74773ae30 fix to plugins/wysiwygarea/plugin.js by using attached patch​ and: 

patch -u plugins/wysiwygarea/plugin.js 0001-Simplified-fix-for-Access-denied-error-in-IE9-10-whe.patch

Please make sure that your browser's cache is empty before testing this fix. Generally speaking, IE have serious issues with cache.

If this solution still fails please provide additional info so we can reproduce this ticket in details:

  • Full config for the editor.
  • The exact way of running the editor (via CKEDITOR.replace() or by class).
  • Full version number of failing IE.

comment:9 Changed 12 years ago by Ramesh Ponnusamy

I have tried your latest solution but i'm getting the attached error. Looks like iframe is still not getting the document.domain.

We have tried your solution in replacebycode sample html.

Note: i have removed the forceCustomDomain for testing this.

Changed 12 years ago by Ramesh Ponnusamy

Attachment: IE Access Denied Error1.png​ added

comment:10 Changed 12 years ago by Piotrek Koszuliński

OK. We identified the error. Our patch works on every IE, but not on Quirks Mode. From your screenshot (there is a border around iframe) and attached DOC we concluded that your page is running in QM.

We updated the ​t/10165 branch with patches fixing:

  • permission denied error on IE9 QM,
  • ugly border around iframe,
  • permission denied error when opening dropdown menus.

I attached the document (attachment:test.html​) that we use for our tests - note that you need to set: 

CKEDITOR.config.forceCustomDomain = true;

We tested this page on the following domains:

Last edited 12 years ago by Piotrek Koszuliński (previous) (diff)

Changed 12 years ago by Piotrek Koszuliński

Attachment: test.html​ added

comment:11 Changed 12 years ago by Olek Nowodziński

Updated ​t/10165 branch with fixed "permission denied" when opening link dialog in the same test case. There's a fileButton in that uses iframe as well.

comment:12 Changed 12 years ago by cschnepf

Cc: christian.schnepf@… added

comment:13 Changed 12 years ago by Ramesh Ponnusamy

Hi,

I have taken the below changed files from [t/10165] branch and put it in my local file and built the files and also i have given CKEDITOR.config.forceCustomDomain = true;. Still it is not working. The CKeditor loads properly without any error now but when i try to open any dialogue it is throwing permission denied error.

The file taken from t/10165 branch:

plugins/dialogui/plugin.js

plugins/panel/plugin.js

plugins/wysiwygarea/plugin.js

Thanks,

Ramesh

comment:14 Changed 12 years ago by Ramesh Ponnusamy

If you like to have webconference i can show you the issue i'm facing

comment:15 Changed 12 years ago by Piotrek Koszuliński

Let's start from question. Does the t/10165 branch work for you in the following case?

Note: There is an error thrown when dragging dialog, but it does not cause any bugs as far as I can see.

Does the sample work?

comment:16 Changed 12 years ago by Frederico Caldeira Knabben

If the current fix still doesn't work, the one and only way to have this handled properly is by having a simple test case page attached to this ticket, so we can have something concrete to work on.

Changed 12 years ago by Jakub Ś

Attachment: test3.html​ added

comment:17 Changed 12 years ago by Jakub Ś

I'm not sure if by simple test you mean test3.html.

Anyway I have two iframes there first always throws access denied and second works in every browser. You still need server for it with two domains. In my case I had example.com and subdomain.example.com. On page I setting example.com as document.domain and I'm running the file from subdomain.example.com.

I couldn’t get more simple than that :)

comment:18 Changed 12 years ago by cschnepf

Any idea when this fix might get rolled into the mainline of ckeditor? I am facing the same problem. I have used the branch and it is working as expected.

comment:19 Changed 12 years ago by Piotrek Koszuliński

Thanks cschnepf for this info. We haven't got confirmation from ramesh.ponnusamy that our solution works, so we stopped working on this patch. It still needs some polishing and we're closing 4.1.1 tomorrow, so it has to wait until next release.

Version 1, edited 12 years ago by Piotrek Koszuliński (previous) (next) (diff)

comment:20 Changed 12 years ago by cschnepf

Hi Reinmar. Looks like 4.1.1 went out a couple days ago. Just checking in again to see if you think this patch might make it into the next release and see if you have an eta for that.

Thanks in advance!

comment:21 Changed 12 years ago by Piotrek Koszuliński

Duplicate #10397.

comment:22 Changed 12 years ago by Lee

I also have this issue and it is preventing me from upgrading from version 3. I host ckeditor in a CDN on a separate sub-domain and I need to set the document.domain for some of my plugins which use iframes.

comment:23 Changed 12 years ago by Frederico Caldeira Knabben

Milestone: → CKEditor 4.1.2

comment:24 Changed 12 years ago by Olek Nowodziński

Rebased t/10165 on latest master.

comment:25 Changed 12 years ago by Olek Nowodziński

Status: assigned → review

Latest changes:

  • Added doc string for config.forceCustomDomain.
  • Added mt for this ticket in test branch t/10165.

Apart from that, I'm doubtful about CKEDITOR.env.isCustomDomain().

Since we really have to additionally use editor.config.forceCustomDomain = true to prevent various permission denied errors in IE when document.domain is touched but not changed, then IMO CKEDITOR.env.isCustomDomain() is no-longer an env-specific method but editor-specific method.

It should be rather something like CKEDITOR.editor.isCustomDomain(). I'm aware of the fact that, due to backward-compatibility restrictions, we cannot basically move this method from env to editor. But we can create CKEDITOR.editor.isCustomDomain() which uses CKEDITOR.env.isCustomDomain() and restrict that the second one is obsolete.

It would also simplify most of conditional statements in several places that look really bad in this ticket branch.

comment:26 Changed 12 years ago by Frederico Caldeira Knabben

Status: review → assigned

I didn't like the forceCustomDomain way since the beginning, so I've considered a different way for it. I'm working on this.

comment:27 Changed 12 years ago by Frederico Caldeira Knabben

Owner: changed from Olek Nowodziński to Frederico Caldeira Knabben
Status: assigned → review

Pushed the new idea in t/10165. It basically deprecates CKEDITOR.env.isCustomDomain.

comment:28 in reply to:  27 Changed 11 years ago by Olek Nowodziński

Status: review → review_failed

Replying to fredck:

Pushed the new idea in t/10165. It basically deprecates CKEDITOR.env.isCustomDomain.

The idea is very cool. It resolves the issue in all browsers. It brings some minor issues to magicline tests but they can be solved.

The problem is IE7, which gives "Permission denied" regardless of solution. For sub.ckeditor4.t it tries: sub.ckeditor4.t, ckeditor4.t, t and eventually fails because "no domain has left". For unknown reason fixDomain always rises SOP error in wysiwygarea plugin, right at the beginning of the callback of editor.addMode( 'wysiwyg', ... ).

I debugged the issue with MS Visual Web Developer 2008 Express because what IE7 returns is nothing like a "verbose output".

comment:29 Changed 11 years ago by Frederico Caldeira Knabben

Status: review_failed → review

I would propose to not spend time right now on IE7 support for this and move on, otherwise we may risk not having this fix for other browsers which are much more relevant.

comment:30 Changed 11 years ago by Olek Nowodziński

Owner: changed from Frederico Caldeira Knabben to Olek Nowodziński
Status: review → assigned

comment:31 Changed 11 years ago by Olek Nowodziński

Status: assigned → review

Pushed updates to both dev and tests.

  • Fixed failing magicline tests in IEs.
    • Caused by falling into QM.
    • Solved by appending fixDomain after the DOCTYPE.
  • Fixed failing paste dialog initial focus test.
    • Refactored test.
    • Added slight setTimeout to fix the issue.
  • Removed redundant fixDomain in bootstrap code, which is also added when calling document.write()

comment:32 Changed 11 years ago by Frederico Caldeira Knabben

Status: review → review_passed

comment:33 Changed 11 years ago by Olek Nowodziński

Resolution: → fixed
Status: review_passed → closed

Merged fix into master, dev (​​git:70fbb8d), tests (f58b6f0).

comment:34 Changed 11 years ago by Jakub Ś

#10563 is continuation of this ticket.

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