Change models and/or use API

[rushsteve1]

In order to make use of the new central RCOS database and API the models have to be updated to match that database schema.

Additionally we may want to consider entirely removing Diesel and replacing it with calls to the REST API itself. It would be a good example of dogfooding and would likely require a similar amount of work since all the models and queries are going to be rewritten anyway.

CC: @Apexal

[Apexal]

I do recommend not having any database stuff at all in Telescope or any RCOS infrastructure going forward. If you depend solely on the REST API, you you have immediate access to all data, filtering, searching, populating relationships, etc. without having to spend any time modeling that on your end. Any infrastructure becomes way easier to develop and (more importantly) maintain.

[rushsteve1]

Oh, I guess #58 and #60 are tangentially related to this.

[vcfxb]

I like the motivation behind this but I'm concerned that the central database/API is not mature enough yet. The lack of independent authentication comes to mind. There are also a few other inconsistencies that we should consider. One example is that Telescope's database uses UUIDs as identifiers and the central database uses strings. We should come to a consensus on the database schema and authentication before rewriting any part of Telescope.

[Apexal]

@alfriadox Interacting with Postgrest just means sending the API key with requests, which can be stored as a secret env var. Telescope can use that API key for everything. In the routes of the application it can decide whether or not to call a specific route, e.g. don't request another user's attendance unless the logged in user is an admin. Postgrest doesn't have to know on who's behalf it is receiving requests, it's either full access (authorized) or limited public access (unauthorized). For added security, we can use row level permissions and actually send to Postgrest the user who is logged in, and we can check access there. This means that authentication of users for our infrastructure can be totally separate. We don't need to wait until we have a single solution for it, and we can change it in the future. Each of our infrastructure services simply need a way to get a user's verified RCS ID.

[vcfxb]

@Apexal It's more about user authentication than database authentication. The problem is where to store the Argon2 hashes of user's passwords. Correct me if I'm wrong but I see nowhere in the rcos-data user accounts table to do that. I don't want to have a second database just for that but that does have to be stored somewhere persistently.

[rushsteve1]

For added security, we can use row level permissions and actually send to Postgrest the user who is logged in, and we can check access there.

This is fairly straightforward with Postgres Policies and the variables exposed by PostgREST to queries. However we may not even need it since most of the interaction can be done server-side.

It's more about user authentication than database authentication. The problem is where to store the Argon2 hashes of user's passwords. Correct me if I'm wrong but I see nowhere in the rcos-data user accounts table to do that. I don't want to have a second database just for that but that does have to be stored somewhere persistently.

This circles back to my original point that I mentioned in #50, do we want to handle authentication ourselves, or do we want to offload to Oauth and not have to handle it ourselves.

I am a big supporter of GitHub Oauth personally. I think it will greatly simplify Telescope, and unify login systems across various projects (ie the Wiki, Telescope, GH itself, and whatever else) without needing to implement our own SSO system.

Tying into GitHub is admittedly not ideal, but I think it's pragmatic. Most of RCOS project development is on GitHub, and it opens up to interesting features like the automatic commit reports that Observatory-new has.

[Apexal]

I agree that we shouldn't handle authentication. We can also use Microsoft OAuth as all RPI students have an account with their RCS ID verified.

[vcfxb]

Between the two I prefer GitHub OAuth, but I don't love being tied to any large corporation or institution. If we have consensus otherwise though, I think I am good to start moving towards GitHub Auth and removing the migrations and other database stuff from telescope. From there, should we focus on dogfooding off of the Postgrest API or should we interface directly with the central database?

[Apexal]

I recommend solely using Postgrest. It will make sure it meets our needs and we can work on it if we run into issues so that any future infrastructure benefits from it.

[vcfxb]

Okay Postgrest API it is.

[rushsteve1]

We can also use Microsoft OAuth as all RPI students have an account with their RCS ID verified

Between the two I prefer GitHub OAuth

The nice thing about OAuth is that we can add/remove providers later without much effort.

[Apexal]

We do need a way to connect connect someone to their RCS ID.

[rushsteve1]

We can ask the user to login with CAS just once and tie their account with the existing user_accounts system.
The problem with that as well is that the old users from the Mongo database doesn't have RCS ids. Some users have the RPI emails which we can get RCS ids from, but some users have other emails.

[Apexal]

That's frustrating :/ Perhaps we should have a way for people to claim and merge their old accounts?

[rushsteve1]

Well we do have GitHub accounts for most of them. So if we have GitHub OAuth then we should be able to figure out who's who.

[vcfxb]

Telescope is now moved entirely to the RCOS GraphQL API.