csev
commented
6 years ago A couple of things. (1) You don't need to log in to do the admin or developer stuff, locally hosted. (2) in my crazy refactor / improvement of the App Store UI, I messed up the navigation that makes this work well when bootstrapping a dev environment, (3) realizing this from you and others, I restored the navigation that makes this easy when you bootstrap, and (4) I made login smarter to know that there is no point in trying.
It is not even a medium priority for me to support a login system other than Google to Tsugi. I have no interest in developing (yet another) a local login system with password reset, robot guessing, etc etc. Really, all Tsugi needs in terms of supporting login is administrator login (Google not required) to set things up and manage things and Instructor login to request and receive LTI keys. Because it is all LTI, students never need Tsugi accounts.
When this becomes an LMS (i.e. Koseu) and students use the site directly - then they use Google accounts. At that point, the decision is really up the the content owner (i.e. www.py4e.com and www.wa4e.com). And lots of logins could be plugged in. But since Koseu is aimed at replacing edX and not on-campus enterprise LMS - Google as login is fine and is super low effort and easy to secure.
And furthermore, it makes Google Classroom integration super awesome. And that will turn out to be very important in the next decade.
ELMS could trivially be the controlling LMS for Tsugi (i.e. instead of Koseu) and then ELMSN would be the login master. Tsugi would not care at all.
btopro
"You need to set $CFG->google_client_id in order to use Google's Login" -- Beyond the "we don't feel like supporting login systems" message it gives, is there a real reason? Otherwise this would be very difficult to get into certain environments unless this is only the requirement for the admin user to get logged in (tho also odd since I had to put in a password into a file manually in order to use this)