Update docker-compose.yml to deploy with the new frontends

[MichaelBailly]

Currently, our docker-compose.yml deployment system is not using the new frontends. This issue objective is to have a deployment of OpenPaaS through this docker-compose.yml file, so that it also deploy/uses the new frontends.

Related issue: https://github.com/OpenPaaS-Suite/esn/issues/28

[piavgh]

WIP PR: https://ci.linagora.com/linagora/lgs/openpaas/esn/merge_requests/1299/diffs

[piavgh]

@chamerling : I asked devops team in VN and they said that there is no way to make Traefik set up our frontend apps at the URL: <address>/#/contacts or <address>/#/calendar as you said on Mattermost

So at the moment, I'm setting up them using route <address>/contacts or <address>/calendar as in this PR But using this way, we will need to update our SPA to add a prefix /contacts/ or /calendar/ before all asset urls

Problem:

1. We will need to add the prefix (for example /contacts) before some assets in index.pug:
   • script(src="/contacts/env/openpaas.js")
   • src="contacts/white-logo.svg"
   • ...

=> We can not run each container separately. Please advise if it's incorrect.

2. Also, after logging in, it will redirect us back to { URL }/#/contact/addressbooks/all/, which is not the correct URL (the correct one in this case is { URL }/contacts/contact/addressbooks/all)

I guess we need to update it here https://github.com/OpenPaaS-Suite/openpaas-auth-client/pull/3#discussion_r471214668

[chamerling]

@piavgh OK I understand. I guess we can now use the history API on all the browsers we want to support (https://caniuse.com/#feat=mdn-api_history) and so do not have # anymore. There is probably a clean way to do this in all the SPAs from webpack configuration also, and then the docker-compose using traefik will be OK.

WDYT @MichaelBailly ?

[MichaelBailly]

I'm OK to spend a couple of hours to test it. The main pain point we'll have is the reverse-proxy configuration.

[chamerling]

@piavgh is it OK for you to test it?

[piavgh]

@piavgh is it OK for you to test it?

Sure, I will do it.

Just want to confirm what needs to be done here (so I don't misunderstand you): We will need to update the code of each of our SPA(s) so that it will not use the # anymore, instead, it will use the history API, is that correct?

And this applies to both of Angularjs project (calendar, inbox, contacts, ...) and Vuejs (login), right?

[chamerling]

Yes, there is probably a call to $locationProvider.html5Mode(true); somewhere that can be removed.

[piavgh]

Things need to be done:

• [x] Remove # in URL
• [x] Update webpack-dev-server setting to support the new URL (even when reloading) for development
• [x] Update login method in esn-frontend-login/src/views/Login.vue to correct this redirection window.location =/${window.location.hash};
• [x] Update Nginx setting in Docker image of each SPA to support the new URL (even when reloading)

[chamerling]

@piavgh I am working on OIDC/login/logout so item 4 may be optional for you

[piavgh]

@chamerling : Please check this video: https://drive.google.com/file/d/1gBDc2faW21VUaSFDp5KUb-N6QtGHtZS1/view

At the moment, I was able to update the login SPA to redirect back to the correct SPA (without the #).

The problem is: it runs in a loop:

1. We go to http://localhost:4000/contact
2. It redirects us to http://localhost:4000/login?continue=/contact
3. We enter username/password and press Login, it redirects us back to http://localhost:4000/contact
4. Back to 1

Question 1: I guess it's normal because now we don't have any login token yet. Is it correct?

Question 2: I don't understand how it works with webpack-dev-server (after logging in, it redirects us back to the SPA and stays there). Can you please explain the mechanism with webpack-dev-server

---

EDIT:

It was caused by CORS issue. Previously, our frontend code is always served along with the backend API. So they are always on the same origin, thus the cookie will be sent.

Now the frontend SPAs and the backend API are on different origins, so we need to update the code. Fixed on this PR

[piavgh]

@chamerling : now we have another problem if we use the History API.

Because we have this piece of code in esn-frontend-contacts/src/app/app.config.js:

angular.module('esnApp')
  .config(function ($urlRouterProvider) {
    $urlRouterProvider.otherwise(function () {
      return '/contact/addressbooks/all/';
    });
  });

If we go to http://localhost:4000/contacts (after setting up Traefik)

• Before using the History API: It will redirect us to: http://localhost:4000/contacts/#/contact/addressbooks/all/ as it works now on https://dev.open-paas.org/contacts

• After using the History API: It will redirect us to http://localhost:4000/contact/addressbooks/all/, which removes the part /contacts, which might break the app.

So I think we can't use history API.

---

Previously, because Traefik can't set up our frontend apps at the URL: <address>/#/contacts/addressbooks/all/ or <address>/#/calendar so I need to do it like the above discussion.

But now I realized we can set it up like: <address>/contacts/#/contact/addressbooks/all/ as we did on dev server: https://dev.open-paas.org/contacts/ I will try to go this way

[chamerling]

@piavgh I do not get all, sorry. Anyway, there are no problem updating the angularjs routes or code to have a working solution.

[MichaelBailly]

@piavgh My understanding of docs (not tested) is that ui-router/angularjs respect the base url with relative urls, so changing:

$urlRouterProvider.otherwise(function () {
      return '/contact/addressbooks/all/';
    });

to

$urlRouterProvider.otherwise(function () {
      return 'contact/addressbooks/all/';
    });

should route to contacts/contact/addressbooks/all/. I hope it helps