Re: [Sugar-devel] [PATCH] webactivity: seed the XS cookie at startup
On Thu, Feb 19, 2009 at 7:20 PM, Simon Schampijer si...@schampijer.de wrote: Martin Langhoff wrote: On Tue, Feb 17, 2009 at 11:03 AM, Simon Schampijer si...@schampijer.de wrote: Well, your call - using the schoolserver url then? The fqdn from backup server or jabber server. Either will do until we fix the registration stuff. Please state exactly which one you want - I want this to be your call. Ok. Both are wrong, and I'm good at being stoned for picking a wrong setting. The jabber server is at least recorded as a fqdn, so let's use that. Backup server is recorded as u...@fqdn:path . And let's make sure we fix registration and these values in the next feature work cycle :-) For the time being, ejabberd, backup and moodle are quite tightly bound together -- this is not a good long-term thing, but a fact of life in the short-term. cheers, m -- mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] webactivity: seed the XS cookie at startup
The fqdn from backup server or jabber server. Either will do until we fix the registration stuff. Please state exactly which one you want - I want this to be your call. How about adding a layer of indirection and letting DNS do the binding? -- I'm not a DNS wizard. DNS has C records which are roughly symbolic links. -- These are my opinions, not necessarily my employer's. I hate spam. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] webactivity: seed the XS cookie at startup
On Thu, Feb 19, 2009 at 10:08 PM, Simon Schampijer si...@schampijer.de wrote: Ok, I pushed to browse git master now. Do you have a way to test if it is working fine against a schoolserver or should I create you the 0.82 xo bundle? I have a git checkout - but on the 8.2.x so master won't work there. I'm rebasing your patch on the sucrose-0.82 branch to test, replacing gconf calls with profile.foo... cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] webactivity: seed the XS cookie at startup
On Tue, Feb 17, 2009 at 12:17 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Tue, Feb 17, 2009 at 11:03 AM, Simon Schampijer si...@schampijer.de wrote: I take it you're happy to fix things up so that the 2 branches are reasonably in sync? Thanks! a git fetch from 'mainline.git' doesn't show any activity. I'm more than happy with the edits you've done on my patch, and the edits notes in the discussion. I'd just would *love* to see this patch on both 'master' and s-0.82, and perhaps a release on that s-082 branch, so deployments can start shipping that with my super moodling code. Are there any blockers? Perhaps this being held by the Perl rewrite you mentioned? m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] webactivity: seed the XS cookie at startup
Martin Langhoff wrote: On Tue, Feb 17, 2009 at 11:03 AM, Simon Schampijer si...@schampijer.de wrote: Well, your call - using the schoolserver url then? The fqdn from backup server or jabber server. Either will do until we fix the registration stuff. Please state exactly which one you want - I want this to be your call. Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] webactivity: seed the XS cookie at startup
Martin Langhoff wrote: On Tue, Feb 17, 2009 at 12:17 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Tue, Feb 17, 2009 at 11:03 AM, Simon Schampijer si...@schampijer.de wrote: I take it you're happy to fix things up so that the 2 branches are reasonably in sync? Thanks! a git fetch from 'mainline.git' doesn't show any activity. I'm more than happy with the edits you've done on my patch, and the edits notes in the discussion. I'd just would *love* to see this patch on both 'master' and s-0.82, and perhaps a release on that s-082 branch, so deployments can start shipping that with my super moodling code. Are there any blockers? Perhaps this being held by the Perl rewrite you mentioned? m Please just reply to the other mail and I can push the patches. As I am swamped things take a bit longer. Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] webactivity: seed the XS cookie at startup
Martin Langhoff wrote:
On Sat, Feb 14, 2009 at 9:11 AM, Simon Schampijer si...@schampijer.de wrote:
Please find attached the patch against master.
Looks good to me (but I know nothing of what's changed in master...)
- i use the backup_url to see if we are associated with a schoolserver
- why did you use the jabber server for this 'xs_fqdn = prof.jabber_server'?
Good question. Neither is the right one. In a XS driven net, both are
equal. In a XS-on-the-internet situation, the public XS may decide
to not offer backup service. Of the 3 (moodle/webapps, xmpp, backup),
backup is the most burdensome on the server.
So I think there is a (very marginal) advantage to using the jabber
server. But the most important hting is that 0.82.x and master use the
same, so whatever you do, both should use the same...
Our registration URL is REGISTER_URL = 'http://schoolserver:8080/',
wouldn't the right Domain than be 'schoolserver'? Since the cookie is
about the registration with the schoolserver this makes most sense to me
(the jabber server could be somewhere else).
(The right fix is to have a 'schoolserver fqdn' entry in the
profile... but that's for the next Sugar dev cycle I guess...)
- c.execute('''CREATE TABLE IF NOT EXISTS
+ moz_cookies
+ (id INTEGER PRIMARY KEY,
+ name TEXT,
+ value TEXT,
+ host TEXT,
+ path TEXT,
+ expiry INTEGER,
+ lastAccessed INTEGER,
+ isSecure INTEGER,
+ isHttpOnly INTEGER);''')
- is the ';' correct here or a typo?
typo
ok;
- i only except for sqlite3.Error
Is that the only thing that could go wrong? My thinking has been: if
we fail, let the startup succeed. This is a good feature, but not a
showstopper.
- what bothers me a bit is that you don't get an error when the database
does not exist - sqlite creates a new one actually - so we might return as
well on 'if not os.path.exists(os.path.join(_profile_path,
'cookies.sqlite'))'
Well, all the calls in the try block are sqlite3 ones - if they fail -
we catch it. If something else goes wrong - we want to fail and not hide ;p
The DB does not exist on the first use of Browse. Actually, it does
not get created until the first website sets the first cookie, AFAICS.
That means that on the first use of Browse the user goes to the XS and
doesn't get autenticated. So if the DB doesn't exist, _we want to
create it_. It's not a failure, it's success.
Ok, sounds good.
- the method could even be a function as it does not interact at all with
the class itself, not sure what is nicer
I'd prefer a function, but it's not my codebase, so follow the style... :-)
Done.
BTW: Is there a spec you used for the cookie format? I find field
descriptions like expires - you name it expiry.
Thanks,
Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] webactivity: seed the XS cookie at startup
note that if the XS is acting as a proxy the cache issue can be addressed. The XS can get a copy of the XO client cert at registration time, and with it can decrypt the HTTPS traffic and cache the unencrypted version. this is a lot of cpu, but it's on the XS not the XO, so it shouldn't be as bad (and there are hardware SSL encryption cards available that can be put in an XS for high-volume situations) I'm not a security wizard, but I get uncomfortable when anybody suggests giving out copies of keys, certs, or passwords. Is this an acceptable case? Why? How would you explain the subtlies to a kid? How many adults give their passwords to phishers? -- These are my opinions, not necessarily my employer's. I hate spam. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] webactivity: seed the XS cookie at startup
On Fri, 13 Feb 2009, Martin Langhoff wrote: On Thu, Feb 12, 2009 at 11:54 PM, Simon Schampijer si...@schampijer.de wrote: Plan A - HTTPS to the rescue Just to understand better. Is the main issue that we have to change the protocol - or are you more worried about the CPU cost? Both. And also HTTPS network load, as HTTPS is a lot less cache-friendly. note that if the XS is acting as a proxy the cache issue can be addressed. The XS can get a copy of the XO client cert at registration time, and with it can decrypt the HTTPS traffic and cache the unencrypted version. this is a lot of cpu, but it's on the XS not the XO, so it shouldn't be as bad (and there are hardware SSL encryption cards available that can be put in an XS for high-volume situations) it's not just a matter of downloading a package and installing it, but it's not rocket science either. this would have the side effect of making the XS security even more critical, but I think that it's already critical enough that this won't really make much difference in how it's secured. David Lang ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] webactivity: seed the XS cookie at startup
On Mon, Feb 16, 2009 at 9:36 PM, Simon Schampijer si...@schampijer.de wrote: Our registration URL is REGISTER_URL = 'http://schoolserver:8080/', wouldn't the right Domain than be 'schoolserver'? Since the cookie is about the registration with the schoolserver this makes most sense to me (the jabber server could be somewhere else). Call me silly, but I really want to set it to the fqdn to avoid exposing the cookie too much. Browse.xo homepage links to http://schoolserver/ and that will match any wildcard dns entry, needlessly pushing out info that is better kept quiet. The XS will redirect to its own fqdn -- and there Browse.xo will send the cookie. Well, all the calls in the try block are sqlite3 ones - if they fail - we catch it. If something else goes wrong - we want to fail and not hide ;p This is of course a matter of style, and I'm not familiar with the Sugar coding style. So with curiosity I ask... why? My PoV is that this is an enhancement to the core function of Browse.xo . A nice-to-have thing. If it fails (and noting that it happens at startup time), it should not stop the user from getting the core functionality of Browse. BTW: Is there a spec you used for the cookie format? I find field descriptions like expires - you name it expiry. Well, there are some post-facto specs on the old 'cookies.txt' format, but since it's moved to sqlite I don't think anyone has spec'd it. Still, if you look at the cookies.txt formats, it is self-explanatory. In terms of where I got the fieldnames from, I did: $ cd .mozilla/firefox/2hrgnz74.default/ $ ls cookies. cookies.sqlite cookies.txt $ sqlite3 cookies.sqlite SQLite version 3.5.9 Enter .help for instructions sqlite .schema moz_cookies CREATE TABLE moz_cookies (id INTEGER PRIMARY KEY, name TEXT, value TEXT, host TEXT, path TEXT,expiry INTEGER, lastAccessed INTEGER, isSecure INTEGER, isHttpOnly INTEGER); and I copy/pasted that. That's how the semicolon sneaked in :-/ thanks! m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] webactivity: seed the XS cookie at startup
Martin Langhoff wrote: On Mon, Feb 16, 2009 at 9:36 PM, Simon Schampijer si...@schampijer.de wrote: Our registration URL is REGISTER_URL = 'http://schoolserver:8080/', wouldn't the right Domain than be 'schoolserver'? Since the cookie is about the registration with the schoolserver this makes most sense to me (the jabber server could be somewhere else). Call me silly, but I really want to set it to the fqdn to avoid exposing the cookie too much. Browse.xo homepage links to http://schoolserver/ and that will match any wildcard dns entry, needlessly pushing out info that is better kept quiet. Well, your cal - using the schoolserver url then? The XS will redirect to its own fqdn -- and there Browse.xo will send the cookie. Well, all the calls in the try block are sqlite3 ones - if they fail - we catch it. If something else goes wrong - we want to fail and not hide ;p This is of course a matter of style, and I'm not familiar with the Sugar coding style. So with curiosity I ask... why? My PoV is that this is an enhancement to the core function of Browse.xo . A nice-to-have thing. If it fails (and noting that it happens at startup time), it should not stop the user from getting the core functionality of Browse. Well, it gets the core functionality. If a method can only throw exceptions A I do not need to except for all exceptions. Not clearly defining which errors one is looking for does more hide errors. My POV :) BTW: Is there a spec you used for the cookie format? I find field descriptions like expires - you name it expiry. Well, there are some post-facto specs on the old 'cookies.txt' format, but since it's moved to sqlite I don't think anyone has spec'd it. Still, if you look at the cookies.txt formats, it is self-explanatory. In terms of where I got the fieldnames from, I did: $ cd .mozilla/firefox/2hrgnz74.default/ $ ls cookies. cookies.sqlite cookies.txt $ sqlite3 cookies.sqlite SQLite version 3.5.9 Enter .help for instructions sqlite .schema moz_cookies CREATE TABLE moz_cookies (id INTEGER PRIMARY KEY, name TEXT, value TEXT, host TEXT, path TEXT,expiry INTEGER, lastAccessed INTEGER, isSecure INTEGER, isHttpOnly INTEGER); and I copy/pasted that. That's how the semicolon sneaked in :-/ thanks! m Thanks will have a look, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] webactivity: seed the XS cookie at startup
On Tue, Feb 17, 2009 at 11:03 AM, Simon Schampijer si...@schampijer.de wrote: Well, your call - using the schoolserver url then? The fqdn from backup server or jabber server. Either will do until we fix the registration stuff. Well, it gets the core functionality. If a method can only throw exceptions A I do not need to except for all exceptions. Not clearly defining which errors one is looking for does more hide errors. My POV :) Makes sense. I take it you're happy to fix things up so taht the 2 branches are reasonably in sync? Thanks! m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] webactivity: seed the XS cookie at startup
On Sat, Feb 14, 2009 at 9:11 AM, Simon Schampijer si...@schampijer.de wrote:
Please find attached the patch against master.
Looks good to me (but I know nothing of what's changed in master...)
- i use the backup_url to see if we are associated with a schoolserver
- why did you use the jabber server for this 'xs_fqdn = prof.jabber_server'?
Good question. Neither is the right one. In a XS driven net, both are
equal. In a XS-on-the-internet situation, the public XS may decide
to not offer backup service. Of the 3 (moodle/webapps, xmpp, backup),
backup is the most burdensome on the server.
So I think there is a (very marginal) advantage to using the jabber
server. But the most important hting is that 0.82.x and master use the
same, so whatever you do, both should use the same...
(The right fix is to have a 'schoolserver fqdn' entry in the
profile... but that's for the next Sugar dev cycle I guess...)
- c.execute('''CREATE TABLE IF NOT EXISTS
+ moz_cookies
+ (id INTEGER PRIMARY KEY,
+ name TEXT,
+ value TEXT,
+ host TEXT,
+ path TEXT,
+ expiry INTEGER,
+ lastAccessed INTEGER,
+ isSecure INTEGER,
+ isHttpOnly INTEGER);''')
- is the ';' correct here or a typo?
typo
- i only except for sqlite3.Error
Is that the only thing that could go wrong? My thinking has been: if
we fail, let the startup succeed. This is a good feature, but not a
showstopper.
- what bothers me a bit is that you don't get an error when the database
does not exist - sqlite creates a new one actually - so we might return as
well on 'if not os.path.exists(os.path.join(_profile_path,
'cookies.sqlite'))'
The DB does not exist on the first use of Browse. Actually, it does
not get created until the first website sets the first cookie, AFAICS.
That means that on the first use of Browse the user goes to the XS and
doesn't get autenticated. So if the DB doesn't exist, _we want to
create it_. It's not a failure, it's success.
- the method could even be a function as it does not interact at all with
the class itself, not sure what is nicer
I'd prefer a function, but it's not my codebase, so follow the style... :-)
m
--
martin.langh...@gmail.com
mar...@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] webactivity: seed the XS cookie at startup
Martin Langhoff wrote: On Thu, Feb 12, 2009 at 11:54 PM, Simon Schampijer si...@schampijer.de wrote: Plan A - HTTPS to the rescue Just to understand better. Is the main issue that we have to change the protocol - or are you more worried about the CPU cost? Both. And also HTTPS network load, as HTTPS is a lot less cache-friendly. So as I understand the process: At registration time with the XS the cert is created and transferred to the client. Probably stored than in the profile. Browse does than integrate it when it starts. The cert integration itself in Browse should not be hard. You are right, it shouldn't be hard if you seed it in the same way my patch is seeding the cookies. Carol pointed out another alternative a couple of emails ago. Seems to sidestep the registration rework, but may be complex to implement. But I'm more than happy with my simple Plan C :-) - which is about as safe as gmail over http as most people use everyday! As save as having your email indexed by the provider... :) When thinking about it a bit more - the big plus with your approach that it's only affects Browse - code wise, which is when back porting to 0.82 a big plus, actually maybe the only way. Cheers, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] webactivity: seed the XS cookie at startup
On Fri, Feb 13, 2009 at 12:19 AM, Simon Schampijer si...@schampijer.de wrote: When thinking about it a bit more - the big plus with your approach that it's only affects Browse - code wise, which is when back porting to 0.82 a big plus, actually maybe the only way. Bingo! I think you're starting to read my mind... m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] webactivity: seed the XS cookie at startup
Martin, I want to understand what https traffic you are concerned will affect performance and caching. As far as I understand the need for https, it would only be used infrequently, when reauthenticating to the server. I.e..: 1. XO connects to Moodle without valid cookie and is redirected to https login. 2. https client cert is exchanged, and cookie of limited duration is planted). 3. XO connects to Moodle, cookie is valid, no redirection needed. There might be particular use cases where the data in transit needed to be protected against snooping, but a use case analysis needs to be done to identify these. I can't imagine that it would be needed in day-to-day classroom use by students. On Thu, Feb 12, 2009 at 6:55 AM, da...@lang.hm wrote: On Fri, 13 Feb 2009, Martin Langhoff wrote: On Thu, Feb 12, 2009 at 11:54 PM, Simon Schampijer si...@schampijer.de wrote: Plan A - HTTPS to the rescue Just to understand better. Is the main issue that we have to change the protocol - or are you more worried about the CPU cost? Both. And also HTTPS network load, as HTTPS is a lot less cache-friendly. note that if the XS is acting as a proxy the cache issue can be addressed. The XS can get a copy of the XO client cert at registration time, and with it can decrypt the HTTPS traffic and cache the unencrypted version. this is a lot of cpu, but it's on the XS not the XO, so it shouldn't be as bad (and there are hardware SSL encryption cards available that can be put in an XS for high-volume situations) it's not just a matter of downloading a package and installing it, but it's not rocket science either. this would have the side effect of making the XS security even more critical, but I think that it's already critical enough that this won't really make much difference in how it's secured. David Lang ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] webactivity: seed the XS cookie at startup
On Thu, Feb 12, 2009 at 6:47 PM, martin.langh...@gmail.com wrote: When starting up, call seed_xs_cookie() to Hi Simon, Hoping for some review :-) . Do you think this patch can make it into the sucrose-0.82 branch? With a tad of elbow grease, it also applies on top of master. The reason I ask for it on the 0.82 branch is that - It's low low risk -- in fact, the interesting ops are wrapped in a try/except block so a failure won't stop Browse from starting up. - It allows me to do a XS 0.5.2 or 0.6 relatively soon that integrates smoothly with the XO 0.8.2.x series. Deployments can ensure that they have an updated Browse.xo... cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
