[Sugar-devel] [sugar-devel]engineering the moodle-print communication
Vamsi Krishna Davuluri
vamsi.davuluri at gmail.com
Mon Jun 8 14:55:55 EDT 2009
Andres and I were talking about engineering the moodle-print
We found out that webactivity.py already has implementation to
users, as it sends a cookie. We were wondering if reusing that code is any
good, and if we can also send moodle username along with it, and have
the pdfs stored under that particular moodle user.
This would be through a HTTP POST
would I have the user provide his details, and send them to xml-rpc to
authenticate him and then upload pdf into his space.
is there a better implementation for this.
I need to somehow send a pdf, and I will need it to be registered under
any user, or the XO user's by default.
[23:48] <daveb> martin wrote the origin*al webactivity code
[23:48] <daveb> that sets the cookie
[23:48] <daveb> that patch is on the ML
[23:49] <iwikiwi> oh okay
[23:49] <aa> yeah, I remember that one
[23:49] <daveb> the other patch is to register.py to allow registering non
XO to a schoolserver/moodle
[23:53] <aa> ok, it uses the sugar profile's public key
[23:54] <daveb> right
[23:54] <daveb> ah ok
[23:54] <daveb> so you have access to that
[23:54] <aa> iwikiwi: which you can get by using
[23:54] <daveb> if you can get to the filesystem
[23:54] <daveb> or that!
[23:54] <aa> daveb: sugar has an API for that :)
[23:54] <daveb> ok so the random number is for the registration itself
[23:54] <daveb> which is totally outside your area.
[23:55] <daveb> since you need to be already registered to et into moodle
[23:55] <iwikiwi> aa: yay, but how does that identify me as a particular
[23:55] <aa> probably, I dont see any random numbers in webactivity.py
[23:55] <daveb> its in schoolserver.py where the registration occurs
[23:55] <daveb> so basically if you aren't registered print doesn't care
about moodle anyway
[23:55] <daveb> right?
[23:56] <aa> iwikiwi: you should put that cookie in the HTTP header
[23:56] <aa> daveb: if you aren't registered we will probably have to let
the user know
[23:57] <aa> but that's something to be discussed with the design team
[23:57] <iwikiwi> aa: even if i do, i dont see how moodle can authenticate
me without my password. 1) I could be the admin himself 2) i could be vamsi
3) I could be iwikiwi :P
[23:57] --> bemasc has joined this channel (n=
bens at c-76-118-183-78.hsd1.ma.comcast.net).
[23:57] --> Flipo has joined this channel (n=
Nat at bas4-montreal28-1279343241.dsl.bell.ca).
[23:57] --> NeoAmsterdam has joined this channel (n=
NeoAmste at 66-234-59-27.nyc.cable.nyct.net).
[23:57] <aa> iwikiwi: it doesnt, this doesnt provide any security at all,
nor does it intend to
[23:57] --> Mokurai has joined this channel (n=
mokurai at 75-25-130-215.lightspeed.sjcpca.sbcglobal.net).
[23:58] <iwikiwi> hmm, why do we do this then?
[23:58] <aa> the schoolserver guys wanted a way to let kids use moodle
[23:58] <iwikiwi> ah!
[23:58] <-- dirakx has left this server ("Leaving.").
[23:59] <iwikiwi> actually i think this will be trickier for me to put phds
under a specific user :P
[23:59] <iwikiwi> pdfs*
[23:59] <aa> and didnt have the time to code a pub key based auth mechanism
[00:00] <aa> iwikiwi: I'm not sure what moodle does internally with this
cookie to authenticate the user, but it should be no more than copying and
pasting that code
[00:01] <aa> iwikiwi: to get the cookie, just do exactly what browse
activity does (see webactivity.py) except for the sqlite stuff
[00:02] <iwikiwi> aa: im more worried on how to parse the pdf under a
specific user. like: leona made a pdf and wants to show her teacher under
her moodle username leona, which the teacher will approve/disapprove. But
when i do this the webactivity way, I dont see how i can upload under a
[00:02] <aa> iwikiwi: I'm thinking a simple form POST with this cookie set
is much easier than all this xmlrpc stuff
[00:03] <iwikiwi> yeah, agreed
[00:03] <iwikiwi> but how to evaluate the sent pdf is what im wondering
[00:04] <aa> just add that info in the POST
[00:04] <iwikiwi> user name and password?
[00:04] <aa> the cookie only contains the pubkey, so I'm guessing martin is
using a hash of that as a username
[00:05] <aa> but you can just put sugar's username in your request and store
that in your module's db
[00:05] <iwikiwi> yeah, but will that upload the pdf under 'leona'? and will
it be something leona can check after she logs into moodle using the login
leona and pswd?
[00:05] <aa> no need for the username you display and moodle's internal
username to be the same
[00:05] <-- bertf has left this server ("Entering Real World").
[00:06] <aa> iwikiwi: kids using this mechanism dont even know their
[00:06] <aa> so you store both things, moodle's username, and sugar's
[00:06] <aa> when kids log in via web, you query your storage using moodle's
[00:07] <aa> but you show them their sugar username
[00:07] <aa> not h327134kjv6w155
[00:07] <aa> or whatever moodle is storing
[00:07] <iwikiwi> aa: hmm, i will see if moodle lets me upload files for
some user through some user
[00:08] <iwikiwi> some other*
[00:08] <iwikiwi> aa: what will this webactivity user previlidges be?
[00:08] <iwikiwi> priviledges*
[00:08] <aa> webactivity?
[00:09] <iwikiwi> sorry meant to ask what will this cookie's authenticated
codes priviledges be
[00:09] <iwikiwi> cookie*
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Sugar-devel