Re: [orion-dev] how to disable sandboxing?

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

I understand the scenario, but what I'm
saying is that Orion plugins (in their current form) weren't designed to
solve that problem... You're trying to achieve reuse by modifying the line-up
of plugins to suit your different application, which coming from OSGi is
a very natural thing to try. Maybe that's even a logical direction for
Orion plugins to go in the future, although the browser SOP isn't the only
problem you'll run into. Communication between Orion plugins is limited
to serialized JSON, which is another big limitation compared to what you
can do in page. Thornier still, modern web applications aren't just a wad
of _javascript_ that could be reused by inserting different scripts into
a page. There is also the HTML and CSS that you'll likely want to tweak
and customize hand in hand with the JS for any given application.

Having said that, the reuse problem
is real and we suffer from it within our existing Orion pages as well.
We are currently handling it with a combination of "privileged"
services registered directly by the page, helper functions (generateBanner,
createFileCommands, etc) and good old copy & paste. I think there are
two paths forward:

1) Orion plugins evolve to allow richer
integration and interaction, contributing not only services but also HTML
and CSS directly into the page. This could enable reuse and modularity
similar to OSGi bundles.
2) We use or come up with some other
mechanism to enable customization and reuse of pages or page fragments,
and orion plugins remain a narrow keyhole for secure inter-host communication.
Most large scale web apps use some form of server side page construction
like Python/Rails/PHP/JSP/ASP, but it might be possible to create a pure
client-side equivalent. On the CSS side Anton has investigated using LESS
to allow better customization and reuse of CSS for example.

In Orion's current form, you can probably
only get the full level of customization you are looking for by creating
your own pages. Each of our pages is primarily three files: an HTML file,
a CSS file, and a "glue code" script file. The glue code primes
what services are defined within that page. If you wanted a fully customized
navigator, you would need to copy those three resources and modify them
to suit your needs. Tweak the CSS to change the appearance and visual behaviour,
the HTML to add or  remove page elements, and the glue code script
to add or remove services. Since the services registered here run directly
in the page they are more powerful than what you can do from a plugin.
Hopefully the bulk of the real Orion functionality can be directly reused
so this isn't quite as bad as it sounds. Here's a pointer to the "three
files" for the navigate page:

https://github.com/eclipse/orion.client/tree/master/bundles/org.eclipse.orion.client.core/web/navigate

That's not a very satisfying answer
and we clearly need to come up with something better, but I think that's
where we are at the moment.

John



From:      
 Rafael Chaves <rafael@xxxxxxxxxxxx>
To:      
 Orion developer discussions
<orion-dev@xxxxxxxxxxx>, 
Date:      
 12/17/2012 02:55 PM
Subject:    
   Re: [orion-dev]
how to disable sandboxing?
Sent by:    
   orion-dev-bounces@xxxxxxxxxxx

---

I can't help thinking this disconnect is due to coming
from an OSGi/eclipse architecture where everything is a plugin.

That is probably the case, John. So much that I can't
fully comprehend your points.

I have no use for adding my own pages, I just want to
contribute to (or plug into) existing pages. How can I do that cleanly,
without directly modifying somebody's page implementation? As far as I
know, it has to be via a plug-in, and with that comes a whole bunch of
restrictions, even though they come from the same host. 

So, my scenario is:

1) I own an Orion instance
2) I am using pages from others (like navigator, shell,
editor etc)
3) I want to cleanly contribute services to those pages

Right now I am using a plugin (configured in the Orion's
instance default.pref). But I am facing all sorts of limitations because
of security restrictions etc. Is there a better way of doing that?

Cheers,

Rafael

On Mon, Dec 17, 2012 at 11:39 AM, John Arthorne <John_Arthorne@xxxxxxxxxx>
wrote:
I can't help thinking this disconnect
is due to coming from an OSGi/eclipse architecture where everything is
a plugin. In Eclipse/OSGi everything is a bundle, and each bundle has the
full expressive power to do absolutely anything in the system. The only
way to provide or consume services in OSGi is via a bundle.  In Orion,
everything is most certainly *not* a bundle. An Orion plugin is simply
a mechanism for inter-frame (host) communication. They are not a unit of
modularity or reuse. If you look at the implementation of the "built
in" Orion pages, there are lots of services but not many plugins.
Most services are created directly by the page and have all the power of
in page scripts. In this model, disabling the sandbox for plugins from
the same host is a non sequitur - if the services are provided by the same
host then they don't need to be in a plugin. Maybe there is a reason for
this that I'm missing... 

John 





From:        Mike
Wilson/Ottawa/IBM@IBMCA 
To:        Orion
developer discussions <orion-dev@xxxxxxxxxxx>,
Date:        12/17/2012
02:16 PM 
Subject:        Re:
[orion-dev] how to disable sandboxing? 
Sent by:    
   orion-dev-bounces@xxxxxxxxxxx

---

Rafael,

I thought you were going to help us figure out how to solve this problem?
Instead of re-iterating your original position, try to describe exactly
what you'd like to be able to do, maybe even with example API, etc.  Bug
393711 is a starting point, but you (and Simon) need to flesh out details,
before we can think about implementing it.

McQ.

Rafael
Chaves ---2012/12/17 12:36:04---This bug report suggests sandboxing of
plugins can be disabled: https://bugs.eclipse.org/bugs/show_b

From: Rafael Chaves <rafael@xxxxxxxxxxxx>
To: Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date: 2012/12/17 12:36
Subject: [orion-dev] how to disable
sandboxing?
Sent by: orion-dev-bounces@xxxxxxxxxxx

---

This bug report suggests sandboxing of plugins can be disabled:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=393036

Could someone please shed a light on how sandboxing of plugins is
implemented in Orion and how it can be turned off (even if it requires
gutting some code in Orion)? I will then try to look into a way of
selectively disabling it (say, for plug-ins coming from the same
host/port), basically to address
https://bugs.eclipse.org/bugs/show_bug.cgi?id=393711.
 If my knowledge
of _javascript_/browser security model wasn't so spotty I am sure I
could find it on my own.

<rant>
I am hitting orion-dev because I think this is of architectural
interest. The differences between "built-in" and plugin code
are an
overwhelming limitation in Orion as is today. It is either the case a
use case was foreseen in some extension point or it just can't be done
(usually because of sandboxing), and that seriously cripples
innovation on top of Orion.
</rant>

You pointers/directions are appreciated. Keep up the good work.

Rafael
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev

_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev


_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev

_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev