[sugar] Integration with web apps (and Moodle specifically!)

Ian Bicking ianb
Mon Sep 4 16:53:35 EDT 2006


Ivan Krsti? wrote:
> Ian Bicking wrote:
>> So are we talking about laptops identifying themselves to other laptops?
> 
> Yes. That's where the emergent PKI idea comes in.
> 
>> Or even the laptop identifying itself to... itself?  If HTTP-based RPC
>> is a major means of communication inside the system, then one can
>> imagine a need for identification.
> 
> Generally, this isn't an issue. Local web apps execute within the
> microserver; to do this, they already had to be trusted in some way.
> Once they're running, they can access system services via the
> microserver, which brokers D-Bus (or something else if needed) on their
> behalf.

What about local content?  Javascript content on a host can open 
XMLHttpRequests to the same host, so any content on localhost that isn't 
scrubbed could initiate any kind of RPC to localhost.

One resolution would be to display no content on localhost.  You could 
just create another alias for localhost, e.g., localcontent, and 
Javascript cross-domain restrictions would keep XMLHttp from being a 
problem.  Or you could even try to keep content as its "real" location, 
relying on a proxy to use the local content when it is available.  This 
probably has several advantages, though of course it's more complicated 
to implement.

>> # Student gets some popup -- like HTTP Basic login, except it doesn't
>> # ask for username/password; maybe it asks for an identity, plus
>> # confirms that a login should occur; maybe offers to automatically
>> # login in the future?
> 
> I think a whitelist-driven approach is right here. Really, the only
> situation where you want to communicate and authenticate the full
> identity is e.g. to the school server, or to other laptops in direct
> physical proximity. Everything else should be rejected by default. If
> we're popping up a yes/no dialog to protect the kid's privacy, we've
> already lost.

Would it be akin to how popup blocking works in Firefox (and extension 
installation)?  I.e., reject by default, but notify the user of the 
rejection and allow them to change that decision.

>> I guess something like a common identity system would be the sort of
>> thing that would make up what Martin was talking about as a "web app
>> framework".  That's not normally what's talked about as a "framework",
>> but I'm not sure what to call it, and I can certainly see the value.
> 
> Right. A common identity identity broker of some variety that runs on
> the school servers will definitely be provided, allowing any application
> to call into it via a stable API.

Would it have to be a broker, or could this just be a protocol with 
library implementations in the environments most likely to be relevant 
(Python, PHP, Ruby, whatever).  Deploying and interacting with a 
separate process tends to be a headache for developers.


-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org


More information about the Sugar-devel mailing list