17 Oct
2008
17 Oct
'08
12:55 a.m.
hello,
I would like to be able to import an external Javascript using its URL in
the head of the HTML page using the same model as JSX extension...
something like:
$xwiki.jsx.use("url:http://my_url_to_my_external_js")
but JSX always translates the URL into a JSX action...
It would really be practical for importing external JS APIs...
What do you think about this possible extension to Skin extension?
Is there already another way of doing this?
regards
Pascal
17 Oct
17 Oct
1:29 a.m.
New subject: [xwiki-devs] JSX skin extension: why not importing external JS based on URL?
Pascal Voitot wrote:
hello,
I would like to be able to import an external Javascript using its URL in
the head of the HTML page using the same model as JSX extension...
something like:
$xwiki.jsx.use("url:http://my_url_to_my_external_js")
but JSX always translates the URL into a JSX action...
It would really be practical for importing external JS APIs...
What do you think about this possible extension to Skin extension?
Is there already another way of doing this?
We're planning on supporting filesystem files like this (patches welcome
;) ), but I'm not sure about external URLs. Some problems we must consider:
- Server access to external URLs: since the jsx plugin puts it through
the /jsx/ action, the server must be able to download the file. I think
some of our more paranoid users don't allow this from the internal
servers (request being pushed through a gateway, while the internal
servers are completely offline)
- Performance: as above, since the file must be downloaded from a remote
site, if the caching is not well done the request will take longer to
complete.
- External Point of Failure: if the external resource becomes
unavailable, a part of the wiki will stop to work, and users will not
know the real cause and blame the wiki.
- Security concerns: since the js now comes from an external source, but
the browser sees it as coming from the same server, it will have
different rights on the client, thus allowing CrossSite scripting.
- Security concerns: since any part of the document can pull in a skin
extension, even a comment, it will be easy to do some crosssite
scripting in a not so well secured wiki.
I know that this would be useful for developers, but security is
important, too. From my PoV, it is better to include that external
service as a local JSX object.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
9:10 a.m.
On Fri, Oct 17, 2008 at 1:29 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
Pascal Voitot wrote:
I have the same pov as you but I have encountered the bad case :)
Google APIs... (I'm not using XWiki in the case of a closed intranet wiki)
you need to insert before any code something like:
<script type="text/javascript"
src="http://www.google.com/jsapi?key=*ABCDEFG*"></script>
Then you write some JS code based on google objects and I wanted to use this
code through the JSX extension.
But as JSX puts a link in the head of the HTML doc, if the upper script is
not found before, your JS code will never work.
The only solution I have found is to change the skin header in
javascript.vm. But it breaks the concept of lazy loading brought by JSX...
Pascal
hello,
I would like to be able to import an external Javascript using its URL in
the head of the HTML page using the same model as JSX extension...
something like:
$xwiki.jsx.use("url:http://my_url_to_my_external_js")
but JSX always translates the URL into a JSX action...
It would really be practical for importing external JS APIs...
What do you think about this possible extension to Skin extension?
Is there already another way of doing this?
We're planning on supporting filesystem files like this (patches welcome
;) ), but I'm not sure about external URLs. Some problems we must consider:
- Server access to external URLs: since the jsx plugin puts it through
the /jsx/ action, the server must be able to download the file. I think
some of our more paranoid users don't allow this from the internal
servers (request being pushed through a gateway, while the internal
servers are completely offline)
- Performance: as above, since the file must be downloaded from a remote
site, if the caching is not well done the request will take longer to
complete.
- External Point of Failure: if the external resource becomes
unavailable, a part of the wiki will stop to work, and users will not
know the real cause and blame the wiki.
- Security concerns: since the js now comes from an external source, but
the browser sees it as coming from the same server, it will have
different rights on the client, thus allowing CrossSite scripting.
- Security concerns: since any part of the document can pull in a skin
extension, even a comment, it will be easy to do some crosssite
scripting in a not so well secured wiki.
I know that this would be useful for developers, but security is
important, too. From my PoV, it is better to include that external
service as a local JSX object.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5872
days inactive
5873
days old
2 comments
2 participants
participants (2)
-
Pascal Voitot -
Sergiu Dumitriu