Feature request: authentication before creating group

[oselin]

The feature title is quite clear. So far, if I run a Spliit instance locally and expose it to the web, anybody can create a group. In other words, if I expose my local instance at spliit.example.com, anyone can create a group at the given url.

I think it is better that only allowed users can do so

[pavlos-dontas]

if I expose my local instance at spliit.example.com, anyone can create a group at the given url.

This is the reason I had to use Cloudflare access/policy so I can only let whitelisted users (family members) based on email to use the exposed app.

[karldelandsheere]

That’s exactly why I can’t commit to use this app, despite being what I was looking for to replace Tricount.

[Arthurin]

I'm also concerned about the lack of authentication on Spliit. If you are hosting it, isn't it possible to use a basic password protection like .htaccess ?

[Uli-Z]

I created a fork to address this problem. Its a fork of Spliit adapted for fixed communities. All groups are visible to all users, and access is protected by a shared password. You can turn on/off each feature by setting env-vars:

https://github.com/Uli-Z/spliit-room

[Arthurin]

I created a fork to address this problem. Its a fork of Spliit adapted for fixed communities. All groups are visible to all users, and access is protected by a shared password. You can turn on/off each feature by setting env-vars:

https://github.com/Uli-Z/spliit-room

Nice, thank you @Uli-Z ! Have you considered doing a pull request? It would be great to implement these optional functionalities in order to stay up-to-date with newer versions, to benefit more users, etc.

[Uli-Z]

Yes, I’ve considered it. For now, I’ve decided against it. I still need to test the functionality a bit more — it's a bit more complex, so I want to give it some time. I also have strong doubts whether the changes align with the core design philosophy of the original project. Since it’s a rather significant shift, I felt a fork was more appropriate for now.

That said, the structure remains compatible with the upstream repo, so updates can be integrated easily to keep things up-to-date. If @scastiel is interested, I’d be happy to look into preparing a PR.

[chrislockwood]

It is an ugly hack, but if using a reverse proxy to enable SSL support you might also consider sending the relevant endpoint into a black hole, at least until this project offers a more robust alternative.

location = /groups/create {
   return 444;
}