Skip to content

Typesense port protocol params#38

Open
Bermudez0622 wants to merge 2 commits into
typesense:masterfrom
Bermudez0622:typesense-port-protocol-params
Open

Typesense port protocol params#38
Bermudez0622 wants to merge 2 commits into
typesense:masterfrom
Bermudez0622:typesense-port-protocol-params

Conversation

@Bermudez0622

@Bermudez0622 Bermudez0622 commented Aug 21, 2022

Copy link
Copy Markdown

Change Summary

If Typesense self hosted cluster is not running at 443 port, firestore will not sync changes
image

PR Checklist

@jasonbosco

Copy link
Copy Markdown
Member

@Bermudez0622 The reason we haven't allowed protocol to be configured in the extension is because the trigger functions run on Firebase and so we don't want calls to Typesense going over an unencrypted http connection via the public internet, to any Typesense Cluster, self-hosted or not...

Are you able to setup an SSL cert on your self-hosted Typesense node and use the default 443/https. LetsEncrypt for example has free SSL certs.

@darren-lawlabs

Copy link
Copy Markdown

We are currently trying to use this extension using the firebase ext:sdk:install method of setup instead of config files. We are trying to do this because we have a large number of collections we would like to setup and the sdk method allows us to programmatically do this with far less setup code and repetitive files. This works fine for our staging/prod environments but it does not work for local development with a locally running Typesense container because this is missing. This yaml file is used to provide the parameters in the SDK setup not just the manual UI. Without this we are forced to set this up using 2 methods: the method we are trying to avoid just for local development and the desirable one for staging/prod. This is even less ideal because we have to support double the setup, so do we abandon trying to use sdk install which is far more desirable?

I was about to submit this change as a PR myself before I found this one. Considering there are valid use cases for these parameters, which are available in the config file deployment method, it seems arbitrary to not include this in the newer better deployment method as well.

Is there a way to check if the extension is running in a production or emulated environment and throw an error if https is not used appropriately? Doing this would enable local development with the sdk setup method and close the loophole of using the config files to enable unencrypted communication in production environments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants