htmlArea

A directory of browser-based WYSIWYG editors

  MAIN
INDEX
SEARCH
POSTS
WHO'S
ONLINE
LOG
IN

Home: htmlArea 3 (beta): htmlArea 2 & 3 archive (read only): htmlArea v3.0 - Discussion:
cross domain support


The htmlArea 2 & 3 editors have been discontinued.

We've made these forums available as a read-only reference and knowledge-base for people using or developing editors based on htmlArea 2 or 3.

Anyone who is interested in taking over version 2 or 3 is free to do so. All we ask is that you choose a new name that doesn't have "htmlarea" in it to avoid confusion with this site. We'll even give you a link in the directory to make it easier for people to find you. If you are developing or hosting an htmlArea based-editor under a new name, please submit it to our directory.

 


grover77777
New User

Sep 9, 2003, 12:50 PM

Post #1 of 8 (2022 views)
Shortcut
cross domain support Can't Post

On a clustered server, if you change the document.domain to its second level domain (heck, even just changing the domain to itself), htmlArea will give permission errors on dialogs with the showModalDialog method when it is used. Is there any way around Microsoft's security "fix" to the showModalDialog method?. It violates the DHTML object security model with this behavior. Any help is supported.

Thanks,

Paul


Denver Dave
User

Sep 9, 2003, 3:45 PM

Post #2 of 8 (2017 views)
Shortcut
Re: [grover77777] cross domain support [In reply to] Can't Post

Hi Paul - I'm really glad to have someone to exchange ideas with about this.

Somehow, in general opensource software's idea of reuseable code is to copy the code over and over and over with each installation. I much prefer to install once and call the service. With version 2, I was able work well across domains with some amount of smoke and mirrors.

I was waiting for Version 3 to settle down a little bit, before I tried to get it to work across domains, but before this post I gave it an first step and part of the functionality seemed to work, but it was very slow. So my discussion has more to do with version 2, but hopefully, similar techniques will work with version 3.

(1) Paths. Even if everything worked right off, we would still have to know where to go find things like scripts and images. In some cases there seem to be paths defined, but then not used with the path hard coded - see discussion: http://www.interactivetools.com/iforum/Open_Source_C3/htmlArea_v3.0_-_Beta_Release_F14/htmlarea.js_image_paths_P16573/

(2) Popup windows are an interesting challenge. Technically speaking, I'm not sure that a window from one domain can update a window from another domain. However, whoever said the actual windows had to be in different domains? Just the directions for the functionality and images. By using PHP, I pass a parameter to a call to the original edit window and open a new "popup" window in the client domain. Then the php script and javascript is smart enough to go get whatever scripts and point to images it needs from the server domain, include it with the client popup window and presto changeo we have a popup window built with instructions from the server. This was very tricky for me to get right, but once done, I just set a few flags and the edit capability is available for any domain on my server. ( I have not tried cross server - I installed once for each server and used for many domains on the server)

If others are interested, we can go script by script and see if we can identify changes that need to be made in order to run with one installation and be used by many domains on the same server. The use of path variables would certainly make upgrades much easier.

Might as well work on the cross domain - I've pretty much given up on a mere mortal ever getting the Spellchecker to work without admin access to the server <sigh>: http://www.interactivetools.com/iforum/Open_Source_C3/htmlArea_v3.0_-_Beta_Release_F14/Standard_Aspell_installation_on_Linux_P16014/


grover77777
New User

Sep 9, 2003, 5:37 PM

Post #3 of 8 (2013 views)
Shortcut
Re: [Denver Dave] cross domain support [In reply to] Can't Post

Good points you have.

However, whoever said the actual windows had to be in different domains?

Well, the network architecture does :)... and I don't mean different domains as in www.abc.com and www.xyz.com like it seems you have, I mean domains such as cluster.abc.com and server server10.abc.com. And technically, the windows are in the same domain. (once changed with document.domain) It sounds like you have multiple domains on the same server. I have the same second-level domain on multiple servers. You probably won't have that issue if each domain includes the htmlArea director with an aliased domain to it... or however you want to state that, since everything would then run in the same domain.

Basically, much of the problem arises because of the clustering... the server, for example, cannot save files to itself, because it can be one of many servers you are accessing... (cluster) it would be on cluster1.abc.com, but not cluster2 or cluster3. So, another server is set up, speciically for saving files... server10. Now all applications from cluster can call server10 and place the htmlArea in its pages and use the file upload/etc there. However, some issues I have had are when changing document.domain to abc.com, instead of cluster.abc.com or server10.abc.com, showModalDialog method does not work. Specifically, dialogArguments are inaccessible.

This problem may be outside of this project, but this project does use the method.

Through further study, I have found even if I set document.domain equal to itself (I know you would not want to do that normally, but am doing it to prove a point) then showModalDialog dialogArguments do not work...

Further study reveals:

http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/methods/showmodaldialog.asp

"Because a modal dialog box can include a URL to a resource in a different domain, do not pass information through the vArguments parameter that the user might consider private."

OK, so from that quote I would gander that modal dialog boxes should work cross domain, but even if I change the document.domain=document.domain; then dialogArguments have permission denied.

OK, so I said maybe it's Microsoft's security issue:

http://support.microsoft.com/default.aspx?scid=kb;en-us;814458 (you may have to paste this link manually)

"WORKAROUND Contact the administrator or content developer for the Web site to resolve this issue. Content developers who must set the domain property for the dialog window to another value but must still have access to the dialogArguments property values can work around this issue by creating a local variable to store the dialogArguments value before the document.Domain property is used to change the domain. After the domain change, the local variable can be used in the rest of the script to use the information that was passed to the showModalDialog or showModelessDialog method as arguments."


(P.S. Don't you love how they say... contact the administrator or content developer.... they always do that.. hello MS... I am the developer and administrator, who do you think is looking at this.. the end user?, sorry for the rant Smile )


OK, so I create a local variable, but once the document.domain is changed (even to itself), the dialogArguments get permission denied. Maybe I am just doing this wrong, but I've tried it like 10 ways. Something goofy is going on there, and I think it is the way Microsoft laid out this security fix. There is absolutely no documentation anywhere, that I have found, that explains, in detail, how this actually works now. As for your other comments, I am attempting to take any server in the general .abc.com domain, and have it access this one server that hosts HTMLArea... not only that, but it provides for the ability for other architectures to call this WYSIWYG editor. That is what reusable code is. Not only for technical reasons, but also, for ease of maintenance and use, I wish to only use one server to host this editor across the .abc.com domain. I guess my only hurdle is to get past the showModalDialog part. I suppose I could change all of the showModalDialog methods to open a window that emulates showModalDialog by using layers to hide other window or just switch the focus back when trying to leave, but these seem tacky and really don't solve the actual issue I am looking at.

As far as the paths, yes, it looks like we'd have to add these or create these, another option is to get the path, from the image, from the parent's window in a hidden text field possible? But that is kind of tacky also. But with that, you could create a hidden text field for path, and then the image dialog could access that... it would save from having upgrades to the core htmlArea destroy any customization there.

It's a great product, but 3.0 still kinda buggy with tables... Good job, we appreciate all of the developer's work with this. :)

As for aspell.. .:) I had su access... maybe u want to start a thread to help you with that. If you do, include the type of system you're using.

Paul


(This post was edited by grover77777 on Sep 9, 2003, 5:44 PM)


Denver Dave
User

Sep 9, 2003, 8:15 PM

Post #4 of 8 (2004 views)
Shortcut
Re: [grover77777] cross domain support [In reply to] Can't Post

Paul - you give me too much credit for what I was trying to do.

Images and javascripts can be pulled in from any publically accessable server, so as you indicated, the issue really is with the dialog windows.

OK, if a dialog window can not share info with a window in a different domain, let's cheat and open both in the same domain. Remember I want to install once and use with many domains - I don't care how I do it as long as the each of the client domains has htmlArea edit capability without having to separately install htmlarea for each client domain.

So when I need a dialog window from an edit window in the client domain, I call either a dummy window (a window that does not know anything on its own) or even better the existing edit window as a modal dialog but pass it a paramenter such as:

// ****** davehack ********
var newcolor = showModalDialog(base_window + "?popup=select_col",

(note base_window is the client domain edit window varies by client)

Then in the base window script:
if (IsSet ($popup))
{
switch($_GET['popup'])
{
case 'fullscreen':
include 'http://serverdomain.com/htmlarea/popups/fullscreen.html';
break;
case 'insert_tab':
include 'http://serverdomain/htmlarea/popups/insert_table.html';
break;
case 'select_col':
include 'http://serverdomain/htmlarea/popups/select_color.html';
break;
case 'insert_ima':
include 'http://serverdomain/htmlarea/popups/insert_image.html';
break;
case 'aboutxxxxx':
include 'http://serverdomain/htmlarea/popups/about.html';
break;
case 'editor_hel':
include 'http://serverdomain/htmlarea/popups/editor_help.html';
break;
default:
echo $_GET['popup'] . 'not found';
}
exit;
}

So basically if the modal dialog window has to be in the same client domain as the edit window - let it be in the same domain by opening the same edit window as modaldialog and make the dialog window interagate the server to figure out the "guts" of how it should behave based on a parameter that defines what popup window it should act like.

I had some javascript issues in the popup html, but the basic idea is above.


grover77777
New User

Sep 12, 2003, 3:40 PM

Post #5 of 8 (1965 views)
Shortcut
Re: [Denver Dave] cross domain support [In reply to] Can't Post

Great.



I finally worked around the showModalDialog issue... because of Microsot's security fix, myserver.mydomain.com that I set it to is not the same as the myserver.mydomain.com that the page defaults to. To resolve the issue, all pages use document.domain=mydomain.com EXCEPT when I call showModalDialog, I switch to myserver.mydomain.com. The dialog page must also be set to myserver.mydomain.com. (I did not set the dialog to myserver.mydomain.com earlier, and it didn't recognize them as the same domain, even though the strings matched) Upon returning from the method, I set document.domain back to mydomain.com. It seems to have resolved the issue.



Thanks for everyone's help.



Paul


LogicMan
Novice

Dec 10, 2003, 1:22 PM

Post #6 of 8 (1583 views)
Shortcut
Re: [grover77777] cross domain support [In reply to] Can't Post

 


klex
Novice

Jun 17, 2004, 9:06 AM

Post #7 of 8 (999 views)
Shortcut
Re: [grover77777] cross domain support [In reply to] Can't Post

hy guys!

I have the same cross domain problem and there is no chance to change the constellation. what and where do I have to change my javascript-code. the editor is shown correctly but after clicking a button for a popup I get the following Error: uncaught exception: Permission denied to get property Window.Dialog

maybe you have a solution for me.

thanks in advance


klex
Novice

Jun 23, 2004, 1:54 AM

Post #8 of 8 (953 views)
Shortcut
Re: [grover77777] cross domain support [In reply to] Can't Post

Hello!

please can you send me an example of one popup and the scripts with the changed or inserted code. I have still a problem with cross domains.

thanks

klemens

 
 
 


Search for (options)