coffee_chum

joined 1 year ago
[–] [email protected] 5 points 3 months ago (2 children)

I'm pretty sure it's a lot easier than all of that. Account settings -> oauth -> link to oauth. That's it. Maybe gets more complicated but sounds like that should be it for your use case.

[–] [email protected] 2 points 4 months ago* (last edited 4 months ago)

If you end up going with conduit, I would instead use conduwuit. More development effort and better docs IMO. I think maybe even one of the main devs from conduit moved over to conduwuit? But not 100% sure

https://conduwuit.puppyirl.gay/

The domain choice? Eh, not what I would have gone with but to each their own lol

[–] [email protected] 19 points 4 months ago

Just to play devils advocate for a minute- Loading from their own domain means they can actually garner quite a bit of information from just the serving of the svg:

  • date and time of access
  • IP (country, state, region, etc)
  • Potential for SVG xss attack if hoster doesn't clamp down their CSP settings

Date/time/IP are good enough for getting pretty good estimates of who all uses their software. Doesn't matter if they are or aren't using that data- it is being sent to them on their own accord and terms. The public has no way of knowing.

And this is all perfectly acceptable, as long as you do one of the following:

  • Prominent notice to user that tracking is enabled by default, and it can be disabled by doing X, Y, or Z. State the kind of tracking information collected and maybe even say logs are kept in memory or dumped after X days.
  • Allow for opt-in tracking. This one's pretty straightforward.

All of this doesn't really matter if the dev isn't willing to change anything about the remote image.

But a fork?? Yeah, totally unnecessary. You can take easily care of this at the reverse proxy layer by preventing the svg (or anything else for that matter) from being served. Just serve a 404 or something instead or do a regex replace and remove it altogether from the page prior to serving.

[–] [email protected] 3 points 5 months ago (1 children)

That's.. not how that works. Just because they're getting separate IP addresses doesn't mean you can all of the sudden have "full control" and start using privileged ports without granting that sys capability to docker. I fear you are overcomplicating what should be a fairly straightforward process and likely weakening security because you don't fully grok the implications of the security measures you're attempting to put in place. Just use traefik or caddy and be done with it.

[–] [email protected] 3 points 9 months ago

This is the way. I just hope they don't start gatekeeping essential features behind the "enterprise" license. Already they have announced push-based 2fa (like Duo) will be enterprise which is a bit of a bummer but it's honestly awesome software otherwise and beggars can't be choosers!

[–] [email protected] 3 points 9 months ago

This is typically the case. Increasingly, self-hosted apps use integrated OIDC or OAuth but for those that don't there are various other methods of integration into the SSO provider you're using including forward auth and remote username. Authentik is nice in that it is also a forward-auth proxy and so you don't need to use an additional oauth proxy software like oauth2-proxy.