Open migruiz4 opened 2 years ago
Any update about this issue?
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.
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
@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.
@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.
@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
.
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
@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.
@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?
@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.
@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) tohttps
, 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 incominghttp
requests ashttps
, as my PR does. Lastly, add a new minor feature to SuiteCRM 8, allowhttp
requests when the related setting is set toTrue
.
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.
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:
Sometimes, after refreshing, the following will appear the first time I try to log in:
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:
Network after both attempts:![image](https://user-images.githubusercontent.com/37381070/159687131-1221bebb-c634-4622-9ef2-a58452d9d373.png)
(After refresh) Error occurred while fetching metadata.
![image](https://user-images.githubusercontent.com/37381070/159689384-8306647c-c100-4f5f-a7a4-a95a1efaacc9.png)
Succesful login using![image](https://user-images.githubusercontent.com/37381070/159688055-69043666-5d07-40a6-8369-8eae783161d8.png)
/legacy
:Succesful login when traffic doesn't go through the network load balancer:![image](https://user-images.githubusercontent.com/37381070/159689015-c8025628-290b-458c-a9c1-dcdd9c0d0bbe.png)
Expected Behavior
Be able to log in through the LoadBalancer service.
Actual Behavior
Login attempts will fail.
Your Environment