User Accounts

[Bobbyjoness]

I would like to see if I can add user account support to Vapor. But idk if I should code my own backend in lua or somehow try to use it with the official Vapor site/server. Also I would be attempting to add openssl and LuaSec.

[pablomayobre]

I dont think LuaSec is the way to go, I would prefere to use luajit-request a thousand times (at least with LÖVE)

[Bobbyjoness]

That's more binaries if I'm not mistaken. Luajit-request depends on openssl and libcurl

[pablomayobre]

In Windows that is one DLL file, in Linux that is one extra dependency (Not actually becaue for LuaSec you need LuaSec which depends on openssl, so it is actually the same) and MacOSX already has curl so no problem there (I think)

[pablomayobre]

About the real topic here (because we were actually discussing about #39 lol) this is also a 1.x milestone and not actually a 0.x milestone. So if you want to implement it in 0.x, do so in your own fork, but 1.x is a complete rewrite so it is possible that your code will not be included (at least without major changes)

[Bobbyjoness]

Majority of the work is backend. I'm basically using 0.x as a testing grounds for backend work if the things I want are approved and we decide how to do backend work. I'm thinking about doing user accounts on a lua or node server but do it as a RESTful api so the website can use it as well.

[pablomayobre]

Well you will have to host that yourself and then somehow integrate it with Drupal in the future, but I still think that the review will include MAJOR changes

[Bobbyjoness]

If its agreed on how to do it here. Then the lua/node account system can stay running independent of drupal. As I'm sure that drupal can use RESTful APIs for user accounts. It actually a good way to distribute the load

[pablomayobre]

Well then that is a different topic:

• Lets discuss what would we do with User Accounts
• Lets discuss the API
• Lets discuss the data we are gonna handle
• And lastly how are we gonna implement this (If in Lua, Node or PHP or whatever)

[Bobbyjoness]

Well for the first one I think that we can do a lot with user accounts but the simple things are messages, friends list, currently playing, better analytics based off of demographics, anything really but at first I would say that we need at least friend list and currently playing and a syncable favorite lists.

[Bobbyjoness]

And I just thought of a new issue.

[pablomayobre]

Well, I need to ask, is that all really needed? Are you considering the load all that means to the server? even more if Vapor becomes more and more accepted

[Bobbyjoness]

I can provide a server host for any of the components if it comes down to it. But in reality it should do fine on what we currently have for server hosting. The load would be not as much as you would think. Yeah more than it currently is but it wouldn't be that bad.

[pablomayobre]

Another question, isnt security a problem?

[Bobbyjoness]

Yeah but we have a community of web devs I'm sure we can figure it out. And if Vapor kicks off I'm sure we can figure out the server side stuff by then. I have some plans. A lot of plans. Lol this a good pet project no wonder leafo maintains itch.io

[pablomayobre]

I dont think this can be fixed, because there is no way to hide tokens or credentials for the client app so you could easily ask the server for all the data for an user... I guess this same applies to everything but it is, still, a problem

[Bobbyjoness]

What are you talking about? We can make it secure I don't understand the concern.

[pablomayobre]

Well I wonder about that, it is always a matter of opening the LÖVE file (or searching the github repo) to find the tokens and credentials needed to access the private API and with that you are a few requests away to dumping all the info of an user... So security is always a problem.

Anyway that is just a part of this... About the other stuff... Will this account be somewhat related to the forum account? There are private messages there and also friend lists...

[Bobbyjoness]

Credentials wouldn't be stored anywhere on the client machine. It would be entered each time.

[pablomayobre]

Yeah I know about that, I meant if the app was modified to try with multiple credentials (an actual attack)... Anyway that may be thinking too much about it for now...

What about the other thing I commented at the bottom?

[Bobbyjoness]

Being related to forum accounts would ultimately require more coordination with the Löve web devs and for us to get access to their database. I personally would not want that responsibility. An accidentally delete all would be sad.

[pablomayobre]

Yeah I thought the same hahaha... would be ultra nice though... (One account to rule them all)

[Bobbyjoness]

And the public generally don't have a love forums account

[pablomayobre]

The public generally doesnt have a Vapor account... so creating one or the other is pretty much the same...

Anyway If we go broader than LÖVE having an account in the LÖVE forums may be pointless

[Bobbyjoness]

They can make a Vapor account in app. Lol plus Vapor will have a lot more data and if we use love forums account we would need two databases for the data.

[pablomayobre]

In app registration sounds like lots of spam accounts to me... and bots and such...

[Bobbyjoness]

Ok now you just saying whatever lol. It's the same on websites lol.

[pablomayobre]

It is not, in a site you put a captcha and you have reduced this in a huge amount... in app you just modify the .love file and there you go... a million accounts in a second

[Bobbyjoness]

We can do a captcha as well.

[josefnpat]

Looking at this entire discussion, I can see the benefit of working Account Registration into the 1.x branch, but not much use in the 0.x branch due to it's design.

As @positive07 mentioned, we really need to determine what we want to be included in the 1.x branch.

As for feature request from vapor.love2d.org I see:

• Messages
• Friend List
• Currently Playing
• [demographic] analytics

IMO at this point there are not enough internet multiplayer games for love to entirely warrant this (considering I wrote xapalus, I say this with a heavy heart.) On the site I currently see:

• Netwars
• Snaik
• trAInsported

Although with the inclusion of enet in love 0.9.x, it does show a lot of promise.

What may be interesting is if we integrated a service much like the classic Kali did.

For each of the feature requests mentioned earlier, a full API needs to be discussed and laid out before implementation to ensure:

a) Security
b) Ease of integration
c) Ease of reproduction on other websites.

For implementation, I see a few ways to do it, but to ensure that Vapor is extendable and reusable, we need to approach it the right way.

1. We could add a "master" vapor user registration system that would associate accounts with mirrors. This would allow folks to be able to manage mirrors as a part of vapor.love2d.org. Unfortunately what it does do is it restricts vapor to only be used with vapor.love2d.org mirrors. I am personally against this when we can do the next option and still achieve the same objectives.

2. We could document exactly how vapor plans on authenticating (SSL) users for developers, and then associate a flag with the "mirror" object type that accepts usernames, passwords and stores sessions. This way we can maintain a "open" and "free" environment for people to use vapor any way they want.

e.g. user: seppi password:pass at vapor.love2d.org/login would respond with a session key if correct. Then vapor could syncronize the mirror with vapor.love2d.org/api?session=$session.

Then vapor.love2d.org/api could use the session key to return appropriate data.

Security Concerns: With the creation of luajit-request, we are pretty sexy. We have full https support and should have no issues with security. It requires minimal distribution of libcurl on windows, OSX comes with it, and linux usually does as well except in some odd edge cases we can test for anyway. After that, drupal for vapor.love2d.org is well prepared. We can probably get an api endpoint from the phpbb3 instance of love2d.org/forums to authenticate against them as well if we ask super nicely. For communication purposes, security shouldn't be a problem.

Service outage concerns: I intend on supporting whatever traffic vapor ends up spitting out, and drupal will scale just fine until proven otherwise.