Hi, <br><br> Andres and I were talking about engineering the moodle-print communication.<br> We found out that webactivity.py already has implementation to authenticate <br> users, as it sends a cookie. We were wondering if reusing that code is any <br>
good, and if we can also send moodle username along with it, and have <br> the pdfs stored under that particular moodle user.<br> This would be through a HTTP POST <br> (or)<br> would I have the user provide his details, and send them to xml-rpc to <br>
authenticate him and then upload pdf into his space.<br> (or)<br> is there a better implementation for this.<br> this being:<br> I need to somehow send a pdf, and I will need it to be registered under<br> any user, or the XO user's by default.<br>
<br>[23:48] <daveb> martin wrote the origin<i>al webactivity code<br>[23:48] <daveb> that sets the cookie<br>[23:48] <daveb> that patch is on the ML<br>[23:49] <iwikiwi> oh okay<br>[23:49] <aa> yeah, I remember that one<br>
[23:49] <daveb> the other patch is to register.py to allow registering non XO to a schoolserver/moodle<br>[23:53] <aa> ok, it uses the sugar profile's public key<br>[23:54] <daveb> right<br>[23:54] <daveb> ah ok<br>
[23:54] <daveb> so you have access to that<br>[23:54] <aa> iwikiwi: which you can get by using profile.get_profile().pubkey<br>[23:54] <daveb> if you can get to the filesystem<br>[23:54] <daveb> or that!<br>
[23:54] <aa> daveb: sugar has an API for that :)<br>[23:54] <daveb> ok so the random number is for the registration itself<br>[23:54] <daveb> which is totally outside your area.<br>[23:55] <daveb> since you need to be already registered to et into moodle anyway<br>
[23:55] <iwikiwi> aa: yay, but how does that identify me as a particular moodle user?<br>[23:55] <aa> probably, I dont see any random numbers in webactivity.py<br>[23:55] <daveb> its in schoolserver.py where the registration occurs<br>
[23:55] <daveb> so basically if you aren't registered print doesn't care about moodle anyway<br>[23:55] <daveb> right?<br>[23:56] <aa> iwikiwi: you should put that cookie in the HTTP header<br>[23:56] <aa> daveb: if you aren't registered we will probably have to let the user know<br>
[23:57] <aa> but that's something to be discussed with the design team<br>[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<br>
[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>).<br>[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>).<br>
[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>).<br>[23:57] <aa> iwikiwi: it doesnt, this doesnt provide any security at all, nor does it intend to<br>
[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>).<br>[23:58] <iwikiwi> hmm, why do we do this then?<br>
[23:58] <aa> the schoolserver guys wanted a way to let kids use moodle without passwords<br>[23:58] <iwikiwi> ah!<br>[23:58] <-- dirakx has left this server ("Leaving.").<br>[23:59] <iwikiwi> actually i think this will be trickier for me to put phds under a specific user :P<br>
[23:59] <iwikiwi> pdfs*<br>[23:59] <aa> and didnt have the time to code a pub key based auth mechanism<br>[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<br>
[00:01] <aa> iwikiwi: to get the cookie, just do exactly what browse activity does (see webactivity.py) except for the sqlite stuff<br>[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<br>
[00:02] <aa> iwikiwi: I'm thinking a simple form POST with this cookie set is much easier than all this xmlrpc stuff<br>[00:03] <iwikiwi> yeah, agreed<br>[00:03] <iwikiwi> but how to evaluate the sent pdf is what im wondering<br>
[00:04] <aa> just add that info in the POST<br>[00:04] <iwikiwi> user name and password?<br>[00:04] <aa> the cookie only contains the pubkey, so I'm guessing martin is using a hash of that as a username<br>
[00:05] <aa> but you can just put sugar's username in your request and store that in your module's db<br>[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?<br>
[00:05] <aa> no need for the username you display and moodle's internal username to be the same<br>[00:05] <-- bertf has left this server ("Entering Real World").<br>[00:06] <aa> iwikiwi: kids using this mechanism dont even know their password<br>
[00:06] <aa> so you store both things, moodle's username, and sugar's username<br>[00:06] <aa> when kids log in via web, you query your storage using moodle's username<br>[00:07] <aa> but you show them their sugar username<br>
[00:07] <aa> not h327134kjv6w155<br>[00:07] <aa> or whatever moodle is storing<br>[00:07] <iwikiwi> aa: hmm, i will see if moodle lets me upload files for some user through some user<br>[00:08] <iwikiwi> some other*<br>
[00:08] <iwikiwi> aa: what will this webactivity user previlidges be?<br>[00:08] <iwikiwi> priviledges*<br>[00:08] <aa> webactivity?<br>[00:09] <iwikiwi> sorry meant to ask what will this cookie's authenticated codes priviledges be<br>
[00:09] <iwikiwi> cookie*<br></i><br>Thanks,<br>Vamsi<br>