Hi, Andres and I were talking about engineering the moodle-print communication. We found out that webactivity.py already has implementation to authenticate 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 (or) would I have the user provide his details, and send them to xml-rpc to authenticate him and then upload pdf into his space. (or) is there a better implementation for this. this being: 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 original 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 profile.get_profile().pubkey [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 anyway [23:55] <iwikiwi> aa: yay, but how does that identify me as a particular moodle user? [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=<a href="mailto:bens@c-76-118-183-78.hsd1.ma.comcast.net">bens@c-76-118-183-78.hsd1.ma.comcast.net</a>). [23:57] --> Flipo has joined this channel (n=<a href="mailto:Nat@bas4-montreal28-1279343241.dsl.bell.ca">Nat@bas4-montreal28-1279343241.dsl.bell.ca</a>). [23:57] --> NeoAmsterdam has joined this channel (n=<a href="mailto:NeoAmste@66-234-59-27.nyc.cable.nyct.net">NeoAmste@66-234-59-27.nyc.cable.nyct.net</a>). [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=<a href="mailto:mokurai@75-25-130-215.lightspeed.sjcpca.sbcglobal.net">mokurai@75-25-130-215.lightspeed.sjcpca.sbcglobal.net</a>). [23:58] <iwikiwi> hmm, why do we do this then? [23:58] <aa> the schoolserver guys wanted a way to let kids use moodle without passwords [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 specific user [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 password [00:06] <aa> so you store both things, moodle's username, and sugar's username [00:06] <aa> when kids log in via web, you query your storage using moodle's username [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* Thanks, Vamsi