Can't login when SuiteCRM 8 is behind a LoadBalancer

[migruiz4]

Issue

I'm trying to deploy SuiteCRM 8 in Kubernetes.

When deploying my container using Docker compose or testing locally using minikube, everything works fine.

The problem starts when I try to deploy SuiteCRM 8 in the cloud (GKE). I configure a LoadBalancer service, SuiteCRM login page appears, but when I try to log in different error appears. These two will alternate randomly:

• "Unexpected error when calling action."
• "Login credentials incorrect, try again" (Using the same password input)

Sometimes, after refreshing, the following will appear the first time I try to log in:

• "Error occurred while fetching metadata"

This doesn't happen when I log in using the /legacy UI or using the same deployment but my traffic does not go through the GKE network loadbalancer (using kubectl port-forward).

Screenshots and logs

Here are some logs and screenshots for each case mentioned above:

• Unexpected error when calling action.
  
• Login credentials incorrect, try again
  

Network after both attempts:

• (After refresh) Error occurred while fetching metadata.
  
  

• Succesful login using /legacy:
  

• Succesful login when traffic doesn't go through the network load balancer:
  

Expected Behavior

Be able to log in through the LoadBalancer service.

Actual Behavior

Login attempts will fail.

Your Environment

• SuiteCRM Version used: SuiteCRM 8.0.4
• Browser name and version (e.g. Chrome Version 51.0.2704.63 (64-bit)): Tested with Firefox version 98.0.1 and Chrome Version 99.0.4844.83
• Environment name and version (e.g. MySQL, PHP 7): MariaDB 10.3, PHP 7.4
• Operating System and version (e.g Ubuntu 16.04): Debian 10 (Buster)

[dgomezleon]

Any update about this issue?

[dgomezleon]

Hello @johnM2401 ,

Have you had the opportunity to examine this case? Our focus is to provide the most up-to-date stable version of SuiteCRM chart. However, this particular issue is hindering our progress. Any info would be greatly appreciated.

[xeruf]

This issue led to the official discontinuation of SuiteCRM from Bitnami, driving away potential users and with them future funding. We wanted to try SuiteCRM and potentially collaborate in the future but without proper kubernetes support we won't engage in the hassle. How can it be nobody cares about what seems to be a rather minor technical issue with big impact?

See also
https://community.suitecrm.com/t/fresh-v8-0-0-install-login-not-working/83157
https://community.suitecrm.com/t/running-behind-nginx-reverse-proxy/84927/6

[chris001]

@migruiz4 From your screenshots, the issue is obviously caused by, when the v8 application is configured behind the load balancer, this load balancer is attempting to login via http, which is rejected by the v8 application for security reasons.

@johnM2401 A simple solution to this issue would be for the v8 application to auto configure its Apache 2.4 to redirect all incoming (non-localhost origin) http requests (from the load balancer) to https, which would pass its login security check, and allow the user to login thru a load balancer.

[AndreasBBS]

@chris001 This issue was opened 2 years ago and no maintainer has even bothered to comment, assign, label, nothing... This isn't solved because it's not technically possible but simply because they don't care, unfortunately.
Bitnami's has been maintaining a chart for this software for years and there's been countless deployments in K8s of suitecrm thanks to the effort put in by Bitnami.
To let this continue unsolved for 2 years to the point that Bitnami has to deprecate their Helm chart just goes to show there's not interest in getting this solved.
Fortunately there's other open source CRM alternatives that offer their own charts like ERPNext or that build in a way that allows charts not to get deprecated like Odoo. Oh, and CRM is just a tiny feature they support.

[chris001]

@AndreasBBS I agree it's a pity, it seems there's a shortage of PR triage resources. One simple solution for this particular issue would be to configure the LoadBalancer to connect to SuiteCRM 8 thru https only. Alternatively, SuiteCRM 8 would configure Apache to rewrite all incoming http requests as https, as my PR does. Lastly, add a new minor feature to SuiteCRM 8, allow http requests when the related setting is set to True.

[xeruf]

As far as I remember, both ERPNext and Odoo are open core though, I was placing hopes in SuiteCRM as a fully open-source alternative :c

[chris001]

@AndreasBBS @xeruf
I confident we'll see this getting fixed. The issue is quite minor (not responding to cleartext http requests from the trusted load balancer on the LAN), the fix is quite basic (respond to the cleartext http request), and the benefit is significant - compatibility with clustered containers running the app.

[migs35323]

@chris001 I did applied your fix, but i am now getting endless redirects.

I am using traefik as an ingress controller/reverse proxy in my cluster to terminate the TLS.

edit: in your fix, should we add conditions to not match ips like the pods/service/cluster CIDR?
because traefik by standard has its pods on 10.42* (and kubernetes services on 10.43.*)
i am a noob about apache, but i am guessing should the htaccess have rules to allow traffic from a trusted proxy, or use the x-headers?

[chris001]

@migs35323
Yes. This patch needs more.

One thing I realize it needs is, for the OAuth login, Suite should send a "long path" search/engine/friendly Redirect URI to Azure, then Apache will translate it back to the Redirect URL with query parameters as expected by Suite.

Yes, further checks would best be made: IP address, hostname, the X-headers containing proxy information.

[AndreasBBS]

@migs35323 It seems to me that the approach of the suggested fix is through this solution:

@johnM2401 A simple solution to this issue would be for the v8 application to auto configure its Apache 2.4 to redirect all incoming (non-localhost origin) http requests (from the load balancer) to https, which would pass its login security check, and allow the user to login thru a load balancer.

That's an admirable effort on @chris001 part. In my opinion it's easier and cleaner the solution suggested later:

@AndreasBBS I agree it's a pity, it seems there's a shortage of PR triage resources. One simple solution for this particular issue would be to configure the LoadBalancer to connect to SuiteCRM 8 thru https only. Alternatively, SuiteCRM 8 would configure Apache to rewrite all incoming http requests as https, as my PR does. Lastly, add a new minor feature to SuiteCRM 8, allow http requests when the related setting is set to True.

I understand why by default SuiteCRM requires https for some stuffs. There's lots of non technical users that will just launch the server and not take the time to secure it. On the other hand advanced users usually setup a reverse proxy that does the SSL. Most of the workloads I run operate in http and I'm responsible for the SSL optionally. I don't mind the default being forced SSL but there should be an option to disable it. I'm going to take a look into it and see if I can introduce such environment variable that if present disables the forced SSL. I might take a bit because my Apache knowledge is terrible, I always preferred NGINX.