🔓 Add config to secure instance from unauth users

[lukevella]

Many self-hosters ask to be able to secure their instance to prevent unauthorized users from creating polls on their instance. This update addresses this issue by adding the following configuration properties:

Name	Default	Description
AUTH_REQUIRED	false	Set to true to require authentication for creating new polls and accessing admin pages
ALLOWED_EMAILS	""	Comma separated list of email addresses that are allowed to register and login. If not set, all emails are allowed. Wildcard characters are supported. Example: "[email protected], *@example.com, *@*.example.com"
DISABLE_LANDING_PAGE	false	Set to true to take users straight to the app

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated
rallly	✅ Ready (Inspect)	Visit Preview	💬 Add your feedback	Mar 14, 2023 at 4:33PM (UTC)

[hollosch]

AUTH_REQUIRED false Set to true to require authentication for creating new polls and accessing admin pages
ALLOWED_EMAILS "" Comma separated list of email addresses that are allowed to register and login.
If not set, all emails are allowed.

Wildcard characters are supported.

Example: "[email protected], *@example.com, *@*.example.com"
DISABLE_LANDING_PAGE false Set to true to take users straight to the app

Hi, this doesn't work in my installation. Do you have an idea?

[jdaviescoates]

Hi, this doesn't work in my installation. Do you have an idea?

Same, I have the following my env file:

AUTH_REQUIRED=false DISABLE_LANDING_PAGE=true

But it still requires users to create an account, see https://schedule.uniteddiversity.coop

[lukevella]

This is config for v2. In v3 it was changed so that auth is required by default for poll creators and there's no option to disable it for self-hosted instances.

Auth is not required for users participating in a poll.

[jdaviescoates]

Ah, OK, many thanks for clarifying that @lukevella

It's a bit of a shame though as IMHO it's a nice/ better UX how it is on https://app.rallly.co/ where you can jump straight into https://app.rallly.co/new (which is presumably why you've got it set-up like that), and it'd be nice if it were possible to replicate that on self-hosted instances too.

Is it worth adding a feature request to that effect, or do you simply have no plans of making that possible?

Thanks again.

[lukevella]

@jdaviescoates If you're looking for convenience, why not use the managed service? Having multiple open instances of Rallly can harm the project as some users might not even realize they are not using the hosted version and this leads to all sorts of problems which was the main motivation for this move.

[hollosch]

Ah, ok - thanks for the info.
Unfortunately, there doesn't seem to be a "middle ground".
I would like to host it myself, but also use the function to create appointment queries without registering.
Is something like this conceivable - e.g. as a payment option?

[hollosch]

Ah, ok - thanks for the info. Unfortunately, there doesn't seem to be a "middle ground". I would like to host it myself, but also use the function to create appointment queries without registering. Is something like this conceivable - e.g. as a payment option?

This: https://support.rallly.co/self-hosting/pricing#suggested-price ?

[jdaviescoates]

@jdaviescoates If you're looking for convenience, why not use the managed service?

Just because I prefer to self-host things on my own domains if at all possible 🙂

Having multiple open instances of Rallly can harm the project as some users might not even realize they are not using the hosted version and this leads to all sorts of problems which was the main motivation for this move.

I'm unclear on what harm and problems it could cause, but fair enough I guess 🙂 I'm probably missing something obvious.

(Although TBH, given how generally confused people often get about simple tech stuff, I think even when people are using self-hosted instances with auth lots of people might not realise they aren't using the hosted version, if they even know a hosted version exists - of course at present the vast majority of people have never even heard of Rallly hosted or otherwise, )

[lukevella]

So, to clarify, the reason people want to run an open instance is not because they want to allow anyone to use it, but it's because they don't want to spend time logging in?

Doesn't it make more sense to work on making logging in easier then?

[jdaviescoates]

So, to clarify, the reason people want to run an open instance is not because they want to allow anyone to use it, but it's because they don't want to spend time logging in?

I'm confused, who said that?

As you know given you made it(!) it's already possible to run an open instance where anyone can create an account.

But some people would like to run an open instance where you can create polls without having to first create an account (basically exactly as you can on https://app.rallly.co/new right now)

I'd guess they'd want to do this for exactly the same reason that you yourself want people to be able to do it on https://app.rallly.co/new - which I'm presuming is because it improves the UX by reducing friction and making it easier for people to create polls? 🤷‍♂️

Doesn't it make more sense to work on making logging in easier then?

Well, that wasn't the motivation, but now you mention it, whilst it's already pretty easy, OIDC would make it even easier for people within our orgs to login! 🙂

[lukevella]

I'm just trying to understand what you want. Do you want to allow anyone to use your instance? In that case, an open-instance is the solution, but it would help to understand why you want this.

If you find logging in painful, running an open-instance is a pretty extreme way to solve this problem. My time would be better invested providing alternative login solutions like OIDC or password login which benefits everyone not just self-hosters.

The managed version is open to make it easier to onboard people. UX is improved only in the sense that the barrier for entry is reduced but you get less features as a guest and this will become more obvious as more features are added.

[jdaviescoates]

I'm just trying to understand what you want. Do you want to allow anyone to use your instance? In that case, an open-instance is the solution, but it would help to understand why you want this.

Yes, I'd like anyone to be able to use my instance.

I want to do this just because I like to offer nice useful tools to other people, and it makes our co-op look good and nice to be able to provide such useful services on our own domains.

If you find logging in painful, running an open-instance is a pretty extreme way to solve this problem. My time would be better invested providing alternative login solutions like OIDC or password login which benefits everyone not just self-hosters.

I don't find logging in painful. But OIDC would be great.

The managed version is open to make it easier to onboard people. UX is improved only in the sense that the barrier for entry is reduced but you get less features as a guest and this will become more obvious as more features are added.

Exactly, the barrier for entry is reduced and it's easier to onboard people if they can just jump in and use the app without immediately having to create an account first by entering their email. Totally fine/ good that they would then have to enter their email to access admin/ others features. People are used to that with Doodle etc.