[Feature request] Deploy webapp to an alternative web server

[a1730]

Is your feature request related to a problem? Please describe. We tried to deploy Glewlwyd webapp to Nginx but the application failed to start.

Describe the solution you'd like Separation of concerns Separate life cycle for back-end server and front-end application.

• It should be possible to deploy the webapp to an alternative web server, and
• It should be possible to upgrade the back-end service independent of the front-end web application. You already have a relatively stable API for the front-end to leverage while interacting with the backend.

While the focus of this request is 'deployment to alternative web servers,' it is easy to see the benefit of separate life cycle for front and back end services.

It would be nice if we can deploy the webapp to other web servers like Nginx where there are readily available skill set in configuration and security (locking down the server.) Those dedicated servers also have richer (than glewlwyd) support for serving web applications like rewrite rules, serving precompressed files, caching, and up-to-date compliance with web standards. Our motivation came from a requirement to be able to customize some screens as and when necessary. We had modified some pages for version 2.6.0 and got jittery after reading your response to #178 [Feature request] front-end customization.

Describe alternatives you've considered Nothing yet. We wanted to ask the expert if the proposed configuration is advisable/supported before we start the effort.

Additional context Reading the linked documentation in #178 carefully, we found 'Warning: Remember to use front-end files that correspond to your Glewlwyd version' That statement implies an unbreakable bond between our SSO server (a security application and back-end service that should just run - Glewlwyd does), and our login web server- a front end application that we can update multiple times a day or none at all for weeks depending on our user experience... thus, limiting our deployment agility which is critical for security applications like glewlwyd. Imagine that you release a critical patch because of a security event. We will unable to update glewlwyd back-end server as quickly as desired in the face of that event because we need some time to upgrade the customized user facing front-end.

Our concerns, which we hope are misplaced, include

• Front end application deployment stability and agility: updating a CSS, JS, or logo should not lead to 2:00am calls. While we are willing to go through this effort, we are nervous about the unknown requirements for future Glewlwyd releases. We just upgraded from 2.6.1 via 2.6.2 to 2.7.0 and one of our update scripts failed while updating a file that we modified to use SVG logos. Yes, we found this during testing but we would have preferred to test the back-end service independent of the front end.
• Infrastructure reuse: Rules to change the server profile due to user activities; e.g. we would like to redirect all requests to .php files on our glewlwyd server to a honeypot for analysis; we constantly throttle annoying IP addresses based on information from the honeypot. These infrastructure support services are readily deployed for Nginx and other dedicated web servers.
• We will not be able to deploy the web application to a serverless environment where we can present a stronger security profile to hackers.

/enough rambling

We still love <3 Glewlwyd. Thank you for a great application. PS: There were some errors relating to locales, and config in developer tool

[babelouest]

Hello @a1730 ,

If I correctly understand you feature request, here's what I can do:

In the next version, I will provide a glewlwyd-webapp.tar.gz that contains only the /webapp content, so it can be deployed separately more easily.

The other packages would still contain the /webapp content, but you can ignore it then.

About the separation between the front-end and the back-end, that will be more difficult to me, because both are closely bound, and improvements in the UI usually reflect changes in the back-end. I added features to help users personalize their front-end, but I'm very open to suggestions or PRs to help improve this.

About the errors you mention at the end of the message, I would need more information.

[a1730]

Hello @babelouest, Thank you for your quick response.

We are thrilled that you are willing to create a separate the glewlwyd-webapp tar deployment artifact. Thank you.

Our plan is to expose login and profile URLs through the web server while GlewlwydUrl and AdminUrl are handled natively by Glewlwyd so, we will probably use the /webapp content in the full package if available.

It is understandable that the back-end and front-end are joined at the hip. However, it would be nice, based on a simple need for the back-end to be agile, if changes to the back-end are backward compatible with the front-end within a reasonable release window.

I added features to help users personalize their front-end, but I'm very open to suggestions or PRs to help improve this.

We found the available facilities to personalize the front-end to be sufficient for our needs i.e. LoginUrl and ProfileUrl. We slapped a little of the proverbial lipstick on the UI and voila! it looks great and captures username, password, and remember me - that's all we need. It works for us.

About the errors you mention at the end of the message, I would need more information.

Please ignore the error for now. We will stay on v2.6.1 until a separate glewlwyd-webapp tar artifact is available even if we have to wait for version 3.0.

Thank you for Glewlwyd. Thank you for the fast response.

[babelouest]

Can you check the glewlwyd-webapp.tar.gz in the release page and see if that would fit?

I'll answer the other questions tomorrow.

[a1730]

Hello @babelouest,

First, thank you for the swift response (as usual.) In short, it looks like we are almost there.

A quick diff of the contents of that file indicates that the files are identical to what we extracted from the full v2.7.0 distribution. Nevertheless, we replaced our extract with the contents of the above tar file. Using a web server is at 192.168.120.37 and glewlwyd back-end at 192.168.120.97:4593. We created config.json from the sample, and changed GlewlwydUrl to 192.168.120.97:4593. curl http://192.168.120.97:4593/config |jq '.' yields

{ "api_prefix": "api", "admin_scope": "g_admin", "profile_scope": "g_profile", "delete_profile": "yes" }

We see the client hit the server, and had what looked to be a successful login interaction but the web site does not show the admin page. Please see attached images.

2022-05-08T03:39:04Z - Glewlwyd INFO: Glewlwyd started on port 4593, prefix: api, secure: false, bind address: 192.168.120.97, external URL: https://glewlwyd.innov8.cglcons.com/ 2022-05-08T03:44:16Z - Glewlwyd INFO: Event - User 'admin' authenticated with password

We toggled use_secure_connection on and off but it makes no difference. We are back to from where we started and are probably missing something trivial...

PS: I noticed help wanted tag on the issue. How can we help?

[a1730]

Hello @babelouest , Great news. It works. We were getting 401 and not seeing the application page because of back-end server misconfiguration. Thank you very much for your support. Now to start our tests.