Configuring sharedlists for Terra

[wvengen]

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

On 23 March 2019 11:35:38 CET, "benD [via foodsoft]" <[hidden email]> wrote:

Allright, after pulling the updated image and restarting the container I still see the same Version number displayed in foodsoft (4.6.99) and still have the same issues regarding articles sync.

Here is what currently works:

* Adding a supplier which is defined in sharedlists

Using the "choose articles to import" sync
* Importing articles from this supplier
* updating imported articles which have changed in sharedlists
* deleting articles which have been deleted (or have number changed) in sharedlists

Using the "All Articles" sync (either "new are available" or "new are unavailable")
* deleting articles which have been deleted (or have number changed) in sharedlists (those articles were previously imported via the "choose articles to import" sync option)


What doesn't work using the "All Articles" sync (either "new are available" or "new are unavailable"):

* updating changed articles from sharedlists
* adding new articles from sharedlists

---

If you reply to this email, your message will be added to the discussion below:

http://foodsoft.51229.x6.nabble.com/Configuring-sharedlists-for-Terra-tp2076p2111.html

To start a new topic under foodsoft-discuss, email [hidden email]
To unsubscribe from foodsoft-discuss, click here.
NAML

[benD]

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]

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 or the database 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 you sent, I was able to reproduce, and have opened issue #633. Let continue the conversation there.

[wvengen]

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

[benD]

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]

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

- Willem

On 23 March 2019 20:17:29 CET, "benD [via foodsoft]" <[hidden email]> wrote:

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!!

---

If you reply to this email, your message will be added to the discussion below:

http://foodsoft.51229.x6.nabble.com/Configuring-sharedlists-for-Terra-tp2076p2116.html

To start a new topic under foodsoft-discuss, email [hidden email]
To unsubscribe from foodsoft-discuss, click here.
NAML

[benD]

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]

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

On 21-04-19 11:09, benD [via foodsoft] wrote:

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!!

---

If you reply to this email, your message will be added to the discussion below:

http://foodsoft.51229.x6.nabble.com/Configuring-sharedlists-for-Terra-tp2076p2198.html

To start a new topic under foodsoft-discuss, email [hidden email]
To unsubscribe from foodsoft-discuss, click here.
NAML