Users

[confused-Techie]

Alright one more oversight that's been pointed out, seems there is another undocumented API endpoint that's been discovered,

But we have two undocumented endpoints to cover, and another SQL Database change we need. Which on that last part @Digitalone1 I'd appreciate any assistance you can offer.

---

• /api/users: This will be an authenticated Endpoint, which returns the authenticating Users information back to them.
• /api/users/:userName: This endpoint will have no authentication, and will return the public details of another user. The big kicker here, this endpoint needs to return all of said users packages they have published.

---

A few notes:

Firstly these endpoints are undocumented because they don't seem to actual exist on the backend API. But they exist on the frontend website. But since of course this API is supposed to include everything, I feel that it should be added here.

Secondly, the reason I mention a Database change, is because currently there is no foolproof way to determine which packages belong to which user. This is something we do by checking what they have access to on GitHub itself. Meaning we may need to add in another column on the packages that links the user to the package they are publishing, while they publish it.

Which brings me to my third point. What about already published and migrated packages? Do we make any attempt to link them to a user?

Which if we did, would mean that during a users onboarding process we would have to either use the username to determine ownership, which I really don't think is a good idea, because then otherwise we have to get a list of the repos they have access to and check that against every package in the system. This would become expensive fast, and doesn't really seem practical.

So if we decide to let all migrated packages remained orphaned, that's fine and something we can do, but if we do I recommend that for v2 we try and think of how we can let users adopt a migrated package, if they need to. Could be done during any updates, or have a dedicated new endpoint in v2 that would allow them to attempt to adopt a package.

Which the later suggestion is more what I feel is possible for us here, since it would be problematic to do a manual adoption any way I see it.

But would love to hear your thoughts, and that we are able to get these other steps done no matter what we decide to do for existing packages

[confused-Techie]

It's worth saying, at this point the support for the user endpoints has been built in.

All that would be required is to create the methodology to retrieve a users full list of packages, and append it to this list.

But for the meantime, the endpoint is at least functional

[Digitalone1]

Is this necessary for v1? I'd say let's postpone it to v2.

Anyway I have some thoughts:

• A package belongs to a user, but that's not always true. There are also forks on Github. How can we determine a single owner? I don't remember how we do currently, but if we check the list of the packages we end up having multiple user owning a package because of the forks. And even if it's not a fork, nothing forbids me to create a different package and name it the same as another and it will count as the one on Pulsar I think. That's very tricky to manage, I thought this was already handled by the backend somehow.
• Another issue is the rename. Look at the current repository for example. This was named atom-community-server-backend-JS, but now it's only atom-backend. If we look only for the latter, I'm the real owner because of the fork, not @confused-Techie, which is not true.
• A first proposal would be having a table for users (which we already have, but is it enough? Should we add other information?). Then we should decide whether link it "one to one" or "one to many" against packages. Because of the forks, one to many seems near to the reality, but a user can also have more packages, so we would end in the situation like the stars against the packages, may to many.

It's tricky, I'd say let's postpone this and focus on other priorities.

[confused-Techie]

I'm on board to postpone this. We will just include a user endpoint like I've already implemented, and leave the actual package side of things for v2.

But to answer your question, yes and no.

The way it should work:
Essentially what happens is a User gives us a token and a package name. we are able to ensure that the token matches on of our accounts, and exists and is valid to GitHub.

We later then ask GitHub give us every repo the user has access to. Then we enumerate this list, to determine do they have access to the repo they claim to (By attempting to delete or modify a package) under this name.

We do match the ownership by using the full owner/repo so that wouldn't ever allow you to claim ownership of this repo if it were a package.

But you do bring up a great point. One oversight, is if a package is renamed then we would miss it.

Keep in mind once renamed the old name will still resolve, that's why if you go to https://github.com/confused-Techie/atom-community-server-backend-JS it still resolves to this repo, but if I ask GitHub for every repo I own it won't be listed because the name has changed.

We should probably add in some check for this or some new methodology, but otherwise this should be mostly a non-issue to determine ownership at the time of modifying a package.

But yeah I don't see any good way to do so statically. As in without a users Token and access to their GitHub, which can only take place during authenticated actions.

That's why I was thinking we could have /api/packages/adopt where the user provides their Authentication, and the name of the package, which we take the same steps to determine ownership, and now if we can determine the user has write access, they can be claimed as the owner and list that on the package.

[confused-Techie]

So I want to add, the users endpoint is fully implemented and working.

The only aspect not functioning yet is listing a users stars. So I'll cross this off our todo list for v1, and we can worry about listing a users packages for v2