🔑 Validate organization membership

badandbest commented 5 months ago

For?

services.facepunch.com

What can't you do?

My library interacts with a backend where I tie data to players and load that data when a player joins a game. I do this using auth tokens.

I also tie data to the gamemodes organization.

I want the organization members to be able to get and set that data from in-game. But to do this I just need to be sure the user isn't lying about their membership.

How would you like it to work?

Idea 1. The auth/token endpoint could bundle the game's ident + your membership status. {"SteamId":76561198167118483,"Ident":"facepunch.bombroyale","Membership":"Owner/Member/None","Status":"ok"}

Idea 2. Create a new endpoint only for validating membership.

Idea 3. The organization's ~people page is accessible.

But anything works.

What have you tried?

I've tried validating memberships with https://asset.party/{organization}/~people, but my backend isn't authorized to view the page.
Not only is EditorUtility.Account.Memberships restricted to the editor, it's also useless when users can modify that code.

Additional context

No response

anthonysharpy commented 5 months ago

I was literally thinking of this exact thing last night. Same as badandbest, wanted to restrict access to an API based on org/gamemode (not the user's steam ID, so slightly different, but similar I guess).

Thinking about it now, I don't think it would work for my use case, because I don't necessarily want all instances of the same gamemode to use the same account (different people might host the same gamemode), so I'll probably go the normal user/password route. But I think it'd be a good feature to have.

badandbest commented 4 months ago

Any updates on this? It's the last thing preventing me from continuing my library

MD485 commented 4 months ago

It's been labeled as a proposition, that doesn't mean it's currently in development.

I don't agree with this being a good feature or something we'd necessarily want to be able to do.

Orgs are meant to facilitate collaboration between developers, I don't believe they should be used as a backing store for elevated privileges for game features managed by an external service.

If you have an external service already, why not manage your membership levels on there, given that it's what you intend to use to give authorisation in the first place?

You can generate a special key locally on first connection to the server to validate the user, that way people don't get the permissions simply by spoofing your steam id.

I don't like the idea of muddying the purpose of an org within asset party.

Facepunch / sbox-issues