#123 closed New Feature (fixed)
Support for domain relaxing
| Reported by: | Owned by: | Frederico Caldeira Knabben | |
|---|---|---|---|
| Priority: | Normal | Milestone: | FCKeditor 2.6 |
| Component: | General | Version: | |
| Keywords: | Review+ | Cc: |
Description
Please provide support for domain relaxing.
In order to do some cross domain ajax requests for our internal sites, I would like to change our pages to set the document.domain to our intranet domain (domain relaxing: http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/properties/domain.asp). However, doing so causes fckeditor to break. This is because domain relaxing requires all frames that want communicate through javascript to have the same document.domain. I did a search and replace through the fckeditor files and I was able to set the document.domain on almost everything. However I get an access restriction. The fckpanel uses window.createPopup for IE. Microsoft's documentation (http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/methods/createpopup.asp) states:
Note Pages that change the document.domain property before creating the popup object may receive an 'Access is denied' error message when accessing the popup object. Changes made to document.domain in the calling page will not propogate to the new popup object; this is currently a design restriction to limit access with the popup object.
I also tried to force it to go down the non IE pathway, but that doesn't work within IE.
Attachments (3)
Change History (18)
comment:1 Changed 17 years ago by
comment:2 Changed 17 years ago by
I just did a search for
<head>
and replaced with
<head><script type="text/javascript">document.domain="mydomain.com";</script>
It produced 61 changes. This was just a hard coded attempt to see if I could get it to work, but certainly not robust enough.
Idealy the document.domain would be set in the config file like everything else. However to access the configuration already loaded in anothe frame, the child frame would need to have the document.domain already set.
A possible solution would be to create a seperate js file that just sets the document.domain. All frames and html pages would put that script as the first thing they do in the head. Then the developer using fckeditor would just need to update that one file to set the document.domain.
comment:3 Changed 17 years ago by
Domain relaxing would be very fine. I also tried to implement FCKeditor in SAP EP, but EP uses domain relaxing. So usage is very limited because there is only the choice between disabling relaxing (some SAP scripts are not working) or not using FCKeditor (and use the ugly SAP Editor).
comment:4 Changed 17 years ago by
| Milestone: | → FCKeditor 3.0 |
|---|
comment:5 Changed 17 years ago by
I've had to work on this particular problem recently, and though I haven't fully solved the issues with it, I have made considerable headway that I'd like to share.
First of all, it is actually possible to retain use of the createPopup method in IE. In order to be able to access it, you need to create the popups and set their domains before you set the domain on the page within which they are created (it should be fckeditor.html). The issue of course is that you need to know how many of those popup instances you'll need ahead of time, and as I'm not sure of the entire scope in which those popups are used I'm not sure if that's actually possible to know when you create them. However, if it turns out to be impossible to know for sure how many of them are needed, it may still be possible to maintain a popup pool of sorts, and simply recycle them.
The iframes that fckeditor users are a bit more troublesome, as you cannot access the document contained within any dynamically created iframes once they're created, so createElement doesn't really work. What you can do instead is give the iframe an src attribute pointing to a blank html file in which there is a small script to set the domain. This however introduces another issue, that of a potential race condition, where if you try to act upon that iframe immediately after creating it and setting its src, there is the potential for the page to not yet be loaded and as a result, the domain will not be set resulting in Access Denied errors. This can be avoided by creating the iframes ahead of time, and as suggested for the popups, maintain a pool of iframes which you can simply recycle.
While I found that this worked, it is a bit messy and still introduces the potential for failure. It's possible that instead you might be able to create the pool simply by using document.write to generate not only the iframe, but its contents as well, including the domain setting; this way you avoid any issues with load times.
As for a script to set the domain. I could be wrong, but as I understand domains, they can't actually be used to access domains that are not a suffix of the original domain, so for instance if my domain was dev.fckeditor.net, I could not change it to google.com, I could only reduce it down to fckeditor.net. As such, there's no need for the user to set anything in the config, you can simply use javascript to dynamically determine if the domain needs to be changed (just trying to set something on the parent within a try catch block) and then if it does, iteratively strip more and more off the domain until you get one that works.
comment:6 Changed 16 years ago by
| Owner: | set to Frederico Caldeira Knabben |
|---|---|
| Status: | new → assigned |
comment:7 Changed 16 years ago by
| Keywords: | HasPatch added |
|---|---|
| Milestone: | FCKeditor 3.0 → FCKeditor 2.6 |
I've attached a proposal for a fix to this issue.
It was really hard to workaround all different browsers' bugs around this problem. After a lot of trial/error and intuition, some solutions came to light. It's not to say that everything is clear in the code, but that's the way it works.
Following Richard's comments:
- IFrames: the only problem here is IE. I was able to workaround it by setting the domain in the initial "src" assignment. The tricky thing here was make it work under HTTPS without security warnings, and avoid having unnecessary entries in the browser navigation.
- Popups: worked well with IE7. With IE6, we had issues, but I've found that it's enough to set the domain back to the original value right before creating the popup to overcome the problem. It seams it is still an issue with IE5.5, but for now I'm accepting to not have document.domain compatible with that browser.
- Auto-detection: you (Richard) was completely correct with your assumption. I've implemented it in a way that it automatically detects the domain setting, so no entries are needed in the configuration file.
It seams that some important and more complex systems make extensive use of document.domain, which makes this feature extremely important for us. I'm anticipating it to the 2.6. I'm not committing it right now as we are working to stabilize version 2.5. I'll commit it right after that release.
Changed 16 years ago by
| Attachment: | 123_2.patch added |
|---|
comment:8 Changed 16 years ago by
| Keywords: | Review? added; HasPatch removed |
|---|
I've updated the original patch to the current HEAD and added the changelog entry for it.
comment:9 follow-up: 11 Changed 16 years ago by
I think that one thing that it's missing it's a clear explanation of what are the advantages of this new system.
How it can be used, where it can be used, what it can do and the things that it doesn't allow. It can help to review exactly what must work instead of doing tests for things that just can't work.
The changelog entry is only "Full support for document.domain with automatic domain detection", but I'm sure that it won't tell too much.
So for example (these are my assumtions):
This doesn't change anything if someone wants to interact between mydomain.com and otherdomain.com
It won't change also anything regarding to mydomain.com and mydomain.net
It doesn't change anything between http://mydomain.com and https://mydomain.com
It doesn't change anything between http://mydomain.com:80 and http://mydomain.com:1080
It does allow (i'm guessing) to use the fckeditor placed in www.mydomain.com from admin.mydomain.com
It does allow to use also the filemanager in that configuration
What else?, any specific example about how it could be useful?
The second question is regarding to the new floating panels, as this code changes the dialog code I guess that it will have to be reviewed in order to apply both patches.
comment:10 Changed 16 years ago by
The document.domain feature present in browsers is quite unknown for many. Our intention here is not really teach those who don't know what it is, but to provide compatibility with document.domain to those who know how and need to use it. Of course, we can dedicate a page in the documentation just to explain it, but this is not related to the ticket.
The idea is quite simple. Two frames are able to interact through code, only if both share the same document.domain. This makes it possible to a page from www.example.com interact with an iframe coming from assets.example.com. All we need is set document.domain to "example.com" in both pages.
It doesn't mean that www.example.com can interact with www.google.com, even if both would have tried to set document.domain. This is not possible because, by definition, browsers restrict the possible changes to document.domain only to a superdomain. So, www.example.com, can set it to "example.com", but not to "example.net" nor "hackme.example.com".
This is an advanced feature, which can be found in advanced sites and softwares.
Testing it is quite simple. I'm running FCKeditor locally at "dev.fckeditor.local". In my case it is enough to append the following line of code as the first line in sample01.html:
document.domain = 'fckeditor.local' ;
You will see that the above line will break FCKeditor 2.5, causing security errors.
comment:11 Changed 16 years ago by
Replying to alfonsoml:
The second question is regarding to the new floating panels, as this code changes the dialog code I guess that it will have to be reviewed in order to apply both patches.
Yes. I've already advised Martin about it. We need to commit this ticket first, to be able to work to close #35.
comment:12 follow-up: 13 Changed 16 years ago by
| Keywords: | Review- added; Review? removed |
|---|
Popup dialogs are not working with IE7 (and IE6 as well, though Fred said it's not supported).
Steps to reproduce problem:
- Have fckeditor.local and www.fckeditor.local point to the same IP (modify hosts file if needed).
- Modify sample01.html in fckeditor.local such that it's document.domain is 'fckeditor.local' before creating the oFCKeditor object.
- Open sample01.html via www.fckeditor.local in IE7.
- Open the "Add Smiley" dialog.
- Error: window.dialogArguments.Editor is null or not an object.
Changed 16 years ago by
| Attachment: | 123_3.patch added |
|---|
comment:13 Changed 16 years ago by
| Keywords: | Review? added; Review- removed |
|---|
Replying to martinkou:
Popup dialogs are not working with IE7 (and IE6 as well, though Fred said it's not supported).
I've attached a new patch. The error were being thrown because of changes to trunk made after the first patch proposal. I've fixed it.
Also, it is completely supported on IE6. Maybe my previous comments to Richard's comments created some confusion.
comment:14 Changed 16 years ago by
| Keywords: | Review+ added; Review? removed |
|---|
The new patch works. Tested on IE6, IE7, FF2 and Safari 3.0.4. Since context menus aren't working in the newest Opera 9.50 internal testers build, it's not tested at the moment.
comment:15 Changed 16 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Committed with [1192]. Click here for more info about our SVN system.
Due to the popup limit you have described, this feature could be developed only after a review of the popup system to not use createPopups, which is planned, but is not a priority in the moment.
For now, it would be nice to have a list of the points you have found in the editor code that needs changes to make it work.