Configuring sharedlists for Terra

wvengen · March 23, 2019, 11:22am

Thanks for the overview!
Can you include the error message from the docker container logs, to be sure?

benD · March 23, 2019, 12:22pm

Sorry, there is no error message in the logs. This is the log output when fetching articles using the “All Articles” sync:

Started POST "/f/suppliers/15/articles/sync" for 172.17.0.1 at 2019-03-23 10:33:51 +0000
Processing by ArticlesController#sync as HTML
  Parameters: {"authenticity_token"=>"K3ZuO4f7jt3EYgwJoKB+gyH9tGtdersXmucx1K79bwWCnIe9zlXXT4cEKhyce1NuxUZdf1e4h3Ut/wwt6as/JQ==", "foodcoop"=>"f", "supplier_id"=>"15"}
Set locale to en
Redirected to https://foodcoop.DOMAIN.org/f/suppliers/15/articles
Completed 302 Found in 26ms (ActiveRecord: 14.7ms)
Started GET "/f/suppliers/15/articles" for 172.17.0.1 at 2019-03-23 10:33:51 +0000
Processing by ArticlesController#index as HTML
  Parameters: {"foodcoop"=>"f", "supplier_id"=>"15"}
Set locale to en
  Rendered articles/_articles.html.haml (5ms)
  Rendered articles/index.html.haml within layouts/application (13.3ms)
  Rendered layouts/_footer.html.haml (2.8ms)
  Rendered layouts/_header.html.haml (20.9ms)
Completed 200 OK in 47ms (Views: 28.5ms | ActiveRecord: 10.5ms)

Might it be that foodsoft doesn’t query sharedlists when updating articles using the “All Articles” methods? Looking at the logs of both containers I don’t see any output of sharedlists when trying to fetch articles. Or does foodsoft fetch data only direct from the sharedlists database without querying sharedlists itself at all? Then I don’t understand the GET line in the log ouptut. It looks like there is a successful GET on the docker host IP (172.17.0.1). On this IP haproxy listens on but in foodsoft it is only referenced for database access on port 3306. Not for webaccess.

Is there a way to check if foodsoft does query the database correctly?

wvengen · March 23, 2019, 4:29pm

Hi On 23-03-19 13:22, benD [via foodsoft] wrote:

Sorry, there is no error message in the logs. This is the log output
when fetching articles using the “All Articles” sync:

Started POST “/f/suppliers/15/articles/sync” for 172.17.0.1 at 2019-03-23 10:33:51 +0000
Processing by ArticlesController#sync as HTML
Parameters: {“authenticity_token”=>“K3ZuO4f7jt3EYgwJoKB+gyH9tGtdersXmucx1K79bwWCnIe9zlXXT4cEKhyce1NuxUZdf1e4h3Ut/wwt6as/JQ==”, “foodcoop”=>“f”, “supplier_id”=>“15”}
Set locale to en
Redirected to https://foodcoop.DOMAIN.org/f/suppliers/15/articles
Completed 302 Found in 26ms (ActiveRecord: 14.7ms)
Started GET “/f/suppliers/15/articles” for 172.17.0.1 at 2019-03-23 10:33:51 +0000
Processing by ArticlesController#index as HTML
Parameters: {“foodcoop”=>“f”, “supplier_id”=>“15”}
Set locale to en
Rendered articles/_articles.html.haml (5ms)
Rendered articles/index.html.haml within layouts/application (13.3ms)
Rendered layouts/_footer.html.haml (2.8ms)
Rendered layouts/_header.html.haml (20.9ms)
Completed 200 OK in 47ms (Views: 28.5ms | ActiveRecord: 10.5ms)

Might it be that foodsoft doesn’t query sharedlists when updating
articles using the “All Articles” methods? Looking at the logs of both
containers I don’t see any output of sharedlists when trying to fetch
articles. Or does foodsoft fetch data only direct from the sharedlists
database without querying sharedlists itself at all? Then I don’t
understand the GET line in the log ouptut. It looks like there is a
successful GET on the docker host IP (172.17.0.1). On this IP haproxy
listens on but in foodsoft it is only referenced for database access
on port 3306. Not for webaccess.

Is there a way to check if foodsoft does query the database correctly?

Foodsoft has a direct connection to the sharedlists database, so you’d
need to configure either Foodsoft
https://stackoverflow.com/questions/23397341/display-sql-queries-in-log-with-rails-4
or the database https://mariadb.com/kb/en/library/general-query-log/
to show queries.
First a POST is done to do the synchronization, and after that was
finished, it redirects you to the articles page which is a GET request.
This is expected. If there is anything to tell, it will show in a flash
alert on top of the page. So if there is no error message in the flash
alert, it looks like Foodsoft thinks it has synchronized, but you don’t
agree.

Based on the previous mail
http://foodsoft.51229.x6.nabble.com/Configuring-sharedlists-for-Terra-tp2076p2111.html
you sent, I was able to reproduce, and have opened issue #633
https://github.com/foodcoops/foodsoft/issues/633. Let continue the
conversation there.

wvengen · March 23, 2019, 5:54pm

If you check the new docker image, it’s probably fixed.

benD · March 23, 2019, 7:17pm

YES IT WORKS!!!

Thanks a lot. No doubt, this was a fiercy little bug that was hard to find. But in the end you fixed it! Great!
I already tetsted with new and changed articles and everything works fine by now.
I bet we will come up again with more wishes or maybe little bugs (I already found one or two but that’s for another topic). I’ll push the maintainers of the foodcoop to add themselves to your list, but that’s not my decision.

Again, thank you very much for fixing this and making the combination foodsoft + sharedlists working again!

Best wishes from Berlin!!

wvengen · March 24, 2019, 10:11am

Super, I’m glad it’s working now. Thanks for your patience All the best in Berlin!

Willem

benD · April 21, 2019, 9:09am

Hi Willem,

Sorry for opening this again, but we still have some issues with sharedlists.
Things like import and sync work fine, more or less, but we can’t delete articles from sharedlists. This is because sharedlists itself runs without TLS behind a reverse Proxy which acts as TLS endpoint. In sharedlists I set the environment “RAILS_FORCE_SSL=false”, as mentioned in the wiki. But now the generated URLs are cribbled. Most of them point to “DOMAIN/PATH” and only some of them (like logout) point to “https://DOMAIN/PATH”. Using DOMAIN only leads to opening the URI first without TLS, then the proxy redirects to https. That’s no problem having simple GET URIs. But calling the URI with arguments leads to ruby rejecting the call with a CSRF warning and the user only sees login page:

Started DELETE “/suppliers/1/articles/3348” for 172.17.0.1 at 2019-04-21 09:01:53 +0000
Processing by ArticlesController#destroy as HTML
Parameters: {“supplier_id”=>“1”, “id”=>“3348”}
WARNING: Can’t verify CSRF token authenticity
Redirected to http://DOMAIN/log_in
Filter chain halted as :login_required! rendered or redirected
Completed 302 Found in 0.5ms (ActiveRecord: 0.0ms)
Started GET “/log_in” for 172.17.0.1 at 2019-04-21 09:01:53 +0000
Processing by SessionsController#new as HTML
Rendered sessions/new.html.haml within layouts/application (0.6ms)

Any idea what to do here? I know it works when visiting sharedlists without TLS but this only works via VPN or SSH tunnel.

Thanks and happy easter!!

wvengen · April 22, 2019, 9:31am

Hi,

You can set RAILS_RELATIVE_URL_ROOT to customize generated URLs (precompiled assets containing internal links would need to be recompiled, but sharedlists doesn’t have those).
This is also done in the foodcoops.net docker-compose configuration.

Cheers,

Willem