Support for installation in subdirectory will be discontinued

Okay. Thank you very much for your answers and input.

This is very atypical. I have not heard of another case of users who did not need the mobile apps and do not care about privacy of their connection over the Internet for their deployment.

Hi,

At the time when all communications tend to be HTTPS which implies an IP for each host and an SSL certificate for each host, not being able to install their excellent Rocket.Chat program in a subdirectory, I consider it to be a regression.
In our particular case we have installed your program in a subdirectory. But additionally on the same hosts we have the company website, the support ticket manager, the opensource Etherpad program, the opensource NextCloud program, mail server, webmail server, LDAP server, etc …
I consider that it would be a regression and would imply additional costs not being able to install the Rocket.Chat in a subdirectory (IP + SSL certificate).

Thanks in advance for your excellent opensource program.

3 Likes

Thank you for your valuable input @tecnico3.

Is there some reason why you might not be taking advantage of the free certs available via Lets Encrypt https://letsencrypt.org/? This alternative should be widely supported by almost all hosting providers.

A subdirectory installation is more comfortable for us but I understand your point of view to discontinue this support. After I don’t know too much on meteor and such thing but it’s not really complicated to have a property somewhere that set the contextPath, a lot of applications / framework permits to manage that.
After to provide an argument to keep the possibility to install on a subdirectory is that on some webhost you don’t have the possibility to manage subdomains and certificates, you are limited on what the webhost provide you ! In this case you need to manage all your app install by subdirectories !

An other question, I didn’t succeed also to use a same instance of Rochet.chat on several serverName, this isn’t also a possibility ? Rocket.Chat can’t use the X-Forwarded-Proto and X-Forwarded-Host provided by a proxy server instead of setting it as fixed by UI / env variable ? This would be really appreciated too.

After to provide an argument to keep the possibility to install on a subdirectory is that on some webhost you don’t have the possibility to manage subdomains and certificates, you are limited on what the webhost provide you ! In this case you need to manage all your app install by subdirectories !

Webhost that limits you this way are not competitive and dying fast. I would be surprised if you cannot find a more flexible web hosting firm at a lower cost. Which webhost are you with that still have such restriction?

An other question, I didn’t succeed also to use a same instance of Rochet.chat on several serverName, this isn’t also a possibility ? Rocket.Chat can’t use the X-Forwarded-Proto and X-Forwarded-Host provided by a proxy server instead of setting it as fixed by UI / env variable ? This would be really appreciated too.

This is interesting, but not directly related to this topic. Please create a Feature Request here GitHub - RocketChat/feature-requests: This repository is used to track Rocket.Chat feature requests and discussions. Click here to open a new feature request. to start community discussion.

Webhost that limits you this way are not competitive and dying fast. I would be surprised if you cannot find a more flexible web hosting firm at a lower cost. Which webhost are you with that still have such restriction?

I’m not using a such host, but I know it exist as I already encounter it and changed due to that restriction :wink: And it’s really low cost host.
After on my side we have our own servers, and we are deploying apps by subdirectories, but for several server names as we link a user auth on a domain it’s more easy to keep him on the good server name. But we can tune our servers and apps for a such case with some development for our customization needs, even if we prefer to avoid such cost.

For the server name management part I will follow your advice :wink:

In fact as long as OAuth is supported so I think our requirements will be fulfilled after you take subfolders out. Only one challenge we need to fix

So RC is a part of our community site and our biggest issue was in the login page customize to avoid feeling the user that he is navigating from our site to another system.

Initially, what we did is to add our own custom OAuth provider. We disabled all kind of the authentications and we kept only our custom OAuth. Then we expected the login page will not appear at all and user will be redirect automatically to our site to generate the access token. However what was happened is the rocket chat login page keep showing with only one button that is representing our custom OAuth provider

To overcome that we used the IframeAuthentication which also contains lot of issues because of cross domain iframe security, in fact it was impossible for some browser to use it

Finaly to we came up with deployint it at subfolder to overcome the browser security and be able to allow user login without that Rocket Chat login page

What I am suggesting here after to take subfolder out, we need more control on the login page without iframe in place at all.

For example we can have an option to configure what is the default authentication provider to be used instead of letting the user see the RC login page and click on a button single button representing our Custom OAuth

I want to host rocket chat and jitsi-meet on a single server at home. My ISP uses CGNAT so my router does not have a public IP address. I can circumvent this using https://devhub.io/repos/beameio-beame-insta-ssl, but they only provide one free generated subdomain and SSL certificate to connect to my network. Jitsi-meet will not run in a sub-folder, so your proposal would make it impossible for me to host rocket.chat as well without incurring subscription fees.

Thank you for your input @toddy. We will take into account specialized hobbyist one-off configurations similar to your case.

Custom Oauth WITHOUT transitioning through our login page should be fully functional before 4.0. Please check with the latest 3.x.x releases.

1 Like

At first glance, this seems like a knee-jerk reaction. It shouldn’t be that difficult to make sure that PRs which link to resources on the server, should start with a baseUrl. Is it really necessary to kill such a fundamental piece of functionality, just for the reasons stated?

@sing.li, you have responded kindly to everyone’s concerns, and with valid suggestions and alternatives. However, there are a million ways to fix a problem, but IMO hosting in a subdirectory is not a “problem” that should be “fixed”.

3 Likes

@joshm_tg I totally agree with you, it is for sure depending on how you providing your solutions so you may have some different reasons other than what I have.

I am just stating what we are facing because as you know in the modern applications any system can have different subsystems with different urls as long as the end user has a smooth SSO authentication mechanism among all of these subsystem

@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

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

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

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

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

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

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

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