Dev mode

[deontologician]

We've discussed a couple of ideas about what dev mode should do, and how to discourage people from using it on their production servers.

Dev mode benefits:

1. auto index creation
2. auto table creation
3. (maybe) insecure websockets

Possible dev mode limitations

• limited number of simultaneous client connections

This looks like trial-ware but the idea is to have limitations which you're unlikely to trip while prototyping, but you'll trip very quickly when doing load tests etc.

[mlucy]

Automatic table creation isn't so bad because if people leak tables it just slows down metadata operations, but automatic index creation will slow down all writes if people create a bunch of indexes during development that they never use in production.

Another option would be to allow unindexed operations in development mode, and force people to specify indexes at the same time as they specify security rules (which they'll have to do for production anyway). Or to force people to specify indexes at the same time as they specify security rules and then delete all indexes not specified in that manner when the production mode switch is flipped.

[coffeemug]

Here is how I think the dev mode should work/be controlled.

Dev mode is one if there are no security rules specified by the user (the default mode). When dev mode is on, the Fusion server prints a large warning:

YOUR APP IS INSECURE: PLEASE SPECIFY SECURITY RULES

(Or something like that) In dev mode, tables and indexes are created automagically by the Fusion server, and secure websockets are not required.

Once the user specifies security rules (somehow, we'll have to figure that out), the server now runs in prod mode. In this mode tables and indexes aren't created implicitly -- they must be already in the db, or must be explicitly specified in the security rules. Also, in prod mode secure sockets are turned on, but the user can turn them off in the security rules.

I don't think we should limit anything in dev mode; the warning printed by the server together with the docs should be enough to get the user to specify security rules.

automatic index creation will slow down all writes if people create a bunch of indexes during development that they never use in production

Hmm, this is probably going to be ok (since there is usually little data in dev), but you might be right that falling back on filters in dev mode is a better option. I'd do the easiest thing possible to get v1 up (which seems to be index creation as it's already done), and then reconsider.

(You might notice that we do, in fact, appear to adopt relevant development practices wrt this product 😁)

[marshall007]

If people try to dynamically generate collections and/or perform lookups based on dynamic property names, it might be non-obvious that this would not work in production mode. Logging all implicit operations on the client as warnings and making it clear this won't happen in production might help.

I'm imagining people trying to do collection-per-user type of thing.

[mlucy]

Hmm, this is probably going to be ok (since there is usually little data in dev)

The question isn't the amount of data but the variety of queries. If I rename a field 3 times while developing, I'll end up with 3 indexes, which will continue to exist in production and slow down all writes.

Thinking about it more, I think I like the idea of pruning all indexes that aren't allowed in security rules when the server starts up in release mode. That's probably the least effort, and you're right that we don't care too much about efficiency in development mode.

Once the user specifies security rules (somehow, we'll have to figure that out), the server now runs in prod mode.

I don't think we should switch from development to production mode as soon as you specify a security rule. I would guess people will want the ability to do development with security rules on. (Also, it would be confusing to me if specifying a security rule changed a bunch of other things at the same time. If I finish part A and add security rules for that table, why should automatic index creation stop on part B that I'm still developing? The relationship between the existence of a security rule and automatic index creation isn't at all obvious.)

I think we should make people explicitly switch over, either in the web UI if we support that in the first version or by passing --release as a command line flag. I think the flow should go something like this:

• If you start the server normally:
  • It prints a notice that it's running in debug mode.
  • It prints a notice that security rules are off, but that you can specify security: true in the client when connecting if you want to test them in debug mode.
  • It binds to localhost, tells you about it, and tells you how to make it bind to external interfaces if you really want to.
  • It tells you about the --release option.
  • You can pass a flag security: true on the client when you connect to the server if you want to test your security rules in debug mode.
• If you start the server in release mode:
  • It prints a notice that it's running in release mode, security rules are on, automatic index creation is off, etc.
  • It binds to external interfaces, tells you what it bound to, and tells you how to change what it bound to.
  • It prints a big nasty warning if you have no security rules.
  • If you have at least one security rule, it deletes all unneeded indexes.

Logging all implicit operations on the client as warnings and making it clear this won't happen in production might help.

+1

We should probably also print these warnings on the console for people.

[coffeemug]

Let me clarify what I meant.

I think of the security rules (especially with respect to table and index creation) as a config file. While the config file is missing, everything's allowed; when you add it, you copy security.example (or we can do something like fusion rules-create). In the default/example config there will be rules to turn off automatic index and table creation, and there will possibly be an explicit list of indexes/tables to create on a fresh RethinkDB instance.

You can comment those parts out if you want and continue developing as before; or you can keep them and the server won't automatically create tables and indexes.

So the "mode" is implicit in what you put in the security rules. It really isn't a mode in a binary sense -- you can enable and disable various security features in the rules/config. I think that's much better than having actual modes -- I really don't like the idea of starting the server in two opaque modes that do different things. I think it's helpful to think of these security features in terms of "dev mode" and "prod mode" buckets as we design the product, but I don't think we should actually have two discrete modes that do different things.

I always hate things like x --release as a user -- I don't know what that does and how it's different from x. I think it's much better to keep the specific, granular aspects in the config/security rules, and give the user full control by letting them comment various granular aspects out/put them back in at any time.

[mlucy]

Ah, OK! I was misunderstanding your proposal.

The problem with a granular config file like that is that it's easy to turn stuff off during development and forget to turn it back on. For instance, let's say I add this config file because I want to test security rules, but I'm still doing development so I comment out the "no automatic table creation" line. Now I have to remember to uncomment it. The more lines like that there are, the higher the chances that users will miss something.

It also has the problem that you want default-allow in development mode and default-deny in release mode. So if you add a config file to define rules on one table during development, the server would switch to default-deny for all the other tables unless you added rules exempting them. (And then that's more stuff you need to go back in and change at the end, and if you forget then you just have a default-allow rule that leaked into release mode.)

I think that having this stuff (binding to the outside interfaces, switching to default-deny for security rules, disabling automatic index creation, probably different warnings, probably exposing more stuff in the client, probably other stuff as the project grows) grouped together into a single flag makes sense because you usually want to toggle them all on or all off at the same time, and you want really nasty warnings in release mode if you have an unsafe config.

---

Aside from that, isn't it pretty common for tools like this to have an explicit mode? I know Flask has an explicit debug mode, for example.

[coffeemug]

Hmm, I see. I have to think about it a little bit.

[danielmewes]

+1 on what @mlucy said. I really prefer having two explicit separate modes.

[deontologician]

@Tryneus I think you did everything that was discussed, and anything that wasn't done probably wasn't important. Closing