1 # Conversation held after creating the Week 12 progress report in google docs
3 Jeremy Tan joined group chat.
6 Heh, I didn't expect everyone to start editing it so fast
10 what is this madness, working on it the day before
14 Jeremy: You weren't in IRC, but I hacked together a MySQL authentication thing to work with UserCake.
20 It seems to work well...
21 Although currently any random can register for an account.
24 Sorry, I was really busy sorting out the case study and my databases project (both due today)
28 Ironic... I spent all of today learning about a database :P
31 I was considering using php to redirect the user if they weren't logged it
33 but since you got this working, great
35 Never heard of usercake though
39 It does need some modification
40 For some reason it stores privelage levels in a seperate table to the main users which is a pain for checking if someone is admin or not
43 how do you interact with the db? does mysql have a C api?
46 And of course it has single user registration, so I'm currently trying to make a mass registration form that only the admin can use
47 Yes, MySQL has a C API
50 that must be a pain to work with
57 I was trying something similar with sqlite and the django db
60 At least just for the simple task of looking up a user
64 I got the django one as far as getting the user entry
65 but then the data is base64 encoded
66 and uses sha256 hashing
71 PHP has the same crypt() function as posix which made it easier
74 yeah, except crypt is really insecure
75 but I guess they dont care
79 Someone would have to get access to the database to even look at the hashes first
80 But MySQL doesn't have a great reputation either
83 well that's where the problem lies anyway
84 it's all about if the user gets access to the db, then you're in a really bad position if you've used crypt
85 mysql has better performance than sqlite though (probably)
86 About the control page - we haven't differentiated between a 'strain' and an 'explode' experiment. What controls are also necessary anyway? e.g do we even want the user to be able to control the pressure for the explode version?
89 The easiest way to do it is to just have "strain/explode" switch the relay and otherwise use the same controls, I'm not sure if that's OK or not though
93 How does that UMS affect the current api
101 So is login handled by that cake or the api (or both)?
104 It's entirely seperate, except you can pass a mysql authentication method to the server
105 UserCake handles it's own login
106 Our API still has seperate login
107 It just accesses the same database
111 very similar to the django idea then
115 Yes, I think that's the best way to do it anyway
116 And yes, UserCake is PHP
120 Django's annoying to set up, and then you have to worry about python too
125 Hmm, what's a good justification for it
129 we probably have to change cookie handling in the api
130 usercake probably stores its own cookies
136 and that will definitely screw up things
142 but I was planning on doing something about taht anyway
145 Iceweasel seems to always send the nameless cookie first...
148 oh yeah, that's right
151 So I just truncated the cookie at the first ';'
154 yesterday I limited it
156 it snprintfs exactly the size of the control cookie
157 so if the cookie's first, then it's all good
161 But when you logout I think it sets the cookie to "0"
165 shouldn't be an issue since it won't match
166 but I was thinking of switching to a named cookie
167 PHP can't handle the nameless cookie though (something I found out today)
170 It shouldn't but it feels wrong...
171 Switching to a named cookie is probably a good idea
178 usercake's not on git, is it?
181 Not yet, it's on my local machine in a new branch
182 Should I push it now?
186 that would be good if you could
189 You know you've spent too long writing javascript when you default to writing !==
195 I think I'll call it quits for now
201 I'll try upload this chat log since we didn't use IRC