#Alternatively if someone can provide
frozen turtle
Ultimately, the setup and join pages aren't something a module can touch like that, so manipulating the login mechanisms can't be done via module (which, honestly, is good overall).
The only real way to do that sort of thing would be to have the reverse proxy sitting in front of the join page handle automatically filling in fields in the join page based on SSO stuff handled inside the reverse proxy. I think it's doable, but I've never delved into it myself.
For syncing users between worlds, it's really not something Foundry is designed to do/handle, and you can't load databases from other worlds to do that sort of thing, but I have done some stuff with using an external server that a Foundry instance can communicate with to sync documents (including users). That sort of thing could be done, it just requires a GM loading into a world to push/pull documents and sync them, rather than intrinsic data sharing (which Foundry doesn't support)
haughty hare
I'm using a proxy already to handle the SSL termination and certificates, so adding the auth there wouldn't be too hard - the modules already exist
HTTP Basic Auth adds the username to the headers for all subsequent requests, so the easiest path would be to have the worlds allow for a character to be linked to a provided user
Ideally I'd also really like to allow certain users to have admin permissions as well, i.e. to select the worlds if I'm not available...
frozen turtle
I'm using a proxy already to handle the SSL termination and certificates, so add...
Foundry is realistically unlikely to ever change to support what you're describing. If that's something you need, your only real option is to build your own webserver interface with the capability to manage the Foundry server processes itself internally
haughty hare
so all I realistically need is a way to tell foundry that this user is this character - any ideas on how that can be achieved
frozen turtle
so all I realistically need is a way to tell foundry that _this_ user is _this_ ...
User to character connections are handled inside a world in Foundry, with the character field in a User document that points at an Actor. But that's a user in a world, Foundry itself doesn't have any cross-world document stuff other than just compendiums
haughty hare
The login screen is handled by the world or by foundry?
frozen turtle
The login screen is handled by the world or by foundry?
The login screen is handled by the core software, and not something modules can poke, with the list of users, the world name, the background image, and the description being loaded from the world and shown to users.
haughty hare
so as the authentication happens at the core software layer, this is where the association between authenticated user and character would also need to happen
frozen turtle
Hypothetically, you could have your reverse proxy pre-fill the join screen form with the appropriate User name and password for the world. That's how you would need to handle associating a human authenticated with your reverse proxy with a given Foundry user such that they only need to click "Join" to log in to the world.
haughty hare
that depends on the form never changing formats, it would be more elegant if the core server could have a table that allows me to associate an authenticated user to both the world and also as a server admin
frozen turtle
Yeah, I'm just telling you that it's highly unlikely that core will ever implement that, based on what I've seen of core development over the years. So, your realistic options are to either make your own wrapper framework and work with the form as-is and update if needed (I can't imagine it would ever change so radically that it would require more than minor updates) or to just work with stuff as it exists
haughty hare
any ideas of how I can create such a wrapper?
If there is something that already exists, even partially, somewhere that I can build from then that would be a huge help
frozen turtle
Like I said, you would do it in your reverse proxy, having it fill in the form for users based on their authenticated session with the proxy. I don't know the exact way to go about it, but AFAIK it's hypothetically doable depending on the proxy
haughty hare
that's the bit I'm struggling with, the proxy doesn't interact with the traffic that way
frozen turtle
How much sysadmin experience do have and what reverse proxy are you currently using?
haughty hare
I've been a linux sysadmin for 25 years 🙂 and the reverse proxy is apache
I'm not a developer though 😦
frozen turtle
I'm less familiar with Apache (I've moved most of my stuff at home and work to Caddy, just because it's a lot simpler to configure IMO). But there should be some sort of way to have a plugin to handle authentication (like SSO stuff) in the proxy and then have it rewrite the headers/URL/something for the page being served as it goes. Maybe even rewriting the served page with some regex as it's served?
I have a vague idea of how it would be done, but I've never actually had the burning need to do so such that I actually dug in and made it happen myself, lol
haughty hare
The rewriting is for the URL, the HTTP Basic Auth is carried in the header. None of that directly goes into the login form though
frozen turtle
From a super quick google, something like mod_sed might do the job, since it looks like that can hit the page with a regex. Since you really just need to add a selected to the right user choice and fill in the password. At least, I think that's a direction to try poking, based on a super quick look, lol.
Like I said, I've got like three general ideas of stuff to google and concepts to explore, but I've never actually tried doing it myself, so it's all just exploratory ideas at this point, lol
haughty hare
I could solve all of this with one server side module if modules could interact with the relevant parts of this
Searching through discord and git shows enough interest in people wanting to use reasonable external authentications schemes for broadly similar reasons
frozen turtle
Yeah, server-side modules are something staff have said will never be a thing, just too much of a security consideration.
And the topic of external auth stuff comes up from time to time, but it's a tiny minority of the userbase, and staff tend to focus on stuff that has broader applicability for the userbase (and more payoff for the dev hours implementing and maintaining it)
haughty hare
not having 2fa for users and especially for the admin access is also a massive security consideration
and I'd really like to improve this for all users, my ultimate aim would be to make it easy to implement passkeys for everyone that hosts online...
I'd really rather not have to ask my players to authenticate twice just to play, but that's what we're going to end up doing, and what I'll be recommending everyone does until the security in VTT is fixed
not opening up the option to allow modules for this is weakening security overall
frozen turtle
not having 2fa for users and especially for the admin access is also a massive s...
Eh, yes and no. It is a security consideration, but it's not a security problem because there isn't sensitive data in a VTT. The threat model really isn't one that benefits from 2FA (in general, the extra complexity causes more issues/work than the second factor solves, in the context of playing TTRPGs)
haughty hare
It's an attack surface for the server it's hosted on, it's the ability for someone to wipe hours of effort that people have put into worlds (yes, I have backups, but not everyone does), etc... let alone the ease of use for players that have better security but better ease of access to their characters. I could go on for hours on this.
In my case I host this on my server, albeit under a specific locked down user, but it's still an attack surface I would rather was slightly harder for a script kiddie to probe and possibly use to execute commands on my system...