comp500 wrote:

I see. There could be ways to transfer OAuth to a primitive login API, and I strongly agree that we should (Go Everywhere FTW) but we should still use OAuth for enhanced security and other conveniences that OAuth provides.

Rub0Gameton wrote:

comp500 wrote:

I see. There could be ways to transfer OAuth to a primitive login API, and I strongly agree that we should (Go Everywhere FTW) but we should still use OAuth for enhanced security and other conveniences that OAuth provides.

I agree. Security should be the most important concern, especially when in websites like this targeted to those under 13 (protected by COPPA). It would make everything easier as you wouldn't really have to store any personal information on your own website. The old API required you to put your actual Scratch password in the website and trust that it won't do anything other than check it with Scratch.

jvvg wrote:

Rub0Gameton wrote:

comp500 wrote:

I see. There could be ways to transfer OAuth to a primitive login API, and I strongly agree that we should (Go Everywhere FTW) but we should still use OAuth for enhanced security and other conveniences that OAuth provides.

I agree. Security should be the most important concern, especially when in websites like this targeted to those under 13 (protected by COPPA). It would make everything easier as you wouldn't really have to store any personal information on your own website. The old API required you to put your actual Scratch password in the website and trust that it won't do anything other than check it with Scratch.

We published the complete source code for our website, and a simple look at the register script showed that it doesn't store your password after checking it.

Also, I should point out from a further look, it looks like OAuth is a PHP module that has to be installed. Our web host does not let us install any PHP modules, and OAuth is not included by default on FatCow.

Rub0Gameton wrote:

jvvg wrote:

Rub0Gameton wrote:

comp500 wrote:

I see. There could be ways to transfer OAuth to a primitive login API, and I strongly agree that we should (Go Everywhere FTW) but we should still use OAuth for enhanced security and other conveniences that OAuth provides.

I agree. Security should be the most important concern, especially when in websites like this targeted to those under 13 (protected by COPPA). It would make everything easier as you wouldn't really have to store any personal information on your own website. The old API required you to put your actual Scratch password in the website and trust that it won't do anything other than check it with Scratch.

We published the complete source code for our website, and a simple look at the register script showed that it doesn't store your password after checking it.

Also, I should point out from a further look, it looks like OAuth is a PHP module that has to be installed. Our web host does not let us install any PHP modules, and OAuth is not included by default on FatCow.

Ok, that is interesting. I don't really see a reason on why they should disallow modules. You could check out other hosts if they insist of that. My website $0.50/month web server allowed me to do anything I wanted to (even though I later had to upgrade to 100GB of bandwidth/month due to excess of people). I also know of other free, ad-free hosts who let you do almost anything, including modules, for free (although I wouldn't rely on free services). You should talk it out with Fat Cow and see if they can make an exception.

Back on topic: I really doubt someone like you, who have been at least a few years in Scratch, would be around to steal people's password; however, there are certain people that pursue this like if it was their dream. Showing the “source code” doesn't really mean they are telling the truth about them not using anything else. Example: I show my code as “get password, verify with Scratch and log in.” My actual code is “get password, verify with Scratch, save in database, log in.” There is no actual way of verifying you are doing what you say you are doing with PHP, as it is code ran server-side.

I do agree that the transition process from a pre-existing user database is quite tedious. I had to do this myself recently. It does not take as much effort as it may have seemed at first. The only steps required is first to create the required tables separately and then manually insert/replace columns accordingly.

Again, off-topic: Feels good to debate, lol. I like conflict of ideas =P.

jvvg wrote:

Rub0Gameton wrote:

Ok, that is interesting. I don't really see a reason on why they should disallow modules. You could check out other hosts if they insist of that. My website $0.50/month web server allowed me to do anything I wanted to (even though I later had to upgrade to 100GB of bandwidth/month due to excess of people). I also know of other free, ad-free hosts who let you do almost anything, including modules, for free (although I wouldn't rely on free services). You should talk it out with Fat Cow and see if they can make an exception.

Back on topic: I really doubt someone like you, who have been at least a few years in Scratch, would be around to steal people's password; however, there are certain people that pursue this like if it was their dream. Showing the “source code” doesn't really mean they are telling the truth about them not using anything else. Example: I show my code as “get password, verify with Scratch and log in.” My actual code is “get password, verify with Scratch, save in database, log in.” There is no actual way of verifying you are doing what you say you are doing with PHP, as it is code ran server-side.

I do agree that the transition process from a pre-existing user database is quite tedious. I had to do this myself recently. It does not take as much effort as it may have seemed at first. The only steps required is first to create the required tables separately and then manually insert/replace columns accordingly.

Again, off-topic: Feels good to debate, lol. I like conflict of ideas =P.

I've paid for the website to be hosted until October 2014, and I operate hosting on a rather tight budget. I can't afford to switch hosts. This is a pretty simple solution to that problem. I am not the only one with this problem. Most of the hosts used for Scratcher-made websites and forums don't support OAuth. That would mean that there would be essentially no way for them to authenticate against the Scratch website.
What they do right now to prevent that is simply to warn Scratchers before entering their password on external sites to make sure that they are trusted. It's a perfectly fine system.
Tedious? That's a bit of an understatement. Mod Share is a massive coding project, with tons of ins and outs. If you add everything together (including the forums, which also tie into our user system), we have 42549 lines of code. That is massive. Most of that code references our current user system. To fix all of that would take longer than reprogramming the entire site from scratch (no pun intended). My estimate is that with the limited time budget I have, it would take well over a month to reprogram. For that month, the site wouldn't function properly. Nobody could use it. It would also mean that I am spending time that I should be spending on stuff like playing with my friends, sleeping, etc. programming something unnecessary. I am not one of those professional programmers who spends all of their time on this. I am a high school student. I have homework, projects, and sports. I need to spend time with my friends. I need to spend my time doing more useful stuff than recoding 40K lines of code to change something that really shouldn't need to be changed.

Rub0Gameton wrote:

Ok, maybe I did not take into consideration all the syncing system you must have in place related to your user system, more specifically between your forums and main site. I personally took a look at your site (it actually really impressed me) and realized you just ask for a user's Scratch password once to verify their Scratch account (correct me if I am wrong). I found an alternative. Instead of using OAuth for the authentication system as a whole, you could use it just for that small part. You would not need to set up all of the tables that are required or the modules. The OAuth PHP library lets you make a simple script to log in without the use of a database. You can look for it in Google Code. This way, it would not mess with your user system at all.
EDIT: On a side note, I can't find anything related to installing PHP modules for OAuth nor do I remember doing it before. Are we talking about the same thing? (Also removed a few quotes, they took too much space).

jvvg wrote:

This is what told me it's a module
I looked at the one you told me about (it's here, for future reference) and it still looks rather complicated and too difficult for Scratchers who are still learning web programming.

XenoK wrote:

OAuth? honestly, the APIs on the old site didn't seem to be that much of a security concern, they worked just fine in my opinion. What was the point in switching to a more complicated API system? That doesn't really make any sense to me. Scratch is a program designed for simplification in programming, so why aren't the APIs simpler?

XenoK wrote:

OAuth? honestly, the APIs on the old site didn't seem to be that much of a security concern, they worked just fine in my opinion. What was the point in switching to a more complicated API system? That doesn't really make any sense to me. Scratch is a program designed for simplification in programming, so why aren't the APIs simpler?

veggieman001 wrote:

XenoK wrote:

OAuth? honestly, the APIs on the old site didn't seem to be that much of a security concern, they worked just fine in my opinion. What was the point in switching to a more complicated API system? That doesn't really make any sense to me. Scratch is a program designed for simplification in programming, so why aren't the APIs simpler?

Because the current one allows people to steal passwords; it's too much of a security concern. Although they worked, there's no way you could trust everyone.

jvvg wrote:

Rub0Gameton wrote:

Ok, maybe I did not take into consideration all the syncing system you must have in place related to your user system, more specifically between your forums and main site. I personally took a look at your site (it actually really impressed me) and realized you just ask for a user's Scratch password once to verify their Scratch account (correct me if I am wrong). I found an alternative. Instead of using OAuth for the authentication system as a whole, you could use it just for that small part. You would not need to set up all of the tables that are required or the modules. The OAuth PHP library lets you make a simple script to log in without the use of a database. You can look for it in Google Code. This way, it would not mess with your user system at all.
EDIT: On a side note, I can't find anything related to installing PHP modules for OAuth nor do I remember doing it before. Are we talking about the same thing? (Also removed a few quotes, they took too much space).

This is what told me it's a module
I looked at the one you told me about (it's here, for future reference) and it still looks rather complicated and too difficult for Scratchers who are still learning web programming.

/**
 * This class provides a simple interface for OpenID (1.1 and 2.0) authentication.
 * Supports Yadis discovery.
 * The authentication process is stateless/dumb.
 *
 * Usage:
 * Sign-on with OpenID is a two step process:
 * Step one is authentication with the provider:
 * <code>
 * $openid = new LightOpenID('my-host.example.org');
 * $openid->identity = 'ID supplied by user';
 * header('Location: ' . $openid->authUrl());
 * </code>
 * The provider then sends various parameters via GET, one of them is openid_mode.
 * Step two is verification:
 * <code>
 * $openid = new LightOpenID('my-host.example.org');
 * if ($openid->mode) {
 *     echo $openid->validate() ? 'Logged in.' : 'Failed';
 * }
 * </code>
 *
 * Change the 'my-host.example.org' to your domain name. Do NOT use $_SERVER['HTTP_HOST']
 * for that, unless you know what you are doing.
 *
 * Optionally, you can set $returnUrl and $realm (or $trustRoot, which is an alias).
 * The default values for those are:
 * $openid->realm     = (!empty($_SERVER['HTTPS']) ? 'https' : 'http') . '://' . $_SERVER['HTTP_HOST'];
 * $openid->returnUrl = $openid->realm . $_SERVER['REQUEST_URI'];
 * If you don't know their meaning, refer to any openid tutorial, or specification. Or just guess.
 *
 * AX and SREG extensions are supported.
 * To use them, specify $openid->required and/or $openid->optional before calling $openid->authUrl().
 * These are arrays, with values being AX schema paths (the 'path' part of the URL).
 * For example:
 *   $openid->required = array('namePerson/friendly', 'contact/email');
 *   $openid->optional = array('namePerson/first');
 * If the server supports only SREG or OpenID 1.1, these are automaticaly
 * mapped to SREG names, so that user doesn't have to know anything about the server.
 * To get the values, use $openid->getAttributes().
 * The library requires PHP >= 5.1.2 with curl or http/https stream wrappers enabled.
 * @author Mewp
 * @copyright Copyright (c) 2010, Mewp
 * @license http://www.opensource.org/licenses/mit-license.php MIT
 */

comp500 wrote:

jvvg wrote:

Rub0Gameton wrote:

Ok, maybe I did not take into consideration all the syncing system you must have in place related to your user system, more specifically between your forums and main site. I personally took a look at your site (it actually really impressed me) and realized you just ask for a user's Scratch password once to verify their Scratch account (correct me if I am wrong). I found an alternative. Instead of using OAuth for the authentication system as a whole, you could use it just for that small part. You would not need to set up all of the tables that are required or the modules. The OAuth PHP library lets you make a simple script to log in without the use of a database. You can look for it in Google Code. This way, it would not mess with your user system at all.
EDIT: On a side note, I can't find anything related to installing PHP modules for OAuth nor do I remember doing it before. Are we talking about the same thing? (Also removed a few quotes, they took too much space).

This is what told me it's a module
I looked at the one you told me about (it's here, for future reference) and it still looks rather complicated and too difficult for Scratchers who are still learning web programming.

I have found an easy one I know how to use… but OAuth == OpenID right? This…

Edit: Comment on the api .php file:

/**
 * This class provides a simple interface for OpenID (1.1 and 2.0) authentication.
 * Supports Yadis discovery.
 * The authentication process is stateless/dumb.
 *
 * Usage:
 * Sign-on with OpenID is a two step process:
 * Step one is authentication with the provider:
 * <code>
 * $openid = new LightOpenID('my-host.example.org');
 * $openid->identity = 'ID supplied by user';
 * header('Location: ' . $openid->authUrl());
 * </code>
 * The provider then sends various parameters via GET, one of them is openid_mode.
 * Step two is verification:
 * <code>
 * $openid = new LightOpenID('my-host.example.org');
 * if ($openid->mode) {
 *     echo $openid->validate() ? 'Logged in.' : 'Failed';
 * }
 * </code>
 *
 * Change the 'my-host.example.org' to your domain name. Do NOT use $_SERVER['HTTP_HOST']
 * for that, unless you know what you are doing.
 *
 * Optionally, you can set $returnUrl and $realm (or $trustRoot, which is an alias).
 * The default values for those are:
 * $openid->realm     = (!empty($_SERVER['HTTPS']) ? 'https' : 'http') . '://' . $_SERVER['HTTP_HOST'];
 * $openid->returnUrl = $openid->realm . $_SERVER['REQUEST_URI'];
 * If you don't know their meaning, refer to any openid tutorial, or specification. Or just guess.
 *
 * AX and SREG extensions are supported.
 * To use them, specify $openid->required and/or $openid->optional before calling $openid->authUrl().
 * These are arrays, with values being AX schema paths (the 'path' part of the URL).
 * For example:
 *   $openid->required = array('namePerson/friendly', 'contact/email');
 *   $openid->optional = array('namePerson/first');
 * If the server supports only SREG or OpenID 1.1, these are automaticaly
 * mapped to SREG names, so that user doesn't have to know anything about the server.
 * To get the values, use $openid->getAttributes().
 * The library requires PHP >= 5.1.2 with curl or http/https stream wrappers enabled.
 * @author Mewp
 * @copyright Copyright (c) 2010, Mewp
 * @license http://www.opensource.org/licenses/mit-license.php MIT
 */

Stack Overflow wrote:

OpenID is about authentication (ie. proving who you are), OAuth is about authorisation (ie. to grant access to functionality/data/etc.. without having to deal with the original authentication).

OAuth could be used in external partner sites to allow access to protected data without them having to re-authenticate a user.

The blog post “OpenID versus OAuth from the user’s perspective” has a simple comparison of the two from the user's perspective and “OAuth-OpenID: You’re Barking Up the Wrong Tree if you Think They’re the Same Thing” has more information about it.