ReferenceLookupWindowField doesn't accept absolute external links

[Samuel Schluep]

The ReferenceLookupWindowField Formulator widget does not accept external links.
If "http://server/path" is entered by hand into the text input field of the
widget, the "http://server" part is deleted when updating the a code source
containing such a widget. This behavior is different from the link input field's
behavior. In my opinion the "http://server" part should not be deleted in order
to allow internal and external references.

[Eric Casteleijn (thisfred)]

Hmm, I think this was not accidental: the reference lookup field stores
references to zope objects, not urls, as far as I can see in the code. We may
want to think about having some other field type that stores urls, which would
accept both external and internal links, so that it would also work with a
lookup button. In fact that *is* what the link object does. Should we add a
formulator field like that?

[Kit Blake (kitblake)]

Samuel said:
My multimedia code sources for Flash, Java Applets, Quicktime use the lookup Formulator widget to allow user friendly object embedding. However, there are use cases, where you want to embed a multimedia object stored on another server than the base CMS server. For example a Flash object makes calls to some C programs on a scientific server in order to retrieve data (through some cgi or PHP interface). For security reasons only Flash objects coming from the same scientific server are allowed to access the C programs. As the CMS is a separate server, at least the Flash object should be retrieved from the other address.

Therefore, IMHO we should have a formulator field like that.

[Kit Blake (kitblake)]

This limitation is something I noticed a while back and therefore made the Network Image code source. The underlying thinking in Silva is that there's no way for users to embed anything from another site that could be malicious. A user can link to anything, as both the link field and the link object do. But you can't for instance embed a foo.js file from another site in a document. Of course if the user is a manager, that can be done in a code source template, and/or by adding a string field parameter, but via the 'normal' SMI interface it's not possible.

I'm not saying we shouldn't create the field, only that site managers need to be informed about the risk of abuse if they install the code source.

If we do create the field, users can drag and drop locations, images, and links from another browser window onto the field. No typos!

[Kit Blake (kitblake)]

Ummm, I think this is already done. I just discovered that there are two fields: LookupWindowField and ReferenceLookupWindowField. The RLWF strips the http while the LWF doesn't. Samuel, try using a LWF instead of a RLWF and I think you'll have the result you want.

[Samuel Schluep (schluep)]

Thank you for the hint. The LookupWindowField works in my case as expected. I should have looked better at the fields available before. Sorry for the inconvenience :-(