Support for installation in subdirectory will be discontinued

Announcements
21

@MRamadan I actually didn’t mean to quote you at all! Sorry for the confusion. You may re-read my comment in a new context now! :slight_smile:

1 Like
22

Thanks all for the feedback and understanding. Just to be clear, we know that for some people it may add extra level of complexity (mostly the learning curve) to do the deployment on subdomains, but we strongly believe that the benefits outweighs the investment. Since we want to move faster and faster with the development, we won’t have time to keep testing this subfolder deployment, as it ads an extra level of complexity to our code base and CI environment. Besides, we have many new features on the pipeline, on how to interconnect server using a federation protocol, and this will strongly rely on having fixed API paths and deeper control of the TCP layer.

We know that this may be a costly transition for some and we want to give the community as much time as we can to do the move. We won’t be removing the subfolder code intentionally in the short term, but we won’t be giving support for such deployments and will be relying on the community for testing and fixing bugs.

Let’s work together to get the smooth SSO authentication mechanism among all of these subsystems working flawlessly.

1 Like
23

So far I have found rocket chat 3.2.2 works perfectly in a sub-folder using nginx as a reverse proxy. I could not get version 3.0.4 to work. Perhaps a bug was fixed in Meteor moving from 1.9 to 1.9.2.
I will keep testing.

1 Like
24

I consider this to be a regression. We have a single certificate bound to a specific hostname, were several services are hosted under a resp. subfolder. Rocketchat works like a charm (using 3.4.2 for the moment).

Can adding additonal tests that consider rocketchat being hosted in a subfolder be so difficult to realize? For my part I would have to switch to a wildcard domain certificate to allow for xx.mydomain.com to be handled by the webserver.

What kind of problems do you want to eliminate by eliminating subfolder support? Maybe these problems point to problems that identify more deep underlying problems.

4 Likes
25

Couple reasons why serving under a path is useful

  • It is much easier to set up apps under subfolders, less work when supported

  • I can use a single SSL cert for the whole domain

  • It is easy to hide services behind the main domain, paths are hard to explore

3 Likes
26

Yes we understand why it is easier for many.

It seems that we are going to probably continue support for this for the foreseeable future.

There are some outstanding bugs that will need to be resolved - that won’t happen until 3.16 at the earliest, but work is underway.

3 Likes
27

Hi. I found this after replying to a related thread:

Just to let you know that there is an existing issue on version 3.16.3
It should not be very hard to fix with code similar to this:

var syncUrl = "/_timesync";
if (__meteor_runtime_config__.ROOT_URL_PATH_PREFIX) {
	syncUrl = __meteor_runtime_config__.ROOT_URL_PATH_PREFIX + syncUrl;
}

But replacing /_timesync with api/ecdh_proxy/initEncryptedSession

1 Like
28

Thanks Stefan.

We are aware of a number of issues that are being worked on right now.

eg

There is also this which seems similar to yours.

I suspect that might be cleared by fixes to the others.

Linked comment here:

1 Like
29

Great to hear that it’s getting attention.
I did a workaround with nginx reverse proxy for now.

2 Likes
30

@john.crisp I’ve discovered another bug relating to the subdirectory as discussed in this post.
For reference, I just wanted to add it here because then we have all the issues in one place.

2 Likes
31

Our subfolder installation is broken since 6.2.0 (or 6.2.2) with nginx using reverse proxy (produce many unwanted redirects for every click but “works”).

Our ticket about this issue was closed with “not official subfolder supported”.

So this is the end of proper subfolder installation or has anyone a working example with the current version?

Also is there perhaps a change in the general “official unsupported” decision?

1 Like
32

Just upgraded to 6.3.5 from 5.x and am sad to see that admin links no longer work because they are not taking into account the base URL (/chat).

33

Just to elaborate, this is really awful. You’re just about pushing us to switch to an alternative chat provider!

Now that we must host RC on a different domain (read: subdomain) from where our application is hosted, local storage cannot be shared between the subdomains. This means that our SSO will no longer work without introducing some hacky iframe or redirect solution. This is because Meteor keeps its token / user id in local storage rather than a cookie (which would be supported between a domain and its subdomains).

This decision seems extremely short-sighted. It’s really not hard to prepend a base URL to URLs used within an app. Frameworks like React even do it for you. This is standard stuff.

1 Like
34

Here another user (with a team) that runs RC on a subfolder and would very much like to keep it that way. Moving everything (running a lot more services on subfolders here) to subdomains is not an option.
So unless the RC-team keeps support for this in there, I am afraid we have to migrate to another service. :confused:

35

We are using RocketChat with Docker and /rocketchat fqdn extension. It’s a nightmare, that the support for this type of installation has ended. If that’s not going to change, we need to move to a different solution, because the current situation causes permanent manual adjustments in our setup, when doing updates.