Scratch
archived forums
#176 2012-06-30 13:13:46
#177 2012-06-30 13:58:03
- stevetheipad
- Scratcher
- Registered: 2011-08-06
- Posts: 1000+
Re: Scratch API 2.0
fg123 wrote:
We're are going to try to end up with a api2.scratchr.org domain, or something similar.
So thanks,, but no thanks.
Ah, cool.
gone
Offline
#178 2012-06-30 13:58:12
Re: Scratch API 2.0
Nice entrepreneurel jump-in there, SteveTheIpad, but this'll be either going on blocks.scratchr.org or hopefully api.scratchr.org
BTW, SteveTheIpad is a long name. Is it okay for me to shorten it to Steve or STI? Actually... maybe not STI... 
Offline
#179 2012-06-30 14:31:36
Re: Scratch API 2.0
sparks wrote:
Nice entrepreneurel jump-in there, SteveTheIpad, but this'll be either going on blocks.scratchr.org or hopefully api.scratchr.org
BTW, SteveTheIpad is a long name. Is it okay for me to shorten it to Steve or STI? Actually... maybe not STI...
Definitely not STI. 
STIP, maybe?
Hai.
Offline
#180 2012-06-30 14:33:23
- stevetheipad
- Scratcher
- Registered: 2011-08-06
- Posts: 1000+
Re: Scratch API 2.0
sparks wrote:
Nice entrepreneurel jump-in there, SteveTheIpad, but this'll be either going on blocks.scratchr.org or hopefully api.scratchr.org
BTW, SteveTheIpad is a long name. Is it okay for me to shorten it to Steve or STI? Actually... maybe not STI...
Yeah, my company needs to get "out there", but I can understand using the scratchr domain.
Long but easy to remember. And I always flinch when you capitalize three letters in my name, so just call me Steve.
Are you guys in need of any help with anything specific? It sounds like a cool project to help with.
Edit: 7000th post in the collaborations forum. 
Last edited by stevetheipad (2012-06-30 14:35:18)
gone
Offline
#181 2012-07-03 11:58:52
Re: Scratch API 2.0
Back and you guys haven't worked on it for 3 days
I should be back to my home commodities Saturday afternoon and will make a start on the GUI. I feel like I'm pushing, but it would really be a good idea to start the user system, fg...
Offline
#182 2012-07-03 12:30:57
Re: Scratch API 2.0
LS97 wrote:
Back and you guys haven't worked on it for 3 days
I should be back to my home commodities Saturday afternoon and will make a start on the GUI. I feel like I'm pushing, but it would really be a good idea to start the user system, fg...
Yes! Of course, sorry, my bad.
I've been preparing for my theory exam and have been really busy. I'll chunk out some time to work on it.
So they have a choice of making an account on our servers or logging in with the scratch one? Okay.
Last edited by fg123 (2012-07-03 12:31:23)
Hai.
Offline
#183 2012-07-03 12:41:24
Re: Scratch API 2.0
I have a better idea for Scratch Auth:
1) Queries the database, tries to login with an API account
2) Queries Scratch, tries to login as a scratch user
3) If Scratch users is successful, add user to DB.
I support the Free Software Foundation. Protect our digital rights!
Offline
#184 2012-07-03 14:22:47
Re: Scratch API 2.0
fg123 wrote:
LS97 wrote:
Back and you guys haven't worked on it for 3 days
I should be back to my home commodities Saturday afternoon and will make a start on the GUI. I feel like I'm pushing, but it would really be a good idea to start the user system, fg...Yes! Of course, sorry, my bad.
I've been preparing for my theory exam and have been really busy. I'll chunk out some time to work on it.
So they have a choice of making an account on our servers or logging in with the scratch one? Okay.
Oh, sorry, by all means exams should come first!
Here's how the system should optimally work, in my opinion:
On registration, the user will have the choice of their alias to use on the API site to create and store images. They can choose any name they like, but if the name they choose also exists on Scratch, the password must match that of the Scratch servers.
After registration they may change their password, and passwords must be hashed and only stored in one place.
Offline
#185 2012-07-03 15:50:49
Re: Scratch API 2.0
LS97 wrote:
fg123 wrote:
LS97 wrote:
Back and you guys haven't worked on it for 3 days
I should be back to my home commodities Saturday afternoon and will make a start on the GUI. I feel like I'm pushing, but it would really be a good idea to start the user system, fg...Yes! Of course, sorry, my bad.
I've been preparing for my theory exam and have been really busy. I'll chunk out some time to work on it.
So they have a choice of making an account on our servers or logging in with the scratch one? Okay.Oh, sorry, by all means exams should come first!
Here's how the system should optimally work, in my opinion:
On registration, the user will have the choice of their alias to use on the API site to create and store images. They can choose any name they like, but if the name they choose also exists on Scratch, the password must match that of the Scratch servers.
After registration they may change their password, and passwords must be hashed and only stored in one place.
I trust MD5 is secure enough?
Perhaps SHA-1?
Hai.
Offline
#186 2012-07-04 06:28:48
Re: Scratch API 2.0
fg123 wrote:
LS97 wrote:
fg123 wrote:
Yes! Of course, sorry, my bad.
I've been preparing for my theory exam and have been really busy. I'll chunk out some time to work on it.
So they have a choice of making an account on our servers or logging in with the scratch one? Okay.Oh, sorry, by all means exams should come first!
Here's how the system should optimally work, in my opinion:
On registration, the user will have the choice of their alias to use on the API site to create and store images. They can choose any name they like, but if the name they choose also exists on Scratch, the password must match that of the Scratch servers.
After registration they may change their password, and passwords must be hashed and only stored in one place.I trust MD5 is secure enough?
Perhaps SHA-1?
MD5 with secret passphrase is more than enough
I already explained this upthread I think, but in a nutshell
md5($password . 'secretcodethatonlyweknow')
Offline
#187 2012-07-04 20:11:58
Re: Scratch API 2.0
LS97 wrote:
fg123 wrote:
LS97 wrote:
Oh, sorry, by all means exams should come first!
Here's how the system should optimally work, in my opinion:
On registration, the user will have the choice of their alias to use on the API site to create and store images. They can choose any name they like, but if the name they choose also exists on Scratch, the password must match that of the Scratch servers.
After registration they may change their password, and passwords must be hashed and only stored in one place.I trust MD5 is secure enough?
Perhaps SHA-1?MD5 with secret passphrase is more than enough
I already explained this upthread I think, but in a nutshell
md5($password . 'secretcodethatonlyweknow')
I'm updating, no one touch things. Although I'm mostly adding new files.
Hai.
Offline
#188 2012-07-04 20:31:47
#189 2012-07-05 03:53:48
Re: Scratch API 2.0
fg123 wrote:
Do you have code to retrieve the user profile icon of the scratch user?
Kind of. You know when you check for the password using the (real) API?
If it is successful, it returns a string with various parameters. One of those is the user's numerical ID, which can be used to retrieve their icon at
http://scratch.mit.edu/static/icons/buddy/######_med.png
We could just store that number on signup!
Offline
#190 2012-07-05 04:47:20
Re: Scratch API 2.0
Hi guys, so sorry I've done nothing lately, I can't believe how busy work has been lately. Good to see other people are doing updates though!
What's with all the syntax errors on the create page?
EDIT: ah, I see you've prepared for database connection to the site we move to.
I'm loving error message2 in login.php: "You must login to place an order!" Was that code recycled by chance?
EDIT2: I managed to fix the SQL error that db.php was causing by simply adding a "www." to the start of the host name.
Whoever managed to get the textboxes to look better, I love you forever! They were giving me a lot of grief.
Last edited by sparks (2012-07-05 05:07:49)
Offline
#191 2012-07-05 12:43:11
Re: Scratch API 2.0
sparks wrote:
Hi guys, so sorry I've done nothing lately, I can't believe how busy work has been lately. Good to see other people are doing updates though!
What's with all the syntax errors on the create page?
EDIT: ah, I see you've prepared for database connection to the site we move to.
I'm loving error message2 in login.php: "You must login to place an order!" Was that code recycled by chance?
EDIT2: I managed to fix the SQL error that db.php was causing by simply adding a "www." to the start of the host name.
Whoever managed to get the textboxes to look better, I love you forever! They were giving me a lot of grief.
I will fix the syntax errors now. The function I was using to detect server names detects it without the first subdomain. So it's detecting comeze.com, but when you add www, it detects api2.comeze.com, which is the right one.
Yes, that code is recycled from another project I'm working on. (techwiq)
And the textboxes are still default, so I don't know what you're talking about.
(You joined the forums 8 days before me. )
Now, new stuff:
If the user chooses to create their own account, it can't be the same username of anything in scratch, right? Otherwise, it will collide? Then it really limits it. What if they create an account called: "CanadaRulez"
Then a scratch user makes the same account on the scratch site, and tries to get into the API2 site, but can't because the password is wrong.
I'm thinking they can only login with scratch accounts, then on the signup page, they can click a link to the scratch signup, and do it there. No conflicts.
EDITEDIT: Oh, i see you added WWW in the file, not the address. Cool.
Last edited by fg123 (2012-07-05 13:34:07)
Hai.
Offline
#192 2012-07-05 13:03:38
Re: Scratch API 2.0
What if someone doesn't want to share their password with us?
You can give all the encryption and privacy policies you like, but some people could still distrust giving out the same password to another site.
I think and repeat that this is the best option:
The user MUST actually sign up on our site and create a user to be able to make stuff. There's only one form, no choice between "scratch account" or "api account" yet.
Once the user has submitted the signup form the PHP automatically does some checks:
- if the username exists on the site, it rejects the signup
- it then checks the password: if the username given is also a scratch one, the password must match the records. if it doesn't, rejected.
- at the same time we save the user ID on scratch if appropriate, for the user image.
Offline
#193 2012-07-05 13:35:53
Re: Scratch API 2.0
LS97 wrote:
What if someone doesn't want to share their password with us?
You can give all the encryption and privacy policies you like, but some people could still distrust giving out the same password to another site.
I think and repeat that this is the best option:
The user MUST actually sign up on our site and create a user to be able to make stuff. There's only one form, no choice between "scratch account" or "api account" yet.
Once the user has submitted the signup form the PHP automatically does some checks:
- if the username exists on the site, it rejects the signup
- it then checks the password: if the username given is also a scratch one, the password must match the records. if it doesn't, rejected.
- at the same time we save the user ID on scratch if appropriate, for the user image.
But then we run into the problem I was talking about. What if an API2 user uses a "free" username, then a random user signs up for the same name on scratch. Then we have a name in the Scratch DB and a name in the API2 DB that are matching, but with different users. IF the scratch user attempts to use API2, they won't be able to.
Hai.
Offline
#194 2012-07-05 13:41:05
Re: Scratch API 2.0
That is true, fg, but there is nothing we can do about it if we also want to preserve the policy that users are not obliged to share their password with us!
Offline
#195 2012-07-05 17:03:38
Re: Scratch API 2.0
'Tis a conundrum... I'm with LS97 though, that we should allow users to register with their Scratch account (to increase the ease of dealing with any troublemakers) or create a new account (to avoid frightening away people who are very password-on-other-sites conscious.
Offline
#196 2012-07-05 17:04:17
#197 2012-07-05 17:35:50
Re: Scratch API 2.0
sparks wrote:
The site has a new syntax error... Mistake in db.php...
Fixed.
What info shall we store in the User DB?
And how do I retrieve the details passed from the
if(trim(file_get_contents("http://scratch.mit.edu/api/authenticateuser?username=" . $_POST['username'] . "&password=" . $_POST['password']) ) == 'false')
code?
And what details are included?
Last edited by fg123 (2012-07-05 18:55:27)
Hai.
Offline
#198 2012-07-06 03:56:30
Re: Scratch API 2.0
You see, in the code above, instead of directly checking in an IF statement whether the string equals "false", we can store the file_get_c in a variable. Then we parse it and store what we need in the user's database entry, or if we find it says false then we reject the user.
As for the details that are included, here is a sample.
279261:LS97:unblocked
We're really only interested in the first string of numbers preceding the colon as it is the user ID required for the user image.
For the details to store, here's what I can think of:
- username
- hashed password
- IP (maybe even of each login/day/week...)
- date registered on our site
- ID on scratch (if not applicable, use 0 or some other recognisable number)
- privileges (we don't want to hard code moderation abilities to usernames as the admins may change over time/site)
I think that info could fit well in a table of its own. Then we should have, IMO, two other tables.
The first with a list of images and their basic properties:
- name of image given by user
- unique image ID
- chosen URL if we allow this
- creator's username
- size
- other properties that pertain to the canvas
The second with a list of elements that fit into the images
- unique ID of image they're in
- various properties
Offline
#199 2012-07-06 12:53:34
#200 2012-07-06 15:00:58
Re: Scratch API 2.0
fg123 wrote:
Sounds good, I'll setup the DB. So no email/gender/location or any of that. I was thinking it's actually possible to retrieve the location from the user page.
You raise a good point about maybe an optional email field.
But I don't think gender location is too necessary for our purpose, right?
Offline