search

SDiFI / masdif

Manager for Spoken Dialog Framework
Apache License 2.0
1 stars 0 forks source link

Add Sdifi chat widget #12

Closed lumpidu closed 1 year ago

lumpidu commented 1 year ago

Add https://cdn.jsdelivr.net/npm/@sdifi/webchat@0.2.1/dist/webchat.umd.production.min.js

Make webchat widget configurable via the new config file config/masdif.yml. One can configure it to be enabled/disabled and at which path it should be mounted/served.

Adapt Readme and add webchat widget screenshot to documentation.

rkjaran commented 1 year ago

This is what I get back from GET /:

...

Showing /var/www/masdif/app/views/layouts/application.html.erb where line # raised:

link_tree argument must be a directory

Extracted source (around line #4):

//= link_directory ../stylesheets .css
//= link_tree ../../javascript .js
//= link_tree ../../../vendor/javascript .js

...

app/assets/config/manifest.js:4
...

I am guessing that 4th line in manifest.js isn't supposed to be there.

or just missing as a volume mapping from docker-compose.yml :)

lumpidu commented 1 year ago

The asset compilation must be integrated into the Dockerfile. I will add this to the MR.

rkjaran commented 1 year ago

The rails assets:precompile step in the Dockerfile now complains about a missing secret_key_base:

ArgumentError: Missing `secret_key_base` for 'production' environment, set this string with `bin/rails credentials:edit`

Is this supposed to be configurable in .env or only in the ruby config files (or by running rails command)?

lumpidu commented 1 year ago

Yeah this step is missing from the documentation so far. You need to generate a new SECRET_KEY_BASE variable and export it e.g. by .env.

rails secret or bundle exec rails secret is your friend.

rkjaran commented 1 year ago

Yeah this step is missing from the documentation so far. You need to generate a new SECRET_KEY_BASE variable and export it e.g. by .env.

rails secret or bundle exec rails secret is your friend.

Yeah, sorry I wasn't clear enough. SECRET_KEY_BASE is already set in .env but that's not set when the image is being built. So does bundle exec rails assets:precompile need to be a post-build/pre-start step? Or does this variable not matter for this step, and can be set to anything during the docker build?

lumpidu commented 1 year ago

It should be set to the same value as docker-compose build, because some file assets are derived from that. I wonder why rails complains about it when building. There is also a secrets.yml file, where it can be set. I have not added this file to the repo (one shouldn't). So probably, it's best to set it there and it will be active also when building or running. You should delete it then from .env

rkjaran commented 1 year ago

The Docker build context does not include the host environment (i.e. .env), so it should not have access to anything there. If it did that would mean that the value of the environment variable would be baked into the container image layer. So I'm not sure if I follow?

lumpidu commented 1 year ago

The Docker build context does not include the host environment (i.e. .env), so it should not have access to anything there. If it did that would mean that the value of the environment variable would be baked into the container image layer. So I'm not sure if I follow?

Sorry my bad: these things have changed already since Rails 5 ... a few years later now it works like that: https://edgeguides.rubyonrails.org/security.html#custom-credentials or e.g. via bin/rails credentials:help.

Now we have the secret_key_base inside config/credentials.yml.enc. The key to this file is config/master.key. This file unlocks config/credentials.yml.enc. Inside the Masdif repo only the credentials file is checked-in but not config/master.key, that is okay for me, because I have my local config/master.key, but obviously not for you.

Bear in mind, that for a starting-from-scratch-approach like you are doing, creating and afterwards individually maintaining these key files is recommended, whereas for a collaboration approach, the master.key file should be shared among the collaborators and the config/credentials.yml.enc should be checked-in. I was following the latter approach. When running the container, the contents of config/master.key should be provided as environment variable for production use via ENV["RAILS_MASTER_KEY"]. At the build phase though, master.key should be used, but should be deleted from the container after usage. I will add those commands to the Dockerfile. But you can already see that config/master.key is added to the .gitignore file but not to the .dockerignore file. Therefore, it's present inside my docker build but not in yours and this is the reason that you see the error, whereas I don't see it.

We should agree on what is our approach here. For the minimum I should add these explanations to the README.md and hint on possible git conflicts if regeneration of the credentials from scratch.